Following the default Active Directory mappings, and freeIPA, let’s have a look at another way of adding LDAP integration to Jamf Pro: Jumpcloud.com

Just for the record, before going any further: Jamf, Jamf Pro, JamfCloud and now… a blogpost about JumpCloud? Don’t get confused, JumpCloud is not a Jamf product 🙂 . It’s a 3rd party Directory-as-a-service provider.

As it’s not my intention to give any advise on what 3rd party tool or solution you should use, I’d like to invite you to have a look at their website and see if the provided services are a good match for your environment and deployment needs.

However, my goal here is to “quickly” run through the steps to integrate it in JamfCloud. Also, for those who don’t have a JumpCloud account yet, good news: you get 10 user licences for free, forever and no credit card needed!

Once your Jump Cloud account is up and running, let’s have a look at how to integrate in Jamf Pro, including the mistakes I made initially.

Log in to the administrator portal:

 (Jump Cloud has a user portal and an admin portal, don't get confused. The user portal is used for Single Sign On purposes and give user access to their applications for instance, while the admin portal is where you, logically, manage the server settings and functionality).

Once logged in, you will be asked to create a user to get started, so let’s go ahead and create the user (or “service”) account which we’ll use to give Jamf Pro access to the LDAP in JumpCloud (Or if you already used JumpCloud before, just click the “+” button to create a new user).

Give the user a First and Last name, a username and email (mandatory). Next, “enable as LDAP Bind DN”, in order to allow this user account to search in the LDAP service.

It has been a while since I initially created my JumpCloud account, but in the past you had to enable the LDAP service. It seems that this changed overtime. Creating a user in JumpCloud automatically enables the the LDAP service, and adding a user as LDAP Bind DN automatically adds it to the LDAP Directory (see below on how to do this for other users…).

Next, before going into Jamf Pro to configure the LDAP integration, let’s first create some test users and groups:

I created a user group and only configured the first “Details” page. No need to add this one as a Bind DN, unless you want to use this user account as a “serviceaccount” for LDAP. 

Note: there is one more thing you have to do in order to make the user available in the LDAP directory, but I’ll come back to this (see below).

Next we go to Groups (left sidebar) and click on “Create a Group of Users”:

Give the group a name, and select ” Create Linux Group for this user group”. Creating the Linux Group is important (see below).

Adding a Linux Group allows you to give the group a Group GID (see below).

Next, you’ll want to give the group some members, as JumpCloud is not creating empty groups in LDAP. Again more about this below.

In the meantime I created another user (“heisenberg”) and added it to another group (“breakingBad”).

At this stage I (mistakenly) assumed that everything was set to make it work in Jamf Pro, so let’s have a look at the settings I initially added to Jamf.

To add our LDAP Server in Jamf Pro we go to: setttings -> LDAP Servers -> add “+” -> Configure Manually

JumpCloud allows to connect over SSL, so give the LDAP server a name and add the default JumpCloud settings and port as stated below:

server = ldap.jumpcloud.com
port = 636

In order for SSL to work however, we’ll need to upload the JumpCloud SSL certificate, which we’ll have to retrieve from JumpCloud first. The easiest way to get it, is by using the Terminal command below. The certificate will be put in the /tmp folder of your Mac.

$ echo -n | openssl s_client -connect ldap.jumpcloud.com:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/jumpcloud.chain.pem

Check your /tmp folder of your Mac and move the cert to another location (Desktop for instance).

$ cd /tmp
$ ls -lsa
(to check if the cert is there and to verify the name: jumpcloud.chain.pem)
$ mv jumpcloud.chain.pem /Users/YOURUSERNAME/Desktop/
Upload your JumpCloud certificate to Jamf Pro
(Just ignore the cert I already had on the screenshot, as Jamf Pro lists all already existing certs when configuring SSL for another LDAP integration)

After uploading the cert select the following Authentication details:

Authentication Type = simple
Distinguished Username = check your “service / Bind DN account” in JumpCloud. Should be something like:
“uid=XYZ, ou=users, o=xxxxxxxxxxxxxxxx, dc=jumpcloud.com”, where “o” is actually your organisation ID in JumpCloud
password = password of the service / bind account

Next, just like any other LDAP integration in Jamf Pro, will be the mappings.

First, User Mappings:

Followed by the User Group Mappings:

Here again, I made one mistake by copying the mappings from an old JumpCloud article. I used groupOfNames, instead of posixGroup, but more about that below.

Finally, the User Group Membership Mappings:

So, ready to test… all should be good to go! Well, actually, it isn’t…

With the JumpCloud configuration as above, Jamf Pro does not seem to find any users…

or groups…

Why? Well, while adding users to JumpCloud actually enables the LDAP service as such, users and groups are not automatically created in the LDAP directory. Or to say it differently, users and groups are not automatically bound to any resources, such as JumpCloud LDAP. This has to be done manually on a user/group level in JumpCloud.

After defining the group members, the group can be bound to one or more resources. With all resources, access is implicit deny. In order to grant access, they must be explicitly bound to the resource.

These resources are generally accessed by groups of people so direct binding on the user object - while possible - is generally not recommended. 

Binding a group to a directory is possible even if a group member has already been granted access via a direct binding in the User details.

More info on: 
Getting Started: Users
Using JumpCloud's LDAP-as-a-Service
Binding Users to Resources
Getting Started: Groups
Creating LDAP Groups

Binding the user to JumpCloud LDAP (user level):

Add the user to the LDAP Directory by selecting JumpCloud LDAP under “Directories”.

Or group level:

Add the group to the LDAP Directory by selecting JumpCloud LDAP under “Directories”.

JumpCloud is now correctly configured to allow JamfPro to query the directory. So let’s put the settings in JamfPro to the test…

User Mappings:

Group Mappings:

And finally, the User Group Membership Mappings:

So, all looks good right? Well, actually NO, not really! Once everything seemed to work, I noticed that, when testing the group mappings, Jamf didn’t return any GID or Group ID…

Maybe not important, depending your deployment, and what you are trying to achieve with JumpCloud, but why doesn’t Jamf return the GID numbers when fetching LDAP groups from JumpCloud with the above settings.

But why are we missing the gidNumber? Well, first of all, FYI, Jumpcloud made a change on the platform (since I used it for testing last year), where they migrated from “group tags” to actual “groups” (More info in this here), but more relevant is the difference between the “groupOfNames” attribute, and the more UNIX way of using “posixGroup”.

While the Object Class “groupOfNames” works to find the groups, it actually doesn’t fetch all the required attributes, such as gidNumber. Instead, the Object Class “posixGroup” should be used.

A detailed discussion on posixGroup, groupOfNames, etc… would drift me again too far away from the actual goal of this post, but instead of using “groupOfNames” I changed the User Group Object Class to “posixGroup“:

Change the Object Class to posixGroup (instead of groupOfNames)

FIXED!

Just for the record, I’m querying ‘got’ here instead of ‘gameOfThrones’ as the Linux Group Name has to be unique from the normal Group Name (see creating groups in JumpCloud above).

But, changing the group mapping actually also changed the User Group Membership mappings… the “member user mapping” for “groupOfNames” is “member“, while the one for “posixGroup” is “memberUid“:

So let’s correct this now, to fix the User Group Membership Mappings:

Change the “Member User Mapping” to memberUid (instead of “member”)

Now you should have a fully functional JumpCloud LDAP integration in Jamf Pro!

One more thing: While troubleshooting, I came across this very handy tool to quickly check JumpCloud LDAP attributes: have a look at this GitHub script!

That’s all folks! Have a look at jumpcloud.com for more information about this Directory-as-a-service, and as always, if you liked this post, hit the like button, tell your friends about this blog, and leave a comment, remark, correction or suggestion below!

Oh yes! JumpCloud as SSO provider in JamfCloud? Right! Coming up in one of the next posts 🙂

Grtz,
TTG

Print Friendly, PDF & Email