Azure AD, SSO, and New Device Setup

[McAwesome]

We recently migrated to Jamf Cloud and using Azure AD as our Cloud Identity Provider and Single Sign-On solution.  It works well enough, but we have a weird situation.  We're sticking pretty close to Microsoft's documentation on it, which can be found here.

By default, the iDP maps userPrincipalName as the username.  That's a full email address in our environment, so we want to use onPremisesSamAccountName instead.  That works fine in the iDP in both testing and looking up users/accounts.

We also need user authentication during the initial device enrollment via DEP.  We've gotten that added in by adding an Enrollment Customization that is just the SSO.

Here's where it gets dumb.  If we now enroll a machine while the User Name mapping is set to onPremisesSamAccountName, the SSO during enrollment registers the device to just the userPrincipalName with no other user data.  The Pre-Fill Primary Account Information only puts in the userPrincipalName as the User Name, and the user is able to modify everything despite Lock Primary Account Information being set in the Prestage.

If we change the username mapping back to userPrincipalName, it pulls the rest of the data from Azure but still locks the username to that full email address.  It also still lets the user set their password on the Create User page of initial setup, which I assume is because Azure can't pass the password.

Is there some kind of undocumented trick you need to do to get it to successfully use onPremisesSamAccountName for the username?  Everything I can find says to just put it in there and it should work.  What's even more perplexing is that we had it up and running two days ago with the same settings in a test Jamf Cloud environment.

[McAwesome · Accepted solution]

Closing the loop on this.  We ended up resolving this by doing the following:

1. Change the Azure > NameID to be the onPremisesSamAccountName
2. Change the Cloud Identity Provider > Server Configuration > Transitive groups for SSO to use onPremisesSamAccountName
3. Change the Cloud Identity Provider > Mappings > User Name to onPremisesSamAccountName

Once all three were changed, it started working as expected.  Only downside is that it doesn't set the local account's password to match the Azure one entered, but I'm ok with that.  At least it's (mostly) working now.

[robertryans]

Wanted to thank you for this post - solved a problem which had been vexing me for some weeks with our SSO trial.

[ericbenfer]

I am running into an error with onPremisesSamAccountName.

When I set Settings > System > Cloud Identity Providers > "My Azure Name" > Transitive groups for SSO > User Mapping From The SAML Assertion to: onPremisesSamAccountName
I get this error when trying to save:

User Mapping From The SAML Assertion

Value for the identity provider user mapping configured for single sign-on in Jamf Pro. This must match the User Attributes & Claims configuration of your Single Sign-On with SAML settings in Azure. The value must be the same for all Azure cloud identity provider configurations.

I've already set SSO User mapping to onPremisesSamAccountName

[sintichn]

So I had the exact same issue as @McAwesome, then when trying out the solution I was getting the same error as @ericbenfer. I figured out a solution so I'm going to put it here just in case someone is looking.

NOTE: before you start this, make sure you are able to reach the ?failover login page. 

1. In Azure AD>Enterprise applications>Jamf Pro>Single sign-on>Attributes & Claims
   1. Add a new claim
      1. Give it a name (something like username) Source is Attribute and search for user.onpremisessamaccountname
      2. Save the claim and note the name you gave it
2. In jamf pro>settings>system>single sign-on
1. Change Identity Provider User Mapping to "Custom Attribute"
2. In the Name box that appears below enter the name of the claim. in my case, it was username.
3. Change Jamf Pro User Mapping from "Email" to "Username".
   1. Not totally sure why this is a thing... but jamf was not allowing us to log in via SSO until I made this change.

That's all! after that, our jamf pro users are able to sign into jamf pro... and devices that we enroll were no longer being placed under a new user, they are being enrolled to the correct user via the username.

I hope this helps someone searching for this!