Hey all,

Quick update: for those playing around with a custom attribute like onpremisessamaccountname... I just realised that the correct syntax for this is onPremisesSamAccountName. So not all lower caps like in my screenshots. Otherwise SSO works but JPRO does not map the username correctly via Cloud iDP.

Let’s talk about Azure AD attributes and group claims. This for Single Sign on, as well as scoping based on the Azure AD integration (Cloud Identity Provider).

Let’s start with Single Sign on, which we configure as per: https://docs.microsoft.com/en-gb/azure/active-directory/saas-apps/jamfprosamlconnector-tutorial

The first thing I’d like to kick this post off with, looking at that article, is how to define the group claim in JPRO. The article mentions the claim to use is:

http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

That’s totally fine, but by default the group claim may not be defined in the Azure App for JPRO (or a new app you create):

If that is the case, you need to add the group claim first:

Important here is the Source Attribute you select for the Group Claim. By default it is set to Group ID. However, leaving it like this results in a SAML message which includes the long ID strings of the group, instead of the human readable group name:

If you do leave it like this, you will need to use the same syntax for the groups you add to JPRO (See below for which functionality adding a group to JPRO is needed):

I’d recommend to change the Source Attribute to sAMAccountName, which results in passing the real group names in the SAML message:

Once you have the group claim added to the SAML config in Azure, you can add it to the SSO settings in JPRO:

As you can see the you need to define the exact and full claim, which is by default in the syntax of a URL: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

Now, as you may have noticed in one of my previous screenshots, I had a claim in the list named ‘Something’. Just a single word, and not like the URL for the group claim above. That is totally possible as long as you define it like that in both Azure and JPRO, but for now I’ll just keep things a bit default and leave the group claim as is.

With SSO configured in JPRO, we can leverage SSO for 3 things:

  • JPRO webapp (GUI) access
  • Enrollment
  • Self Service

Let’s start with enrolment and Self Service. For this NO account is needed in JPRO Settings -> JPRO Users and Groups. The only thing which is needed is to enable those features in the Single Sign-On Options for Jamf Pro (SSO settings):

For both enrolment as access to Self Service, the end users need to be assigned to the JPRO app in Azure:

Without assigning the end users you will end up with error AADSTS5010.

AADSTS50105: Your administrator has configured the application Jamf Pro ('65e3187b-REDACTED-0de9249814f5') to block users unless they are specifically granted ('assigned') access to the application. The signed in user 'Yoda@travellingtechguy.dev' is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator.

For enrolment you can further restrict access in JPRO by selecting Any identity provider user or specify Only this group.

For Self Service, any user assigned to the JPRO app in Azure gets access to log in.

Now, for JPRO GUI access, we need more. We need to add either a group or a user to the JPRO Settings -> JPRO Users and Groups and define the level of access and privileges!

You can either add the user directly or because we added the group claim in the SAML token, add a group the users which require GUI access are member of. If you choose for a group, make sure to add the groups like it is passed in the SAML token, readable name or ID… see what I discussed here above.

A standard user/group is enough, but if you also have an LDAP or Cloud Identity Provider integration enabled in JPRO, you can define it as LDAP user/group. The logic JPRO uses for LDAP or Cloud iDP is basically the same, however, when defining user/group as ‘LDAP’ an additional lookup to either the LDAP server or the iDP will be done during authentication. If you are using legacy LDAP instead of Cloud iDP, this may not be preferred in view of limiting the amount of LDAP calls JPRO does. I’d suggest going with standard accounts in JPRO Users and Groups, and even better, a standard group so you do not need to define password for the accounts in JPRO (password in JPRO which are not going to be checked anyway via SSO).

Now, just like the group claim, which you can define as Group ID, sAMAccountName, … the username in Azure can also be mapped to different things. By default the Name ID, or Unique User Identifier, is mapped to user.userprincipalname:

Name ID or Unique User Identifier is what is, by default, used to identify the user in a SAML message unless you change the mapping in JPRO to a custom attribute:

If you want to identify user account by another attribute, you either define the Custom Attribute (as available in the Azure Claims you configured, so either URL syntax or a shorter claim name as discussed above), or you change the mapping for Name ID / Unique User Identifier in Azure.

For instance, use Something as attribute like below,…

or change the Name ID like I changed it to onpremisessamaccountname here:

Regardless of what approach you choose, when adding users in JPRO => Settings => Jamf Pro Users and Groups, you need to make sure to create them with a username matching the value of the attribute you choose for the Identity Provider User Mapping, as well as setting the JPRO side mapping accordingly to either Username or Email. Everything needs to match up.

Now, let’s go a bit further than just SSO via Azure AD, and add the Cloud Identity Provider integration to the mix, as there are a few things to say about the mapping, as well as the group claims.

In the past JPRO only had the possibility to integrate with LDAP. However since a few versions we can now also integrate directly with Cloud Identity Providers like Google and Azure AD.

Focussing on Azure AD here, the integration is quite straight forward: https://docs.jamf.com/jamf-pro/documentation/Azure_AD_Integration.html

The default mappings can be found in the article above, but subject to your environment and/or needs you may need to change them. Apart from the User Name, which I changed to onpremisessamaccountname, you should by default end up with the below ‘default’ setup:

Now, the reason I changed the username mapping to onpremisessamaccountname, was to allow me to define users in JPRO Settings => JPRO Users and Groups in a short and easy way like ‘Yoda’ instead of ‘Yoda@travellingtechguy.dev’ for instance. Or same for scoping and device assignments to users for that matter. Just a preference or matter of what you need or want to use in your environment.

One thing I’d like to highlight here is the confusion I see from time to time regarding the syntax of the attribute we need to define. For instance user.onpremisessamaccountname, onpremisessamaccountname or a URL syntax like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.

Well, important here is to realise the difference between the settings for SSO in JPRO, versus those for Cloud Identity Provider. In the SSO settings the claims need to be defined like you defined them in Azure in the SSO settings of the JPRO app. Matching either the URL syntax or the short name as defined.

For JPRO Cloud iDP settings however, any attribute which has been made available in your Azure tenant can be used, and the syntax is typically the part after the “user.” when you compare it to the SSO claims source attribute. For instance the default onpremisessamaccountname or a custom attribute like sAMAccountName which I provisioned from my on-prem AD for other testing (instead of using the default onpremisessamaccountname):

Important:

To ensure the configuration works as expected, consider the following:

The values for the User Id mapping must support the $filter parameter in Azure AD.

The value for the Group Id mapping defaults to “id” and cannot be changed.

The last thing I’d like to discuss here are the ‘Transitive’ options available on the Cloud iDP settings.

The first one I want to highlight is the one for membership lookups. Purely impacting the LDAP-style lookups:

If your Azure AD holds nested user groups, it’s important to enable this in order to make sure that all groups a user is a member of, directly or indirectly, are returned in the lookup response. 

IMPORTANT: JPRO currently limits the max number of groups to 150 ! However, there is a custom knob which can be enabled in the JPRO database to increase that limit. For this I suggest talking to Jamf Support to discuss it.

The other one, Transitive groups for SSO, is a bit special. At the start of this post, I’ve been discussing the groups claims passed into a SAML token. If we only have SSO enabled, or SSO and legacy LDAP for that matter, the group membership is based on the groups which are returned in the SAML message, just like:

JPRO then matches that with the groups in JPRO => Settings => JPRO Users and Groups. As long as the mapping and value matches and the group claim is enabled, all is good, and if a match is found access is granted (JPRO GUI).

However, Azure AD is also limiting the max number of groups in a SAML token to max 150 groups (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims).

This could potentially be problematic for environments where user are a member of more than 150 (nested) groups. Now, from an Azure side, there is no possibility to lift or increase that limit, but fortunately, JPRO has a little trick up its sleeves to work around that: Transitive groups for SSO.

When you enable Transitive groups for SSO, the group claim in the SAML token is actually ignored. Instead whenever a user authenticates to JPRO via SSO, JPRO will do a lookup via the Cloud iDP integration and fetch all the groups the user is a member of from there and match it with the groups defined in JPRO => JPRO Settings => JPRO Users and Groups to calculate access and privileges.

This affects the privileges granted for the account. So make sure to validate the level of privileges the user should get as an end result in view of multiple groups with different privileges.

Now, while SAML may be limited to 150 groups, enabling Transitive groups for SSO may bring a workaround for this, if you enable a custom knob to increase the current default JPRO limit of 150 groups for Cloud iDP lookups. As said, instead of using the group claim JPRO does a lookup to the iDP and if you need more than 150 groups to be returned (in current JPRO version), have a chat with Jamf Support on to see if this can be enabled.

My screenshot below is an example on how this all matches together, based on usernames defined by onpremisessamaccountname, but as said, different attributes can be used. In this example I pass the Name ID (or Unique User Identifier) value based on the onpremisessamaccount in SAML for SSO, I map it to ‘username’ (not email), and for Cloud iDP lookups I make sure to map the username to the same attribute for both the username in general as the one used for Transitive lookups:

Works like a charm!

Now, before I wrap this all up, there is one more thing I’d like to call out here. In my explanation above I mentioned that for enrollment via SSO (User Initiated Enrollment), you do NOT need to configure any accounts or groups in JPRO => JPRO Settings => JPRO Users and Groups, and that you only need to:

  • assign user to the JPRO app in Azure
  • enable SSO for enrollment in the JPRO SSO settings
  • define if you want to allow ‘Any identity provider user’ (well, in practise this is any assigned identity provider user, but ok) or ‘Only this group’

That is correct, but if you only do this, any end user authenticating via SSO to enrol a device will automatically be assigned to the device in the User and Location section of the inventory. They will not be prompted to choose which username to assign to the device.

This is ok in normal User Initiated enrollment workflows, where it is the actual end user who enrols the device. However, some organisations have other workflows in place where company admins or ICT teams are actually doing the enrollment for the end user. This prior to handing over the device to the end user. In such workflow the lack of being able to assign a user during User Initiated Enrollment with SSO may not be handy, as the device then needs to be manually assigned via the User and Location section of the inventory after enrollment. In workflows where profiles are being pushed which rely on usernames or other variables from the inventory, this can be problematic as JPRO would push out the profile before the manual user assignment was done.

In this scenario the way to allow admins or ICT team members to enroll devices for end users via SSO and UIE, is to create a standard user group (or user) in JPRO settings => JPRO Users and Groups, and set it the privileges to administrator.

Doing so will allow those team members to assign the device to the end user:

If of course everything I discussed in this post regarding the mappings, groups claims and attributes matches that is.

That’s it! I hope this clarifies a few things and allows you to connect the dots of how JPRO links all this together.

As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG