UPDATE – Thu 11 Oct 2019: see bottom of this post

UPDATE – Thu 7th May 2020: see bottom of this post

What? Another LDAP related post? Well yes, while I still have many other pending topics, I thought it might be interesting to share this “LDAP flavour” as well. As Okta is one of the popular identity providers, chances are high some of you might be looking into integrating it in Jamf Pro, and it fits nice into the series of other LDAP related posts like JIM, Active Directory, freeIPA and Jumpcloud.

I’ll leave LDAP integrations behind me after this one, promised! Or maybe not, maybe I should add Azure AD as well, we’ll see 🙂

First of all, we all know Okta as an identity and Single Sign On provider, for which Jamf already has a KB article, but apart from other already released features, their preview or early access list has some cool stuff in development.

And one of those early access features which triggered my interest, is the LDAP interface.

Before we continue however, I’d just want to stress on the fact that we should all honour the “preview/early access” status of anything discussed in this post. Okta has not communicated any final release dates, or promises on the exact functionality. My intentions with this post are just to test how the feature would integrate into Jamf Pro… taking it’s current state and current Jamf Pro functionality into account. Nothing more. See it as a proof of concept.

So, that said, let’s have a look at Okta and LDAP.

Okta already has the Okta LDAP Agent, which allows you to authenticate with LDAP users through Okta. See diagram below, and more info about the Okta LDAP Agent here. Long story short, end users are authenticating with LDAP credentials to Okta, and Okta handles the actual pass-through towards the LDAP server.

This means that it uses an on-premise LDAP server, and the Okta LDAP Agent inside the Firewall, to provide identity services based on the directory account on the backend. An awesome tool for integrating Okta within your existing directory environment, or use it as Single Sign On provider in Jamf Pro (when authenticating users/administrators in Jamf Pro Server, Self Service or User-Initiated Enrollment).

However, for specific features, such as assigning devices or limiting scope to LDAP Users/Groups, or authenticate users via LDAP instead of SSO (during DEP enrolment for instance), Jamf Pro also has the possibility (and/or requirement) to connect to backend LDAP servers directly.

And while some environments might need to keep their Directory Server on-premise, some might see this as an overkill for what they actually need. In this case, you might want to consider migrating your unnecessary, on-premise, LDAP or AD servers to the cloud (or at least your users).

And this brings us to the Okta LDAP interface. If keeping or managing an on-premise LDAP server isn’t something you want to do, the “Okta as an LDAP in the cloud” solution, using the LDAP Interface, might be an option to consider (as an alternative for JumpCloud, see my previous post).

But, that’s not all! Apart from just allowing your “Okta Users” (users within your Okta Universal Directory) to authenticate over LDAP (instead of via Okta SSO), Okta also added MFA, or Multi-Factor Authentication. Yes! MFA over LDAP! Not something you would expect when thinking about the LDAP protocol.

This actually made me think about additional security when enrolling devices into Jamf. Not only when doing User Initiated Enrolment, but also with DEP. You might have seen the fuzz about the “DEP serial hack“. Whether that’s really a big concern or not, I’ll leave it in the middle, but maybe adding MFA to your enrolments might give you your good night sleep back.

Let’s come back on this below, first the LDAP part.

As said, the LDAP interface is an Early Access feature, for which you need to contact Okta Support to have it enabled. More info here.

Once you have the LDAP interface functionality enabled, you can integrate it as an LDAP server in Jamf Pro. Hereby the basic mappings which worked for me:

First, as usual, the manual LDAP settings:

Server: orgname.ldap.oktapreview.com
Port: 636
Select SSL ( No certificate needed)

The distinguished username should be something like: “uid=emailadress,dc=orgname,dc=oktapreview,dc=com” 

This “service account” needs to be an admin, but can be an “Okta Read-only admin“.
Also, make sure that this account does NOT need MFA to authenticate through Okta.

Very important, Okta LDAP interface does NOT support Wildcards yet!
Disable it, or your LDAP integration will not work.

Next the User Mappings:

Object Class: inetOrgPerson
Search Base: dc=orgname,dc=oktapreview,dc=com
Search Scope: All Subtrees
User ID: uid
Username: uid
Real Name: cn
Department: department
Position: title
User UUID: objectGUID uid (recent support case identified this change to fix Self Service issues with this integration)

… the Group Mappings:

Object Class: groupofUniqueNames
Search Base: dc=orgname,dc=oktapreview,dc=com
Group ID: uniqueIdentifier
Group Name: cn
Group UUID: objectGUID

And finally the User Group Membership Mappings:

Member User Mapping: UniqueMember

Only select “Use distinguished name of member user…”

Done! Let’s put it to a test!

Nice, it works! So now we could provision one of our Okta users/groups as an administrator for Jamf Pro:

But let’s go a step further, what about MFA? As said above, Okta actually added MFA to the LDAP interface as well. Let’s take this out for a spin!

First of all you have to enable MFA for you users in Okta, compatible with multiple options including the Okta Verify App, SMS and other 3rd party authenticators.

When authenticating over LDAP, with Okta MFA configured/required for the users, Okta will keep the LDAP authentication request active, process the multifactor verification, and validate the LDAP authentication accordingly. 

However, looking at the Jamf Pro Admin and User Initiated Enrolment portal, when authenticating via LDAP accounts, using a MFA method with a confirmation code won’t be an option. There is no option to add the code to validate the MFA. Hence I went for the Okta Verify App. Besides the standard MFA method with a confirmation code (to enter in the service or app you are authenticating to), Okta also provides a push authentication method, where the app actually gets a notification asking you to approve the login.

Have a look at the link below on how to configure Okta Verify, especially the push authentication method. Going through the full Okta configuration might bring me a bit of track here, but what you basically need to do is:

  • Select the Okta Verify App as a source for your MFA and enable Push Notification

  • Define a Sign On policy and point it to the required MFA method (“prompt for factor”)

Note: Just remember, when setting up the Sign On policy in Okta, don't forget to put the service account you are using for your Jamf LDAP integration as an exclusion! If not, Okta will ask for MFA each time Jamf Pro tries to query the  LDAP!

Once that done, let’s see MFA at work when logging in to Jamf Pro:

Due to the fact that there is no MFA interface on the Jamf Pro login, the login screen will just remain as it is after clicking on the “>”. However, while Okta keeps the LDAP authentication process alive, a notification will pop up on the iPhone, asking to approve the connection in the Okta Verify app.

Once approved, Jamf Pro will just log in…

Cool right? That’s MFA For Jamf Pro sorted! But what about enrolment?

For User Initiated Enrolment via https://JAMFURL/enrol we would have the exact same process, but the next question is: would it also work when doing DEP with the “LDAP authentication required” set in the Jamf Pro prestage?

Let’s check it out. On a technical level I see no reason why it wouldn’t work. The only consideration I’d have here is the story of the chicken and the egg… Imagine a new employee who is just unboxing the shiny new Mac, hitting the “Please authenticate with your Okta account” pop-up you configured in the prestage…

Right… authenticating via LDAP, with a (temporary) password communicated by the IT team wouldn’t be a problem, but authenticating with MFA, before the user was able to configure the verify app and link it to his/her Okta account, is another story.

Unless the user had access to the Okta user portal, via another computer, the DEP interface on a new Mac would not be able to assist the user on setting up MFA on first login (and the same with pure LDAP authentication for new users who have to change their password on first login by the way).

Note: just remember that there might be better ways to integrate Okta in a DEP deployment... like Jamf Connect (aka Nomad Login + Okta) for instance :-) I'm only adding LDAP authentication during the normal DEP proces as a POC while testing this Okta LDAP Interface. Jamf Connect will be for another post.

The choice to enforce MFA (and/or LDAP authentication) during the DEP enrolment, or to use other tools like JamfConnect (aka Nomad / Nomad Login) will depend from your environment, deployment needs and onboarding strategy. But this said, as a proof of concept, here is how DEP LDAP authentication would work for users who already have their LDAP password and MFA configured (for instance an existing user who is switching to new equipment):

Once the login is approved in the Okta Verify app, the enrolment process continues.

Note: a benefit of using LDAP authentication during the DEP enrolment is that fact that the computer will automatically be assigned to the user, and the inventory pulls the relevant user and location fields for the LDAP attributes.

And oh yes, what about using this to have LDAP accounts to login to Self Service? Same thing!

That’s it folks! Jamf Pro, Okta LDAP Interface and MFA… let me know what you think, or in what workflow you would fit this in.

As always, don’t hesitate to make any comments or suggestions, and if you liked this post, hit the like button and share it with your friends!

grtz,
TTG

UPDATE – Thu 11 Oct: it was brought to my attention that using the Okta LDAP interface via Jamf Pro Self Service is having some issues.

UPDATE – Thu 7th May 2020: this issue slipped my mind and I did not troubleshoot any further. However, we saw a support ticket coming in and a colleague identified a quick fix. Set User UUID: uid instead of objectGUID to fix the Self Service issue. Mapping changed in text above.