Update: don’t try this on a VM, doesn’t work for me!
Hi there! It’s been a while since Jamf added ‘Enrollment Customization’ already, so it had to be done: a post on customising the enrollment experience of users enrolling devices in Jamf Pro with Jamf Connect Login!
GOAL: This setup will prompt the user to authenticate against the iDP in order to get access to enroll the device. Jamf Pro will then pass the user information to Jamf Connect Login.
Just after the Setup Assistant, the user will be prompted by a new Jamf Connect Login window, different from the normal OIDC webapp, to validate the password once more. Jamf Connect Login will then do an ROPG call against the iDP to validate and set the local account password.
This enhances the overall user experience and integrates nicely in the Enrollment Customization feature of macOS Automatic MDM enrollment.
First of all, some requirements:
- Jamf Pro 10.17 (preferably 10.18 to customise the SAML claims)
- macOS 10.15 or higher
- Automated MDM enrollement (ABM/ASM)
- Cloud Distribution Point (JCDS, Akamai, AWS,…)
- Jamf Connect 1.12.0 or higher (Jamf Connect Login 1.7.0)
- Single Sign On configured in Jamf Pro
The reason for the need of a Cloud Distribution Point, is the fact that Jamf Connect Login needs to be installed as an enrollment package, in order to be on the system during the Setup Assistant.
Note: Jamf Pro 10.17 is ok, but I'm testing with 10.18 and the latest version of Jamf Connect 1.16 (Jamf Connect Login 1.9.0) in view of bug fixes.
- Configure Single Sign-On in Jamf Pro
- Configure Enrollment Customization
- Create a pre-stage including usage of the enrollment customization
- Plist for Jamf Connect Login in this setup
Configure Single Sing-On in Jamf Pro
As mentioned above, one of the requirements for Enrollment Customization with Jamf Connect is to configure your iDP as SSO in Jamf Pro. I’ll be using Azure here, but in order to keep this post within limits, I’ll refer you to the following link to configure Azure SSO in Jamf Pro. First make sure that your SSO with Azure is working fine, before continuing the setup below.
Configure Enrollment Customization
Once your Single Sign On is sorted, we need to configure Enrollment Customization in the Jamf Pro Settings -> Global Management.
Here you’ll give the Custom Enrollment settings a name and description as you like. The name will be what you’ll select in the pre-stage later, so choose something handy.
The most important part however is the actual PreStage Pane, where you have the choice between a text window, LDAP authentication and Single Sign On Authentication.
In view of the purpose of this post, linking this custom enrollment to Jamf Connect, we need to choose Single Sign On Authentication. Hence the need to setup SSO in Jamf Pro first…
If you want, you can limit the enrolment access to a specific group (Yes, only one ☝️ ) or leave it to Any identity provider user.
NOTE: Just like for SSO access in Jamf Pro, the user needs to be assigned to the Jamf Pro 'Enterprise App' in Azure AD !
Next, switch the Enable Jamf Pro to pass user information to Jamf Connect to ON.
And last but not least, the Attribute Mappings. This is where things can become a bit tricky, depending on how your Azure AD SAML attributes have been configured for SSO!
By default Jamf Pro will look for 2 attributes: ‘NameID‘ and ‘realname‘. The NameID attribute is most likely already going to be configured, but important to check is the ‘Name identifier format’ and ‘Source attribute’.
Go to Enterprise apps > Jamf Pro > Single Sing-on > User Attributes & Claims:
Click on ‘Unique User Identifier (Name ID):
… and check the ‘identifier format’ > Email address.
In most cases the UserPrinciPalName will match the email address of the user in Azure. However, this is not always the case. If for one reason or another SSO has been configured with NameID set to something else, and or UPN differs from email address etc… the good news is that Jamf Pro 10.18 can be configured to use another claim to fetch the Azure Username / UPN which Jamf Connect needs.
Check the additional claims in Azure for a matching attribute, if needed add an additional claim and match it to the correct value. For instance create a claim ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/something‘ and match it to the UPN.
More in on how to customise claims issued in the SAML tokens here.
Now, the second attribute which Jamf Pro will be looking for is ‘realname’. By default this is not included in the claims, and need to be added:
Note, that I created the claim with a name with nothing more than ‘realname’ and not ”http://schemas.xmlsoap.org/ws/2005/05/identity/claims/realname‘. This as it turns out that Jamf Pro is really looking for the exact claim ‘realname’.
If I would have put the name to ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/realname‘, I would just have to define this full path as a custom attribute in Jamf Pro:
In my setup I just created it as ‘realname’ in Azure, so that I could just leave the Jamf Pro attributes default, meaning ‘Empty‘. Hence Jamf pro will be looking for the default ‘NameID‘ and ‘realname‘ attributes.
Now, before we finish our settings for the enrollment customization, there is one more thing you can do: add a text pane.
This allows you to interact with the end user and provide some additional information about the enrollment process or EULA.
Note: The text pane does not support HTML, but is does support Markdown
Create a pre-stage including usage of the enrollment customization
Now, the final step to put this all together is creating or tweaking our pre-stage. In the General tab you’ll find the dropdown to select the Custom Enrollment config to use in this prestage, so yes you can have different setups for each prestage:
For Jamf Connect Login, we’ll skip user creation…
… don’t forget to select the config profile (see below), which you scoped to all computers, or an adequate Smart/Static Group…
… and of course our ‘Enrollment package’ to install Jamf Connect Login during Setup Assistant!
Plist for Jamf Connect Login in this setup
NOTE: Because of the different flow of actions compared to a standard Jamf Connect Login setup, you need to make sure to add the ROPGProvider and ROPGTenant keys. In a standard, pure Azure setup, the OIDCROPGID key is enough. Here we need to tell Jamf Connect how to do the ROPG call. --> without those I got an error saying "can't authenticate, try again". Also, depending your Azure (and ADFS) environment, you might need to use the Azure_v2 end-points, or authenticate against ADFS. See Jamf Connect Hybrid setups here.
That’s it! If all went well you should see the following behaviour when enrolling new devices:
- The normal remote management screen:
- Our custom Text pane:
- The custom Azure Authentication kicking in:
- The Remote Management screen again, downloading the MDM profile (after being granted access through the iDP authentication):
- And depending the options you skip in the prestage, the Setup Assistant continues and configures the Mac:
NOW! With a normal Jamf Connect Login setup, you would be presented with the OIDC webapp login window here, but thanks to the integration with the custom enrollment, Jamf Connect Login now only presents a window to validate the password. Here the user needs to validate the password once more to be able to create the local account:
That’s it! To be honest, I really like it! What about you? Let me know!
Oh yeah, one more thing... I was recently asked if this setup changes anything in view of the creation of Secure and Bootstrap Tokens in Catalina... Well, the answer is NO! Although the user is authentication to the iDP during the Setup Assistant, we are still skipping user creation in the prestage settings. Hence Standard accounts created by Jamf Connect (where the actual creation of the account is still done AFTER the Setup Assistant), does NOT get a Secure Token and Bootstrap does NOT get enabled. Admin accounts created this way do get a Secure Token but Bootstrap will still be disabled.
As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Senior Enterprise Support Engineer | Jamf
What about MDM user ? Is the first user set up as the MDM Enrollment user ? No problem to link the user automatically to the computer in Jamf Pro ?
The first local user indeed becomes the MDM capable user. But can you elaborate the second question?
In fact I already got my answer somewhere else, thanks 🙂 But yes, basically the Mac is properly automatically bound to the user in Jamf Pro during enrollment so fine for me.
BTW I try to peform the same setup with Okta, but fails to do so. Authentincation with Okta is working, but the
I tried using just “NameID” in both Account Name and Real Name fields in the SSO pane, but I just get the standard Jamf Connect Login window and the user still has to type the username and password.
Thanks for your help and your tremendous work on this blog !
In fact the same article for Okta would just be awesome 😀
That’s something I have to do indeed! Let’s see how many hours there are in the upcoming werkend 😉
I finally managed to make it work with Okta, we add to create new dedicated assertions, but it worked! Woohoo!
BTW, the “No VM” issue must be really linked to AAD as we had no issue to test with a DEP-enabled VM.
Thanks! Good to know!
When the Azure Authentication kicks in I am able to enter my Email but then it takes me to a blank page instead taking me to the screen to enter my password.
Do you know what the issue might be?
Still within the setup assistant right? Not the normal Jamf Connect login window after the end of the setup… because if that happens it means Jamf did not get the correct attributes.
If during the setup assistant, before the MDM profile is downloaded, then there is either something wrong with the SSO settings in jamf pro or the jamf pro app in Azure
What about the Notify screen in Jamf Connect? Can you use it without having another Azure Authentication and if so, what do you have to change?
Currently I am getting a second azure authentication when jamf connect kicks in which is less than ideal. Would love to use this “native” azure authentication instead of Jamf Connects during enrolment, but really need the notify feature to kick in later on during the setup.
Hi Carl, the Notify feature in Jamf Connect is actually a ported version of https://github.com/jamf/DEPNotify-Starter/blob/master/depNotify.sh which you can use without Jamf Connect… would that fit you request?
Hi,
I noticed that no matter what I do, I am still getting the other Azure authentication. I just noticed your update about this not working on a VM and I have been testing on one. Did you have the same problem on your VM?
If I want to still use Jamf Connect as well is it possible to get it to kick off the Notiy screen after the steps you have listed above?
On VM’s I could not trigger the passthrough of the account info to avoid the normal Azure login instead of just validating the password. Works fine on physical machine if the attributes are correct in the claim. I’ll have to test Notify to see what the behavior is in combination with this.
We are not using adfs so using the Azure_v2.
When Enrolling I first see the text box and then the microsoft login windows, so that works fine – , but then it switch to jamf login window and error message to “Could not create request URL” shows
Any idea?
So the Microsoft login during the prestage comes from your SSO prestage customization. The jamf connect login screen you see after the setup assistant (when not passing the user details like ij the post) is the normal jamf connect login screen. If that fails to load the URL… thats because the jamf
Connect login profile is either wrong or not scoped correctly. Even if you add it to the prestage, you have to scope the profile itself correctly or it will be removed immediately after enrolment
Thanks –
So if following your details above it actually only show one login windows, instead first MS window and then jamf connect window ?
Should your blog also work the same way with azure V2? or not yet testet?
Just an update from my site.
I don’t know what initially went wrong, but now the error is gone. But SSO mapping does not work so I have to sign in 2 times and cannot understand where the issue is as I do exact same as you have done in the blog
You are not trying this on a VM right?
Yes actually earlier read the other post from another user so thought that was the reason. But also trying on a physical machine it does the same 🙁
In that case the attributes retrieved from SAML are not correct. Jamf Pro looks for NameID and Realname. If this is not fetched correctly from the SAML message, it will not be able to pass it to Jamf Connect and present the normal JCL window again. You can test the SAML message in Chrome with the SAML Message Decoder Extension and sign in to Jamf Pro via SSO. It will give you the attributes it retrieves.
My SSO works fine on jamf pro
I tried to add this extension but I not get much closer I think – what should I look for as there is a lot of lines with all kinds of writings
Sorry – just had to copy it out before I could see all
Here are the main things
I see the following
“http://schemas.microsoft.com/identity/claims/tenantid”> name
ok seems I cannot copy paste. But i See the name and realname attributes (I cannot see it named namdID)
SORRY nameID also was named with my email adress
How is it returned? As “realname” or as full url like: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/realname‘
Please check what I wrote in the post:
Note, that I created the claim with a name with nothing more than ‘realname’ and not ”http://schemas.xmlsoap.org/ws/2005/05/identity/claims/realname‘. This as it turns out that Jamf Pro is really looking for the exact claim ‘realname
It is replying only realname so the config seems right
This is driving me crazy why this does not work for me 🙁
Any other good ideas where the reason behind this can be hidden ?
Open a case with support and we’ll have a look at it
My Collegue created a jamf support ticket, but according to them the 2 times login is how it should work
He got the following feedback:
This is expected and by design and there is no way to skip the second login:
first login) This wil do an authentication against the application in AzureAD. Microsoft not let us read the password here
second login) Will do a Resource Owner Password Grant during the second login. Here, we’re able to read the password and based on this create or authenticate to the local account.
So 2 times login will always happen ? or can you do some magic tricks that someone else in jamf does not know off ?:)
No as explained on the blog, 2 times login is always the case with Jamf Connect. But this is not what this post is about! When you deploy Jamf Connect you have scenario which you do explain correctly here above! However, this blog post is about the custom enrolment where you authenticate already to Microsoft during the initial setup. So that 1x authentication, but if you would then deploy jamf connect you would do the same authentication again (2nd authentication) and them again to validate the password… so 3 in total… what this post is all about is to pass the first authentication to jamf connect during the setup assistant and then only 2 second time after the setup assistant to validate the password. I even have screenshots of those 2 authentications in the post showing you the entire flow, so I don’t know where the confusion is.
OK – this is really confuse me. From what I can see with your pictures you do the exact same as me. Azure setup, deploy Jamf connect package in enrollment – but I see login windows 2 times where I have to enter email + password
But as you and also Jamf write 2 times authentication is how it is – but understand what the difference is between your example above and my I don’t see. But does not matter, so no need to waste more time on finding an error that is not there
Hello,
After successfully configuring JAMF connect, I realize that everytime I restart or logout from my physical test device, I get the windows for Azure Authentication again and then the Jamf Connect Login window to enter my password.
It’s interesting that if I enter another Email during the Azure Authentication it creates another account.
Do you know what might be causing the account creation all over after a restart or logout?
JN
Hi James… thats exactly how Jamf Connect works by design… it’s not “one time user creation”. As long as JCL is enabled, it shows the iDP login window instead of the Native macOS login window.
It does indeed create another account if you login with another user…
Hello,
I was just wondering how its pulling the username for the local account and if there is a way to customize it based on username.
Thanks,
Hi, could you elaborate a bit more? Not sure I understand the question because the account name is linked to the AccountName attribute..:
OK – this is really confuse me. From what I can see with your pictures you do the exact same as me. Azure setup, deploy Jamf connect package in enrollment – but I see login windows 2 times where I have to enter email + password
But as you and also Jamf write 2 times authentication is how it is – but understand what the difference is between your example above and my I don’t see. But does not matter, so no need to waste more time on finding an error that is not there 🙂
2 times is normal with Jamf Connect but for this scenario it should be: 1) user and password during SSO authentication in setup -> only password again after setup assistant. If you see the web app again after the setup assistant, it’s because jamf pro did not correctly pass the info to Jamf Connect
well then I think we are back again where it started. I deploy Jamf connect within the enrollment as you above. But first see custom enrollment flow where I sign in – and afterwards it ask for login again, where I think it should only ask for password.
If I sign in the 2nd time the password validation show up, but I hoped to skip the 2nd time sign in, so it only would prompt for password validations as your picture´s show
Hello,
I was able to get to the last screen where the user is prompted to enter their password to create the account. Unfortunately when I enter the password I get Unable to log in. Please try again.
Do you know what I could be missing?
Thanks,
Jimmy
Contact Jamf Support and raise a ticket. I have similar cases.
Hello,
first of all big thanks for all guides, you did for us. I really appreciate it.
It’s possible to use LDAP information with that way? If I’m handling the prestage with Enrollment Customization -> Azure SSO because I very like the way the users have just one authentication and you can skip the second sign in for the local user. Unfortunately, if I’m using this way I haven’t user information in jamf pro or to handle my permissions for the local admin with my specific groups via jamf connect login plist file. (like login with Enrollment Customization -> Azure LDAP)
The other way with LDAP without using Azure SSO works perfect but I like if I’ve for my users just one login and every other things are skipped.
Hi Flaurian,
Apologies for the late reply, but if I understand your question correctly I must conclude that this is not possible.
Jamf Connect does not use LDAP. It uses OICD via your iDP, hence passing info from your iDP and parse it with LDAP won’t be possible.
However, if both SSO and LDAP are enabled the inventory collection can fetch LDAP attributes by setting it in the Jamf Pro settings-> Computer Management -> Inventory collection: Collect user and location information from LDAP
Collect user and location information from the LDAP server when inventory is updated
And suddenly i see a screenshot of a config profile which was never mentioned before in this article.
Should i create it and what are the content?
@Dennis What screenshot are you referring to?
I’m new to JCL. During the jumpstart it was advised not to upload your own config profile with JCL settings but use the “Jamf Repository” as a source for these settings (under “Configuration Profiles” –> “Application & Custom Settings” –> “Source = Jamf Repository”). Is there any reason you prefer your own config profile over the Jamf repository?
Do you create your plist with JAMF Connect Configuration or do you use a different tool? Also, do you need to sign the plist/profile with your own developer id before uploading it to JAMF?
I’ve read on the #jamf-connect-slack macAdmin-channel unsigned profiles could lead to issues.
Thank you for these blogs. They have been more helpful than the JAMF Connect official documentation!
Hi Marcel, I have always been using plist from day one because of the main reason that nor the config tool nor the Jamf Repository existed in the very beginning. So I got used to plists.
The config tool is nice because it creates either a plist or a config profile for you, but (and this is my personal opinion) is till prefer the plist because it gives me a better overview. Main reason for using the config tool would be: if you are new to JC it might get complicated to understand which key needs to be in the plist for each feature you want to use. It’s easy to miss one. The config tool really helps you with that. Same goes for the Jamf Repository.
However, as I’m in the support realm, and quickly need to test and re-test configs when troubleshooting, I find it much easier and quicker to look at a plist and quickly spot missing or wrongly configured keys.
If I would need to click buttons in the repository or navigate through multiple tabs in the config tool, I would loose too much precious time.
Profiles could work if I’d read them in a text editor, but they give me too much things around the plist which I don’t need for troubleshooting. When uploading a plain plist to Jamf, Jamf Pro will built everything around plist to make it a profile, and sign it.
That said, as a summary, for me plist is much easier for troubleshooting, but when new to Jamf Connect the config tool is a real big help. However, when I quickly need to test a very basic setup with minimal keys, I do use the config tool to test OIDC and ROPG. Very handy!
Finally regarding signing the profiles… should not be necessary if you only change keys specific to Jamf Connect, but I typically don’t upload profiles, just plists (for the reasons above).
Hope that clarifies my personal preferences?
Yes, thank you so much for this detailed explanation. The reason I asked was because I’m running into an issue with JCL and Azure when I change the key OIDCNewPassword from true to false. When set to true, a new user is requested to enter a new password after Azure authentication. I want our users to use their Azure password with their local account, so I’ve set this key to true.
After Azure authentication, the user needs to authenticate again in JCL but an error occurs:
“AADSTS900144: the request body must contain the following parameter: ‘resource'” when logged in. I’ve created a ticket with JAMF.
The plist you’ve published above also has set this OIDCNewPassword key set to false.
I was hoping that this error was maybe related to a JCL setting and by uploading a plist manually I would at least have more control about these keys. I’ve noticed that the Jamf Repository misses a few keys anyway (like LAPSUser) so manually is the way to go!
Thanks again for your informative posts!
Sorry, typo, I mean:
“so I’ve set this key to false”
Sorry, typo, I mean:
“so I’ve set this key to false”
Yes, I understood that :-). Regarding the laps keys, indeed, another reason for plist approach. Regarding the error, do you have the provider set to Azure_V2 by any chance? https://travellingtechguy.eu/jamf-connect-error-codes/
Wow, that was so helpful!
I’ve had set the Identity Provider to Azure (in the Jamf Repository this key is named “Azure”, not “Azure_V2” another reason to go for plists 🙂 but did not fill in the tenant ID.
It works now. I googled for that specific error code but didn’t find any useful results. Thank you for pointing me to your article, I completely missed that one.
Nice! Most welcome! Always happy to help.
Guide is awesome, saved me a lot of headaches. Is there anyway to populate the jss record for the system to include the user that actually uses it and not the management account? I need to be able to use the $EMAIL tag from the record for a few things.
Hi Mike, not sure if I entirely understand what you want to populate. Apologies but can you elaborate an bit more?
Basically just trying to assign the device to the user during enrollment. As of right now, it’s putting the management account as the managed user
Hi Mike, still a bit confused.
If you mean the user assignment in ‘user and location’, then this will be the user authenticating in the SSO process. It automatically assigns the user to their device in Jamf Pro. If LDAP is also integrated with Jamf Pro, the User and Location information will be fully populated using a lookup from Jamf Pro to LDAP. If LDAP is not integrated with Jamf Pro, the Username field will be the only item populated in the User and Location category, and user lookup will not work during enrollment.
However, if you are referring to the ‘manage by field’ in the inventory, that is normal that it is the management account being referenced.
Hi – Thank you for this amazing guide.
I have just implemented jamfconnect and everything works until I get to the validate the password and this gets bypassed/skipped. so no account is created.
Have you seen anything like this before? I am new to Jamf Connect. any help is very much appreciated. I am sure I am doing something wrong.
I am using Pre-stage enrolment with Azure and Jamf Connect V2.3.1
Thanks in advance
Mamadu
Hi, I think you are referring to the moment where Jamf Connect tries to validate the password against Azure via ROPG. Depending your Azure tenant, and how it is synced or federated with an on-prem
AD (via ADFS for instance), your setup may need to be changed or may not work with Enrolment Customisation at all.
Best would be to open a support ticket to investigate things in detail, but if you can tell me if your Azure AD is federated with ADFS or not, that would be a good starting point.