Challenges with User Attribute Mappings in Jamf Pro and Microsoft Entra ID SSO Integration

[tobiasjk]

Hey everyone!

I'm reaching out for guidance on a complex issue I've encountered with integrating Jamf Pro and Microsoft Entra ID for SSO, specifically regarding user attribute mappings and device enrollment processes. Despite a successful setup of Single Sign-On and Cloud Identity Providers for new macOS device enrollments with corporate credentials, I've hit a stumbling block with more detailed configurations.

Core Issues:

1. User Attribute Mappings: My goal is to map the User Name attribute to the onPremisesSamAccountName (essentially, the UPN without @domain.com) for a more intuitive username representation. Additionally, I aim to map Phone attributes to mobilePhone and Position to jobTitle, enhancing user profile completeness within our system.

2. Device Enrollment Customization: During the Setup Assistant phase of Automatic Device Enrollment (via ABM), I intend to pre-fill the primary account information with the device owner's details. However, the system defaults to using the UPN/email for the "Account Name" field, rather than the desired username. This deviation from our goal hampers user experience (especially since macOS doesn't like the @ in the username).

Attempts and Roadblocks:

• I've explored various community suggestions and official documentation, including a detailed thread on here: (Azure AD SSO and New Device Setup) and guidance intended for Jamf Connect SSO setups (SAML Token Attribute Mapping for Enrollment Customization), hoping for overlapping solutions.
• Modifying "User Mapping From The SAML Assertion" in Jamf Pro settings to anything aside from "userPrincipalName" seems unfeasible, as changes refuse to save even when the corresponding claim exists in the Entra ID Enterprise app.
• Attempts to adjust the NameID in the Enterprise App to use the SAM username instead of UPN disrupted SSO functionality, contradicting Microsoft's documentation suggesting such customization is supported.

Given these challenges, I'm seeking insights or success stories from anyone who's navigated similar configurations. Jamf support has yet to offer a resolution, leaving me to wonder:

• Is it feasible to utilize anything other than the UPN for the username in this setup, without leveraging Jamf Connect?
• Are there alternative strategies to import other user attributes into Jamf Pro, akin to what's achievable with LDAP?

I'm eager to hear your thoughts, experiences, links or any other recommendations you may have!

Some screenshots:

Some of my tested claims 

Error when I try to change the User Mapping

The User mapping settings I want to change from the default info I get from Entra ID

 

 What I'm getting, including the UPN for Username

[TheAngryYeti]

This should help you out a bit.  The SAML mods and additional claims are indeed supported.  The issue you may be experiencing could be that with the changes being made it doesn’t match the users that have been manually created in the admin console(admin login). If you are matching based on username it has to match what’s being presented so it would need to be changed to the SAM after the mods have been made. https://travellingtechguy.blog/azure-ad-attributes-and-group-claims-for-cloud-idp-and-sso/ 

[tobiasjk]

Hi @TheAngryYeti 
Thank you for the link, it helped me quite a lot but I still have issues with SSO.

I have set the claims as following:

I have the settings as following in Jamf Pro:

Single sign-on:
Identity Provider User Mapping
NameID
Jamf Pro User Mapping
Username

Cloud identity providers:

User Mapping From The SAML Assertion
userPrincipalName
(I still can't change this to either onpremisessamaccountname or onPremisesSamAccountName as mentioned in the guide, I'm not sure this is what breaks the SSO?)

Mappings > User Attribute Mappings > User Name
onPremisesSamAccountName

---

If I use the test function on the Cloud identity providers page, I can now search the user with the onPremisesSamAccountName as username and I also get the position and phone number.
I can also add admins, as they should up correctly with the username and not UPN

However I can't use the SSO now. In the Enterprise app's Sign-in logs my attempts have a Success status, but I'm getting this error when trying to login:

Any ideas?

[TheAngryYeti]

Where it is breaking is with the NameID field - that really needs to be in a similar format to your short names - either mailNickname or onPremisesSamAccountName.  Keep in mind that SAML is formatted differently from the OAuth you see in the directory.  For this to work you will need matching values from SSO --> SSO Transitive lookup --> the username mapping.  Another route you can go is with the SSO settings in Jamf Pro instead of using NameID you could use another attribute(Custom Attribute) available if you add it to your SAML claim.  Feel free to DM me further.

[tobiasjk]

Update:

I change the NameID back to UPN but keeping the user mapping for username in the idP settings to onPremisesSamAccountName, that seems to give me what I wanted 🙌

Now it looks correctly, when creating a user in the Setup Assistant (using the username instead of UPN), the user is added how I wanted it in Jamf Pro and I can use SSO as well for both enrollment and the Jamf Pro login.

------

But using both UPN or onPremisesSamAccountName I get this error in the Jamf Pro Server Log. Any idea why it can't look up my user groups? I read that SSO previously didn't do Group lookups but it sounds like it should now.

Caused by: com.microsoft.graph.http.GraphServiceException: Error code: Request_BadRequest
Error message: Invalid object identifier 'CMA Admins'.

GET https://graph.microsoft.com/v1.0/groups?%24filter=id%20eq%20%27CMA%20Admins%27%20or%20id%20eq%20%27C...
SdkVersion : graph-java/v5.75.0

400 : Bad Request
[...]

[cbrewer]

We utilize SAM Account Name. In Entra, I changed our Required Claim for Name ID to user.onpremisessamaccountname. You might try that.

[Jay_007 · Accepted solution]

I've just done this exact thing for a customer. There is a trick with getting the User Mapping From The SAML Assertion to stick under Cloud identity providers. You need to edit and change it to your desired value then deselect Transitive groups for SSO. Save, then Edit again and select Transitive groups for SSO and Save again - Strange behaviour, but then it sticks.

Here's the full process to change the username mapping from userPrincipalName to onPremisesSamAccountName:

Make sure that you can access the Failover URL first as this briefly breaks SSO!

Entra ID Changes:

1. Sign in to the Microsoft Entra admin center as a Cloud Application Administrator or Global Administrator.

2. Browse to Microsoft Entra ID > Enterprise applications > All applications.

3. Search for an select the Jamf Pro application.

4. Select Single sign-on in the left-hand menu, and then select Edit in the Attributes & Claims section.

5. Select Unique User Identifier (Name ID)

6. In the Source attribute field, select the dropdown box and change user.userprincipalname to user.onpremisessamaccountname and then Save.

Jamf Pro Changes:

1. Access your Jamf Pro console via Failover URL, as the above change will affect SSO login.

2. Go to Settings > System > Cloud Identity Providers > {NAME}

3. Edit and change User Mapping From The SAML Assertion from userPrincipalName to onPremisesSamAccountName.

4. Deselect Transitive groups for SSO, then save. - There appears to be a bug that won’t let you modify without first removing it.

5. Edit again and reselect Transitive groups for SSO and Save.

6. On the Mapping tab, change User Name field from userPrincipalName to onPremisesSamAccountName. You can also modify any other mapping field here if you wish.

7. Go into the PreStage enrolment profile > Account Settings and change Information Type from Device owner’s details to Custom Details and enter the following variables:

Making these changes will then map users by the SAM account name as the username in Jamf Pro and will also automatically populate as the local device account name during the setup. Jamf Administrators can continue to login to the console with their full UPN as normal. Hopefully this is helpful.

[tobiasjk]

Thanks for the detailed guide @Jay_007 !
I also had to change "Jamf Pro User Mapping" to "Username" in the Single-Sign On settings, but other than that, the solution worked perfectly.

[tobiasjk]

In step 6, I also changed the NameID's "Name identifier format" to "Unspecified". Not sure if it's needed but it seems to be best practice.

[Jay_007]

Ah ok, also good to know! Microsoft's documentation is never great at explaining things 

[Jay_007]

The Jamf Pro User Mapping was already set to "Username" in the Single-Sign On settings in the environment that I was working on, but thanks for pointing that out. Glad the rest of it worked for you :)

[kai_wang1]

Really appreciate your sharing 👍

[Jay_007]

No problem :)

[djrory]

Do you think you can weave Jamf Connect into this? We're trying to do much the same except we want Jamf Connect Login to create our local user accounts with our onPremisesSamAccountName

We can't get the Jamf Connect App registration to provide the onPremisesSamAccountName claim in the SAML response....

[kai_wang1]

As default, account created as xxx@domain.com, after I changed to use  onPremisesSamAccountName on Entra ID. I also need changed username to onPremisesSamAccountName on Jamf to map.

[kai_wang1]

Pls check on Jamf Connect setting, if anything similar and update to onPremisesSamAccountName

[djrory]

Unfortunately I haven't found a way to send onPremisesSamAccountName in the SAML Response from my Jamf Connect Entra ID App Registration. It is not included in the claims by default and I cannot find a way to add it. 

[djrory]

Got there eventually!

[jamtay]

This is very useful info, thanks for posting. I'm just leaving a comment here in case anyone has come across this error when trying to make any changes to the Jamf Pro Entra configuration? We're a bit stuck with user and group lookups both not working...

[RLR]

Some good information in this thread. I'm looking to enable SSO so researching it a bit. One thing I'm unsure about is how attribute mapping works if you currently have an LDAP server setup. Attributes for my users are currently mapped via ldap. If I enable SSO, will that then take over or is there a choice? Pretty sure my SSO attributes are the same as LDAP but just wanted to check.