A guide to JSS Azure AD integration (LDAP + SSO)

New Contributor III


I see that a growing number of organizations are migrating on-premise AD to Azure AD. Therefore, I decided to share our experiences using Azure AD as a authorization provider for Jamf Pro.

First, LDAP is necessary in order to get user and group lookups to work. This means, you have to set up the service Azure Active Directory Domain Services with external LDAPS support. At this time, this service is available for all Azure subscriptions except CSP subscriptions. It is easy to set up, but requires a DNS entry (a name that points to the public IP address of the new LDAP server) and an SSL certificate that works with the given DNS entry.

So, with this working, you need to know that LDAP login with Azure ADDS is possible, but the users' passwords must be reset before it works. Also, the new passwords operate on another time schedule than Azure AD's password policy, so they may stop working. Bottom line: Don't use AD LDAP as login mechanism in Jamf unless you really have to. But use it for smart groups, user lookups and so on. The LDAP setup is really simple, but there are some distinct differences to other LDAP setups.

In our example, we are using the AD domain "dibk.no", so we have defined an LDAP server in the AADDS setup. The port will always be 636, and you need to upload the SSL certificate, both to Azure and to the Jamf server, like we have done here.

Use the simple authentication type, and make a service account in Azure AD to authenticate with. Beware that this account must have its password set AFTER you set up Domain Services in order to work. The account must be specified as 'user@domain', not the DN type suggested.

The mappings were a bit time consuming to figure out.
The User Mapping is mostly standard, but beware to use the Search Base "OU=AADDC Users, dc=yourADdomain, dc=com". Also, use mail as Username.

Same thing for User Group Mappings.

User Group Memberships uses the User object to store its memberships, in the attribute MemberOf.

And that is that for setting up LDAP with Azure AD. With this setup, it should be possible to login to Jamf Pro with a O365 account, provided that the password is reset after adding Domain Services to Azure AD.

Single Sign-On
For Azure AD SSO, most of the work is done setting up a custom enterprise application in Azure AD. And to be able to add a custom enterprise application, you need to have at least a trial license of Active Directory Premium.

So, provided you can create a Non-Gallery Application in your Azure AD (under Enterprise Applications > All Enterprise applications), do so. Make a name, like Jamf Pro SSO, and continue.

You will be asked for the homepage of the application, and it should be like "https://your-jss-server.company.com/". User assignment required should be 'No'.

Under Single Sign-On, choose "SAML-based Sign-On". Specify the following:

Identifier: https://your-jss-server.company.com/saml/metadata
Reply-URL: https://your-jss-server.company.com/saml/SSO
User Identifier: User.mail

Generate a new signing certificate, and make sure to download the resulting Metadata XML for later. Or, you may do it later, but it is needed for setting up the JSS.

Now, go back to Azure Active Directory in the Azure Portal, and choose your new application from the list in App Registrants. Under Properties/Settings, make sure that:

Home Page URL: https://your-jss-server.company.com/
Logout URL: https://your-jss-server.company.com/logout.html

Also, under Reply URLs, there should be an entry of https://your-jss-server.company.com/saml/SSO

Back to the main page of the App Registrant for your Jamf SSO, you should be able to click to edit the Manifest. Do so, and make sure that the following line:

"groupMembershipClaims": null,

instead reads:

"groupMembershipClaims": "All",

Remember to click Save.

Back in Jamf Pro Single Sign-On Settings
Not much setup necessary. Set Identity Provider to "other", give it a name and upload the metadata XML from Azure AD under Identity Provider Metadata Source, make JSS generate a signing certificate, and specify the same Entity ID as in Azure ID (eg. "https://your-jss-server.company.com/saml/metadata").

Also, you need to specify the User Mapping in SAML and JSS as, respectively, NameID and Email. The Group Attribute Name (which doesn't work, BTW) should be "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups". The RDN Key for LDAP Group should normally be "CN", but for Azure AD it should actually be objectGUID instead. Either way, it does not work at this time.

That should be it. You should now be sent to Microsoft to log in, and if successful, Jamf Pro will let you in afterwards.

In our example, we have avoided using SSO for Self Service, but use it for JSS and Enrollment. If SSO fails (because you didn't do it all correctly) you can always login as an admin using the 'secret' URL stated at the top of the page in SSO setup (usually, just add "?failover" to the server URL). Pro tip: keep a local (non-LDAP) admin account handy for such scenarios...

Good luck!


New Contributor

My question is. Is LDAP necessary for the SSO working? I'd rather have the SSO login--> Let Jamf Setup the User after authentication and then I can assign the Permission/Role. I had Jamf engineer setup LDAP and I think the issue of SSO not working properly is due to LDAP in the Mix. Any advise would be helpful. NOTE: I am not concerned about populating User Information from Azure AD but would rather have SSO working in the most simplest form. LDAP has some other Password Hash issues and I'd rather not utilize that.

Contributor III

Slightly off topic here but important, JAMF should really move forward to support SCIM as alternative to LDAPS.
Please vote up theses request:


Contributor II

Can I use the AADS LDAPS service for authentication in the PreStage enrollment? We have massive issues with enrollment customization (SSO) and I hoped I can use LDAPS directly for authentication?

Yes.  I've used it in our dev environment for a while now.

Contributor II

I get `Your credentials are either missing or wrong. Try again` and I don't know why. The credentials are correct. Does the LDAPS service needs to be accessible not only from the Jamf Pro server? At the moment only the Jamf Pro server can access the LDAPS service. Any other settings which needs to be done?

If you are using an IP restriction, you need to make sure you have all the IPs for JamfCloud Outbound in the restriction.  They updated the list of IPs in late december or early january. 

We are still on-prem and the LDAP connection is working fine, we can do lookups but the authentication is not working.

Do I have to disable SSO or can I leave it enabled? Any settings needed in the User-Initiated Enrollment page? Do I need to add an LDAP group with "Enrollment Only" privileges?

Are you using it inside a enrollment customization or just prompting for auth in the prestage?

Just prompting for auth as enrollment customization is broken and we are working with Jamf support on this case for about 5 months and I hoped I can switch over to LDAP only as a workaround. 

Should work.  I guess make sure under Access on User-Initated enrollment that All LDAP users is allowed.  

This is already the case.

What attribute do you have set for Username within the Azure Ldap mapping?  I would assume you are using the same when trying to auth.


For username there is "userPrincipalName" which should be the mail address which I'm also using in the authentication.

and to confirm if you do a test search for the email address it comes back with a user?

Yes, this is working fine. We are already using the LDAP to fill the user and location inventory details with the SSO enrollment customization.

Do you have password hash sync enabled in Azure?

No, the customer has cloud only accounts, no hybrid environment.

Still needs to be enabled from my understanding.  DBrowning_0-1676994016020.png

Link for cloud-only user accounts.  

Ok, I think that was the issue and also there was a setting called "LDAP Signing" or something. But it seems we need to reset the password for LDAP to work.

Yeah once the sync is enabled, a password change is needed.