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.
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:
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...
A little side-note
Even with a fully working SSO + LDAP setup, you (especially admins) will meet an error message from time to time, claiming that there was an SAML error stopping your login. This is due to some token renewal magic not happening correctly (probably) on the JSS side.
Luckily, there is an easy fix: Go to your Azure or Office portal and log out the session. Afterwards, going to the JSS will prompt a new SSO login, and all is well again. The error message might also be avoided by actually logging out of JSS when finishing up an admin session (but who really does that?).
Yes, it should be entirely possible. If you, for instance, have a setup with synced AD, you may use Azure AD SSO and local Windows AD LDAP. No need for Azure AD Domain Services if the on-premise LDAP server is reachable by the Jamf Pro Server.
Other on-premise solutions are described in the Knowledge base articles, just search for SSO.
Hi erikw, thanks a lot for posting this guide.
We're in a similar situation: we're trying to setup Jamf Pro with our Azure AD. We've setup Azure AD SSO for multiple other integrations (salesforce for instance), but JSS seems to be a different case.
From your article, I understand that in order to have user mappings, the LDAPS integration is required. Is my understanding correctly? I was hoping to provision the users automatically when SAML authentication succeeds.
Also, when a user enrolls his system via self-enrollment, authenticated via SAML, is his device then automatically linked to the user that was found through authentication?
As I read it, you understand correctly... 😉
Jamf Pro does do things a little bit differently. It is, I would say, totally dependent on LDAP integration in order to populate user data.
The user is, as I understand it, created automatically in Jamf Pro on first successful SAML authentication, and the user's info is then fetched through LDAP user mappings. In normal SAML setups, the server would, I believe, do separate SAML calls after authentication to fetch the user info from the SSO provider, but Jamf Pro only uses LDAP for this. At this time, at least. The upside is that the LDAP search is much faster than the more cumbersome SAML/SOAP dialog, the downside is that you have to pay additional fees for the LDAPS service in Azure AD.
When a user enrolls his system via self-enrollment (or DEP) and authenticated with SAML, the user will be automatically created in Jamf Pro (if it doesn't exist), the user data populated from LDAP, and the device will be linked to that user. Also, if you enroll a device using a privileged Jamf Pro account (admin user), you are able to choose which user to bind to, but again, that user search is done through LDAP...
I hope this helps clarify a bit.
We are looking into doing SSO for our jamf pro instance here but I am just wondering what the expected behaviour is for users when opening Self Service?
We currently have AD integration working polling our on premise AD Controller but we are in a hybrid Azure AD environment.
Thanks all for this useful thread. Has anyone who is using SSO login to Self Service found an equivalent to logging out of the Azure or Office portal? That solution works great for the admin interface with a typical browser, but I now have a "Single Sign-On Error" in Self Service as a result of choosing 'stay logged in'. Oops!
Is there going to be a proper fix for the SSO logon issue? It is ok for admins to logout of Office 365 when they get this error but it is not something I want users to see as their first experience with Jamf. I've only just got Jamf Pro setup in the last week and so now want to send all my users a self enrolment email but this error is going to cause me problems. We use Azure SSO for over 22 different online services and I've not had this issue anywhere else. Thanks Phil
First: The only way to authenticate with AADDS LDAPS is with 'user@domain' and password. It will not work otherwise.
Also, the password mechanism in AADDS is different from Azure AD, so there might be delays and unexpected password expiries that does not reflect in Azure AD. The account login may work in the Office Portal, but not with LDAPS.
If I understand you correctly, you are using a global admin account as the LDAP User Account in the Jamf Pro LDAP setup? It would work, but you shouldn't need to. Instead, create a separate account without Office licenses or any other permissions than 'Login allowed', for instance 'jamf@yourdomain'. Create the account, set a safe password and wait for about 15 minutes for the AADDS to catch up. It should work.
Otherwise, if you insist on using the global admin, you'll probably need to reset the user's password in Azure AD. If you login to O365 Admin Portal as a different global admin, you are able to reset the user's password to the same it had before. Wait 15 minutes to allow it to sync with AADDS, and then proceed to testing the LDAP service in Jamf.
If it still does not work, it might be that Azure AD cannot sync to AADDS. Check for error messages in AADS 'health'.
Also, check that the AADDS service does not report any errors with it's 'health'. If it can't synchronize with Azure AD, there will be problems.
Thanks for the response, we had to change our user mappings slightly
We added top and user to the object classes and the username field mapping to userPrincipleName
On a different note, how do we test logging into a mac with an Office365 account? Is there some bindings that we need to fill out in Active Directory Bindings under global settings or a config we need to push out?
I have SSO configured with Azure AD
I've found that I can import users from LDAP and then they can log in on SSO through Azure. We have a hybrid Azure AD Connect system in place. This has made it easier to not worry about manually provisioning accounts. One thing I do wish we could do would be to import an LDAP group and have all of those users be imported, but I have yet to find a way to do that
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.
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?
@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
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.
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
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.