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

eDooku
New Contributor III

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
03dfa2fbe27547df9a1ca2d1b67e0cdb
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.
dcdad853771e41f5b077a929324908fd
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.

15bb057b69944d608279469a64a48b75
Same thing for User Group Mappings.

8cf67fda8e1d46a8b8f31c3c71c9fde1
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
331d109b74d149a4b34a5cb2c2726878
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!

41 REPLIES 41

blake_pierce
New Contributor II

Thank you so much for posting this guide!

eDooku
New Contributor III

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?).

alelap
New Contributor

Hello!
Is it possibile in the same way to configure SSO + the classic Windows Server LDAP?

eDooku
New Contributor III

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.

canary_
New Contributor

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?

Thanks!

eDooku
New Contributor III

Hello,

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.

BrentSlater
Release Candidate Programs Tester

Hi Guys,

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.

Cheers

eDooku
New Contributor III

For our setup, I'm sorry, I don't know. We have chosen not to use SSO or login for Self Service, and that suits our purposes. When our enrolled devices starts Self Service, it just pops up.

rseeley
New Contributor III

For the virtual network being used by the Azure Active Directory Domain Service, did you configure NSG to minimize the IPs that can communicate to it? If so did you use these?
https://www.jamf.com/jamf-nation/articles/409/permitting-inbound-outbound-traffic-with-jamf-cloud

eDooku
New Contributor III

43aef8f62cf84aa6a482a1761a68cd5e
I did, in fact, configure NSG to minimise the IPs. And I used the list you link to. Since our organisation is being served from the EU, I opened for the IPs from the EU Frankfurt list, as seen in the image.

gachowski
Valued Contributor II

I think there is a new app in Azure.....

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-jamfprosamlconnector-tutorial

C

rseeley
New Contributor III

@eirikw Pointed out something pretty important. Ran into this error after completing the setup:

9ea07c92aad44b07a25fb8ee4023008b

The resolution was to follow his advice:
"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."

nateburt
New Contributor III

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!

mirrorweb
New Contributor

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

KyleEricson
Valued Contributor

I haven’t test SSO with Self Service, but I have it for enrollments and console logins and I have never seen this issue.


Hire me as an independent contractor.

eDooku
New Contributor III

@nateburt You may try investigating the contents of "~/Library/Caches/com.jamfsoftware.selfservice.mac". It seems the only location Self Service stores any files. It would be the location for any SSO login cookies.

Cayde-6
Valued Contributor

Hi,

I've followed your advise step by step but I am getting a Username or Password error when testing the connection to our Azure ADDS LDAPS.

We've tried both a DN and user@domain, the user account has global admin so it's not a permissions issue.

Can you suggest anything else to try?

eDooku
New Contributor III

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.

Cayde-6
Valued Contributor

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?

eDooku
New Contributor III

Good.

As far as I know, there's no way of binding macOS to O365 (alias Azure AD). I mean, with DEP enrollment, you may end up with a username and password identical to that in O365, but no AD binding. Azure AD is still not a fully functional AD.

majaazbaig
New Contributor

I want to know what are the other attributes that jam f pro using for the azure Ldap other than the SAM Acoount name i want to know what other attributes are being accepted by the jam f pro.

majaazbaig
New Contributor

what other attributes jam f pro uses for the mapping from the azure ldap apart from sam account name

hdsreid
Contributor III

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

gachowski
Valued Contributor II

@hdsreid

I am only 50% sure but I don't think the Jamf Pro can do that... I would like for it to read and use Ldap groups for access so we could just use our ldap groups for Access control.

C

hdsreid
Contributor III

@gachowski

What is the purpose of importing groups in the Accounts and Groups section?

gachowski
Valued Contributor II

@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

hdsreid
Contributor III

@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?

eDooku
New Contributor III

@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?

eDooku
New Contributor III

@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.

jrbaker1
New Contributor

@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.

nicholasmcdonal
New Contributor III

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.

nicholasmcdonal
New Contributor III

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

ikenna83
New Contributor II

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

esv
New Contributor II

Hi All,

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

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

davidjbarr
New Contributor

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

slocke
New Contributor II

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

DBrowning
Valued Contributor II

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

DBrowning
Valued Contributor II

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

petestanley
New Contributor III

Jamf really should implement provisioning to follow best security practices.