In today’s post I’d like to go through adding LDAP integration to Jamf Pro, with Microsoft Active Directory as Directory server, and more specific: share the default settings in case you have to configure the LDAP integration manually. So no magic in this post, just sharing the default workflow and AD mappings which might come in handy. I’ll share some other Directory Service mappings soon, such as freeIPA, OD,…
Before we start diving into the settings, just remember that, if you are a Jamf Cloud customer, you will first need to grant Jamf Cloud access to your AD server. Either by Whitelisting the IP adresses of Jamf Cloud, or by installing a Jamf Infrastructure Manager or ‘JIM’ in your DMZ. See my post on ‘JIM’: )
Once this is done, you can go into the settings of Jamf Pro and configure the LDAP connection using the wizard. Jamf Pro will automatically try to fetch the Directory settings and mappings.
Note: if you are using LDAPs and/or JIM, you will need to go for the manual option (see below).
When using the Wizard, you will be asked to enter the LDAP server hostname / IP adress, and authenticate with a service account. A service account is preferred over a normal AD account, as the password is most likely set to never expire. A normal AD account probably has an expiration time of 90 days set to the password, which means your LDAP account would break when the password changes, and every 90 days you would need to reconfigure the LDAP link in Jamf Pro (or at least update the password).
Depending your network, as well as some AD server settings, it might be that the wizard is unable to connect. In that case you will have to configure the LDAP connection manually (see below).
Next the wizard is going to ask you 2 existing AD user accounts and 2 existing user groups. This is to test if the users/groups exist, and check the group membership. You will be provided with the query results to verify.
First the test users:
Check the mappings Jamf Pro is returning, change them where needed and hit next:
Next the 2 test groups:
Even if there are some mappings or group memberships which need to be corrected, you can still save and change the settings later.
As said, using the Wizard might not always be possible. If your are using LDAP (without SSL) and the wizard does not work, or you are using JIM and/or LDAPs (LDAP with SSL over port 636), you will have to configure the LDAP integration manually. No panic, it’s just a little bit of extra work!
To do this, just select “Configure Manually” instead of selecting your Directory type and hit next:
Next you will have to add the connection settings, service account credentials and mappings.
If you are using JIM to allow Jamf Cloud to connect to your LDAP, you will have to select the enrolled JIM server, and choose a port. See my previous post about JIM. For LDAPS you will need to enable SSL and upload the AD certificate.
If JIM and/or the SSL cert were previously configured/created correctly, these settings should be quite straight forward. The extra work in this manual LDAP integration, compared to the wizard, is adding the correct attribute mappings. But don’t panic, chances are relatively high that you, or your AD admin, did not change too much of the default AD attributes, so let’s go through the default mappings and settings. Crosscheck with your AD attribute editor in case you see incorrect mapping results!
Server and port: add host name of the AD server and relevant port. 389 for LDAP, 636 for LDAPS.
Enable LDAP Proxy Server: select your enrolled JIM server if any and choose a port, telling JIM to listen on for incoming LDAP queries.
Use SSL: If your are using LDAPS, enable SSL and upload the certificate
Finally, select the authentication method and enter the distinguished username of the service account you want to use. Unlike when using the wizard to add an LDAP connection to Jamf Pro, the username needs to be the ‘distinguished’ user name here. This should be something in the format of: “CN=user name, CN=user group, DC=Domain, DC=com”. Check your AD attribute editor or a directory utility for the exact distinguished name of your service account.
Next will be the mappings. Add all mappings (user, group and membership) before saving and testing the LDAP connection.
Object Classes: most likely organizationalPerson or one the following attributes: person, top, user.
Search base: the level in the AD hierarchy at which you want Jamf to start searching for LDAP users/groups. This should be something in the format of “OU=the_OU_you_want_to_search_in, DC=your,DC=domain,DC=com” or just “DC=your,DC=Domain,DC=com” if you want to search in the entire AD.
Have a look at your AD attribute editor or directory utility, at the level you want Jamf to start it’s queries, to find the distinguished search base.
Next are the exact user attributes:
USER ID: most likely ‘uSNCreated’
USERNAME: most likely ‘sAMAccountName’
REALNAME: most likely ‘displayName’
MAIL: could be ‘userPrincipalName‘, but check in your AD attribute editor (in my test AD I also have it set to ‘mail’)
Append to email results: most likely left blank (depends if the ‘MAIL’ attribute returns results as ‘username’ or ‘firstname.lastname@example.org’. Most likely to be the second option, but if not, you can add ‘@domainname.com’ here)
Department: see note below
Building: see note below
Room: check your AD attribute editor
Phone: most likely ‘telephoneNumber’
Position: most likely ‘title’
USER UUID: most likely ‘objectGuid’
Note: Jamf Pro has built-in Departments and Buildings (see Jamf Pro Settings – Network Organisation). It is possible to map these to existing departments and buildings of the AD, by adding the corresponding attributes in the mappings above. However, in order for this to work, all existing values for those attributes in the AD, must be created as Buildings/Departments in Jamf Pro. Jamf will only match existing values. Have a look at this script on GitHub to automise this process.
And the same for the groups:
Object classes: most likely ‘group‘, or ‘top‘
Search Base: similar to the user search base, if your groups are created on the same level as the users
Group ID: most likely ‘uSNCreated’
Group Name: most likely ‘name’
Group UUID: most likely ‘objectGUID’
Finally you’ll need to tell Jamf how to check if a user belongs to a specified group, when checking group memberships. By default the Group Membership Mapping will be ‘memberOf’, with the use of ‘distinguished name’ and ‘recursive searches’ (if you have nested groups).
Once you have your LDAP integration saved in Jamf Pro, by using the wizard or adding the configuration manually, you will be able to test the mapping with test button at the bottom.
Search for some users/groups and check some memberships of well known group members to be sure the LDAP queries are returning the expected data.
If everything looks fine, you should be good to go to use the LDAP related features in Jamf Pro.
That’s it folks!
As said, nothing really special in this post, just sharing the default AD mappings in case someone would be looking for it, without having immediate access to the AD attribute editor.
As usual, if you liked this post, hit the like button, tell your friend about this blog and leave a comment below. Don’t hesitate to make suggestions, or corrections!