Azure AD, SSO, and New Device Setup

McAwesome
Contributor III

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.

1 ACCEPTED SOLUTION

McAwesome
Contributor III

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.

View solution in original post

2 REPLIES 2

McAwesome
Contributor III

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
New Contributor

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