Posted on 10-26-2017 05:50 AM
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...
Posted on 10-09-2020 03:27 PM
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.
Posted on 10-12-2020 07:17 AM
Slightly off topic here but important, JAMF should really move forward to support SCIM as alternative to LDAPS.
Please vote up theses request:
Posted on 02-21-2023 06:55 AM
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?
Posted on 02-21-2023 06:57 AM
Yes. I've used it in our dev environment for a while now.
Posted on 02-21-2023 07:02 AM
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?
Posted on 02-21-2023 07:04 AM
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.
Posted on 02-21-2023 07:06 AM
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?
Posted on 02-21-2023 07:09 AM
Are you using it inside a enrollment customization or just prompting for auth in the prestage?
Posted on 02-21-2023 07:10 AM
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.
Posted on 02-21-2023 07:16 AM
Should work. I guess make sure under Access on User-Initated enrollment that All LDAP users is allowed.
Posted on 02-21-2023 07:18 AM
This is already the case.
Posted on 02-21-2023 07:20 AM
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.
Posted on 02-21-2023 07:21 AM
For username there is "userPrincipalName" which should be the mail address which I'm also using in the authentication.
Posted on 02-21-2023 07:25 AM
and to confirm if you do a test search for the email address it comes back with a user?
Posted on 02-21-2023 07:26 AM
Yes, this is working fine. We are already using the LDAP to fill the user and location inventory details with the SSO enrollment customization.
Posted on 02-21-2023 07:28 AM
Do you have password hash sync enabled in Azure?
Posted on 02-21-2023 07:37 AM
No, the customer has cloud only accounts, no hybrid environment.
Posted on 02-21-2023 07:41 AM
Posted on 02-21-2023 08:41 AM
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.
Posted on 02-21-2023 08:52 AM
Yeah once the sync is enabled, a password change is needed.