Using Okta as an LDAP source

[stevewood]

I am in the middle of deploying a centralized Jamf Pro instance for a large disparate organization. We're talking 5 business units with multiple sub-organizations, ultimately leading to well over 150 different Active Directory forests with no trust between them. So, 150+ separate LDAP directories.

We currently have an Okta integration that is being "fed" by these 150+ ADs, and while the Okta implementation is not the identity authority, it has every end user in it.

We are standing up our infrastructure for the Jamf Pro instance in AWS. We have no connection back to our corporate networks (which do not necessarily have communication with each other), and there is no plan to do so or to implement a VPN of any sort in AWS. So basically, AWS is its own island.

Rather than stand up 150+ instances of Jamf Integration Manager, I was hoping we could utilize our Okta integration to handle LDAP queries for the types of information we need in Jamf Pro. So Okta would become our LDAP source for all of the normal things we'd query: policy limitations, computer object information, etc.

Has anyone done something like this with Okta (or another identity provider), or is it even possible?

[psliequ]

I'm interested in this too. Some of the marketing seems to indicate they offer exactly this;

Okta Universal Directory

What they don't say is if they 're-export' the universal directory through LDAP so something like Jamf Pro can leverage it. Post back if you hear more or talk to them directly on this.

[crodriguez]

@stevewood

I am actually in the process of implementing/configuring JAMFPro here at my organization, we have it hosted on the JAMF cloud and we use Okta onsite for SAML. I have been able to setup Okta within the JSS config and, so far, we are able to SSO into the JSS. We are still in the early stages of everything, but I will be standing up a few JDS points essentially in the DMZ so the JSS can see/communicate with it...but, so far with Okta I have been to configure that work as an SSO for the JSS. I have one test machine in the JSS at the moment and Self Service is working on that machine using the same SSO (Okta) so it seems to be working so far without any issues.

[stevewood]

Hi @crodriguez

Yes, we have Okta configured as an SSO provider for authentication to the JPS web interface, and we can use it to authenticate for Self Service and Enrollment. The problem is with LDAP queries. Since Okta is not a true LDAP source, we are unable to use Okta to scope policies against.

So for example, if I want to provide a piece of software or a script (think rename computer and bind), and I only want a certain user or group of users to see that policy in Self Service, we cannot use Okta to scope the limitation against. The policy wants to use LDAP users or LDAP groups, and Okta cannot do that.

[joe_bloom]

If you have not done so already, I'd recommend to vote up this feature request on user sources. I'd love to hear, beyond Okta, which directory services people are most interested in seeing Jamf incorporate for user/group management and the "source of truth" for your directory.

[stevewood]

Thanks @joe.bloom ! Upvoted and commented on.

[gwinner]

Take a look at OneLogin, which is a unified cloud directory with real-time sync to Active Directory and provides LDAP services: VLDAP

https://www.onelogin.com/product/vldap

https://www.onelogin.com/product/directory

[stevewood]

@gwinner I'd love to look at another IDP, but unfortunately that's out of my control. We've already rolled out an extensive Okta integration (they'll write horror stories around it), and there's no way I'll be able to get them to pivot to OneLogin just because I need LDAP.

We're looking at utilizing the Okta API to possibly import the data directly into the JPS. Only problem with that is keeping the data from going stale. It will require some scheduled syncs of data, perhaps every evening or so, and that just adds another level of complexity.

I'll continue to update this as we come up with a solution.

[joe_bloom]

If you are considering an API based integration, then I'd suggest looking at Jamf webhook triggers (Settings -> Global Management -> Webhooks) so that you can use events to trigger specific updates rather than a full sync of all the data.

[stevewood]

Thanks @joe.bloom ! I'll be sure to let my Jamf support manager know, since he's the one doing the work. ;-)

[egjerde]

@stevewood Any update on where you ended up with this? Curious to know how you wrangled it with Okta.

[stevewood]

@egjerde Unfortunately, nothing to report. I've been waiting for our Okta admins to let me know when we could test Okta Universal Directory, but there have been a lot of other projects in front of that. We have a team currently working on a transformation project to stand up an authority for identity that will sit in front of Okta and AD, and to also provide us a single LDAP to look into.

For now, we've been asking agencies and business units to either allow public read access to their LDAP, or to stand up a JIM. I'm hoping our other team can get their single LDAP going quickly because I'm about to need to stand up several hundred JIM servers, and I really do not want to do that.

[aripringle]

We've been evaluating getting an Identity Provider, in some part because we wanted LDAP integration with Jamf Pro (Cloud). Up until now we've been using G Suite for SSO. We tested:

OneLogin - offers "Virtual LDAP", which doesn't have full group support, which Jamf requires
Okta - offers "Universal Directory", which does not provide any LDAP connectivity
JumpCloud - offers a full LDAP solution, which DOES work with Jamf (but is ultimately a very different solution than the first two)

I don't claim to be an expert on any of these, but I wanted to share my experiences. This was based on my testing of all 3 services around August 2017.

[egjerde]

@aripringle We have been testing the same three platforms right now (February 2018) and Okta is rolling out an LDAP interface to their Universal Directory; it's available right now in dev preview platforms but will be EA in April and in GA June/July (according to them).

We are using FoxPass (foxpass.com) as an intermediary right now - it's a great service that will relay OneLogin, Google, Okta, etc auth mechanisms to a true LDAP service, and it's very affordably priced.

[scottlevy]

We are looking for LDAP solutions that integrate with JAMF as well (Okta or otherwise). Has anyone found an LDAP provider that works with GSuite 2-factor authentication? And/or that synch's with multiple GSuite accounts? Foxpass seems to handle multiple GSuite accounts pretty well but they can't use GSuite 2FA.

[wmateo]

Hi All, I am in the process of moving to JAMF Cloud and my org uses OKTA SSO.... has anyone implemented LDAP connectivity without JIM

[wmateo]

@crodriguez

when you setup your JAMF pro hosted in their cloud did you configure JIM or was the Okta SSO sufficient enough to provide you LDAP information? I am looking to do same thing.

[stevewood]

@wmateo go check this discussion: Connecting Okta as an LDAP Source.

You do not need a JIM instances to connect to Okta for LDAP. If you follow the discussion on that other thread you should be able to connect and use Okta for LDAP lookups.

Okta as an SSO source is separate and does not do the LDAP lookups. Okta SSO is simply for authenticating to Self Service and to the Jamf Pro Server.

[wmateo]

@stevewood Thanks Steve, I was more refererring to my Jamf Pro cloud instance that I would be setting up. I spoke to my OKTA admin and they said as long as the user exists in JAMF, they can enable SSO. Which means I have to connect my JSS to LDAP. Other places I read OKTA can be a directory service. My objective would be not adding so many potential points of failure if I do not have to, hence the JIM question. I guess I am asking the the question as you in your original post.

[stevewood]

@wmateo The other post I referenced walks you through setting up Okta as an LDAP source. It doesn't really matter if you are hosted on site or Jamf Cloud, you do not need a JIM instance to use Okta LDAP.

[kcsantos]

I finally got the Okta Trial working in a test environment for our Prestage.

Is there a way to have Okta MFA step in when authenticating via LDAP in the Prestage enrollment phase?

[tlarkin]

@kcsantos yes but only for 10.15 and newer systems using Apple's new custom enrollment APIs. When you auth via DEP it will prompt you to configure MFA right then and there

[gragnarok]

@stevewood I use Okta LDAP to scope policies in my Jamf environment. It will not scope to the AD groups the Okta accounts sync up. What I had to do is set up Okta groups that build based on AD group membership because Jamf can see those. Once I did that it worked like a charm.

[mardini]

Hi @gragnarok , I'm trying to figure out how to scope policies based on Okta groups and noticed your comment. How were you able to achieve this? Was it via an Extension attribute or did you use "limitations" in the policy scope? Any help would be greatly appreciated, thanks in advance!

[gragnarok]

Hey @mardini, we utilized "limitations" in the policy scope with the LDAP groups. I will say we have since moved away from using the LDAP groups to another method. We do a lot of our scoping via "Department" which is also fed off of the LDAP integration and we have a series of smart groups that populate based on the value of that field. Let me know if you have any other questions I can help with!

[stevewood]

@graynor

Yep, that's exactly what we do. Anytime we need an AD group from one of our agencies to be available for scoping we have them create it in Okta first. Glad you worked it out!

[jeremy_lambrech]

Have any of you got this to work with AD mastered Okta user accounts?

[tlarkin]

@jeremy.lambrecht yes we use AD mastered accounts to Okta. Our Identity Engineer handles most of the work though, and not me