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?
I'm interested in this too. Some of the marketing seems to indicate they offer exactly this;
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.
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.
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.
@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.
@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.
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.
@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.
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.
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.
@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.