Skip to main content

Hi,

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.

Setup

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.

Mapping
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!

@hdsreid

If the jamf server understood those group, I could just add the "support team group" from our AD groups and them match that to a jamf pro group access for the support team, as an example. Then all our sub orgs could manager their own access and our Jamf admin team would not have to add and remover users as the join and leave the our organization.

C

@gachowski

sorry i think my post was a bit too rhetorical. i want to add them for the same reason, however i can't figure out how to get it working. basically what i am asking is, it doesn't seem to allow for access control via ldap groups, so why does the ldap groups option even exist? what can it actually do if not access control?

@majaazbaig If you look at the user mappings in the original post, you'll see that we do not use SAMAccountName at all in the mapping, only other attributes. As Username in Jamf Pro, for instance, we use the mail attribute, as User ID we use uSNCreated. Or did I misunderstand something?

@hdsreid There is a possibility to use LDAP groups in the Policy scope, under Limitations, and I think that works, as opposed to the access group setup.

@eirikw - what is the benefit to LDAP+SSO vs LDAP only? I work for a very small organization and, for reasons I will not go into here, we have a full JamfCloud instances vs JamfNow even though our footprint is quite small.

At this time I do not anticipate enforcing login for self-service and the primary interest in connecting to AzureAD is for the purpose of assigning machines to employees for asset management. The immediate detractor I can see to LDAP only is self-service enrollment.

In regard to Groups & SSO

Hi All,

Just an "FYI" Group Membership claims do work with Azure and Jamf Pro, Azure just passes the Group Object ID instead of the plaintext name. In order to utilize groups you need to get the Object ID of your group, then create a standard group in Jamf Pro using the Object ID as the name of your standard group.

I.e. Azure Group = Jamf Pro Admins has an Object ID of 1001. Create a standard group in Jamf Pro with a name of 1001

Jamf will match the user being asserted via SAML as belonging to that standard group, so long as the SAML assertion contains the Group's Object ID (which it should if you followed this article and edited the app manifest and the user is actually a member of the group).

You can find a groups object ID Under the Group overview section in azure.

Hi All,

We have a step-by-step guide on configuring Azure AD (Azure AD Managed Domain Services) in Jamf Pro as an LDAP source, as well as using Azure AD for Single-Sign On.

Take a look at it here - https://hcsonline.com/support/white-papers/a-guide-to-integrate-azure-active-directory-with-jamf-pro

You are a life saver, I'm currently looking into this and thought of looking it up here and voila!!!

Hi All,

What about this?
https://marketplace.jamf.com/details/azure-active-directory/

seems like simple setup, but having issues getting it to work.

@nicholasmcdonald Nicholas,

I don't suppose you'd be so kind as to elaborate on your post where by being in an Azure AD group should get you access when configured with SSO.... I'm trying to configure a new instance, and do not want the complexity of LDAPS on Azure if I can help it (we are a small Jamf installation, so I don't need all that user info in Jamf, I already have it in Azure AD).

I keep hitting a wall with the app, saying that I don't have access, though I im in the group of which the objectGuid matches the name of the standard group within Jamf. I can see in my SAML response when testing that the group is indeed present (amongst a long list of other groups of which I'm a member). Any pointers would be very welcome!

Currently as we sit, our previous network engineer decided to make a read only domain controller and connected it to our dmz. It's only current role is configured for our pre-stage enrollment where we require authentication and so our ldap settings in Jamf are set to point to the read only domain controller for authentication only.

We want to remove that read only and have the users authenticate against Azure, will the guide above accomplish this? We're not so concerned at the moment about making sure we have SSO or the ability for O365 users to be able to log into Jamf Pro.

Thanks

@slocke The simple answer is Yes. You just wouldn't be doing the SSO part until you are ready.

@slocke this is also a very good guide. Azure as LDAP

Jamf really should implement provisioning to follow best security practices.

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.

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

https://www.jamf.com/jamf-nation/feature-requests/7931/add-support-for-scim-system-for-cross-domain-identity-management

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?

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.

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?

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. 

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?

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?

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. 

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.  

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


This is already the case.

Terms & ConditionsCookie settingsAccessibility statement