Connecting Okta as an LDAP Source?

[saul_herman]

Hi all,

Just wondering if anybody has had any luck connecting to Okta as an LDAP source. It's enabled on our Okta instance and others apps can connect to it, however when I try and configure the JSS it gives me a connection error every time no matter what config I've tried.

[zachary_fisher]

Hey Saul,
I got it to work. Here are settings I used.

Mappings

Object Class Limitation: All ObjectClass Values
Object Class(es): inetOrgPerson
Search Base: dc=ORG,dc=okta,dc=com
Search Scope: All Subtrees

Attribute Mappings

User Mappings

User ID = uid
username = uid
Real Name = cn
Email Address = mail
Department = department
Building = l (this maps Okta City to JAMF Building)(*Building has to already be created in JAMF)
Phone = mobile
Position = title
User UUID = objectGUID

User Group Mappings

Object Class Limitation: All Object Class Values
Object Class(es): groupofUniqueNames
Search Base: ou=groups,dc=ORG,dc=okta,dc=com
Search Scope: All Subtrees
Group ID = uniqueIdentifier
Group Name = cn
Group UUID = objectGUID

User Group Membership Mappings

Membership Location: Group Object
Member User Mapping = UniqueMember
Only Check "Use distinguished name of member user when searching the LDAP directory," leave everything else unchecked

[arjun_asokan]

@zachary.fisher would you be able to share your connection settings(Redacted or generalized of course).

[TajChana]

Has anyone had any success with this? Im still struggling..

[joe_adu]

@TajChana what issues are you having? I struggled through this over the last few days and finally figured it out. I just stumbled upon this post today. Happy to help if you're still having trouble.

[rob_olague]

Also trying this, having an issue as well. Have 'configure manually' set, using ORG.ldap.okta.com and port 636 with SSL ON and simple auth.
distinguished username as uid=USER@DOMAIN,dc=ORG,dc=okta,dc=com and getting a connection error. Seems to work fine in ApacheDirectoryStudio with the same info.

[rob_olague]

Nevermind, I just got it to work. Unselect use wildcards when searching.

[rob_olague]

Looks like OKTA doesn't support wildcard searches yet
https://support.okta.com/help/s/question/0D50Z00008G7VEqSAN/is-it-possible-to-query-okta-with-ldap

[stevewood]

@zachary.fisher THANK YOU FOR THIS!!! Your details helped us flush out where were having issues. We could get everything but Group Membership to work until we switched to your settings.

[cainehorr]

I (currently) work for Okta...

I can confirm... Okta's LDAP as a Service does not (currently) support wildcard searches.

[dstocking]

I'm still having issues with this. It looks like I can connect to Okta, but when I test or query, I'm getting no results...

[chumphries]

Working on setting this up, but having issues. Excuse my ignorance here, but do I have to have an agent running for this to work?

[stevewood]

@chumphries No, no agent needs to be running. Just mirror the settings above and it should work. You will not be able to do wildcard searches, so you need to be using the exact user name criteria. For us that is email address, so I would have to search for the exact email address for Okta to return data.

[sburt]

Seconded that I was able to get FQDN user lookups to work with the settings provided by @zachary.fisher. Has anyone had success in getting group membership queries to work?

[TajChana]

I was hoping that someone will be able to help..

I have used the above settings and it kind of works. I am able to test the connection from JamfPro but when im trying to login from SelfService im getting an error saying that its unable to connect to the server..

Can anyone point me in the right direction..

Thanks in advance

[chumphries]

Thanks @stevewood - where I am struggling is how this all actually works. Testing works great, but should Okta info be syncing to Jamf? What are some use cases for this?

[stevewood]

@chumphries the LDAP connection, whether Okta or a traditional onsite like AD, will get you:

• ability to lookup user info on the computer record on the User and Location tab of a computer record
• ability to scope policies based on LDAP group or user info

You can enable LDAP lookup during computer inventory update, and as long as the computer record has the Okta user name in the User Name field of the computer record the information will get updated for that computer record.

Okta LDAP simply replaces the functionality of AD LDAP. This is helpful in orgs where you may not have access to AD from your JSS without the use of a proxy like Jamf Infrastructure Manager.

[chumphries]

Thank you! @stevewood

[sburt]

To answer my own question from above, my issue with group membership was due to us using AD Groups instead of Okta local groups. If you are using AD groups and would like user group membership to work then you will need to mirror the membership through an Okta group rule. Okta LDAP logon started working for us once we set up Single Sign On with SAML on the Jamf server.

[daniel_ross]

Hey, all sorry to bump an oldish thread. We just got this enabled by Okta and I'm running into issues getting this even to work.

I've read through this thread a few times and think I have this setup to work properly along with the Okta instructions on how to set it up.

Right now though just any test of any kind just yields the results seen in the image below:

Not sure what I might be missing but have been banging my head against the wall for a while now. Anyone find a guide or better set of instructions that helped get them connected?

Thanks in advance!

[stevewood]

@daniel_ross what I've found is that the record you are searching for is not present you will get that "Unable to connect" error. Okta does not do wildcard searching, so if the email/username object that you are looking for is not present in Okta, it will give that error. I've also found that it can be case sensitive. A search for "John.Doe@mydomain.com" fails but a search for "john.doe@mydomain.com" is successful.

[daniel_ross]

@stevewood thank you so much for that bit of information!

I managed finally to get some results back after some troubleshooting late into the night however I'm seeing some fields not return results. Not sure if you or others on this thread run custom fields but below is an example of what I get as a return result for myself however we do have all the Dept, Location fields mapped in Okta and pulling and pushing to our AD.

Its been great so far seeing this as now something we can use but as I work on our Zero Touch deployment and Splashbuddy setup I'd love to pull the Building, Dept and possibly other fields from LDAP.

I'm going to try some additional troubleshooting steps on the User mappings to see if I can't get those fields to pull over.

[stevewood]

@daniel_ross What I used to help me understand the mappings was to use ldapsearch to pull up a user record and fiddle with the mappings there. The only one we use that you have is Department and that is 'department'.

This a cleansed command:

ldapsearch -x -vv -H ldaps://yourinstance.ldap.okta.com -b ou=users,dc=yourinstance,dc=okta,dc=com -D uid=yourlookupuser@yourdomain.com,dc=yourdomain,dc=okta,dc=com -W uid= <userid>

Replace the particulars with your stuff. for the uid= field, if you use full email then put that in there. Run that in terminal and you should get the user record and be able to figure out the mappings.

Good luck!

[daniel_ross]

@stevewood that helped a lot!

We're still running into an issue now where only one of our sites "San Jose" now shows up as "Building" which is the desired outcome and all other sites: Denver, etc. won't show up like this field does for our San Jose office.

We've opened a ticket with Okta to look at this along with other fields that aren't pulling properly to see if they can spot something. We suspect something might be buggy in our Okta instance.

I love the JAMF community as this helped get me ahead of where I thought I'd be today with this.

[jkuo]

I've got our Jamf sandbox connected to our Okta sandbox, but I'm running into trouble getting logged in. When I try to log in using the Okta LDAP credentials, I see the Jamf Pro homepage for just a moment (like less than a second) and then I get kicked out to the login screen again. Has anyone else encountered this?

Thanks!
Jason

[aesin]

@daniel_ross have you had any luck resolving the issue with building/department/room fields returning no result? We're facing the same problem here.

[aesin]

Interesting thing though... When I map Phone=department or Phone=l (or Email Address=department or Email Address=l, etc.) it maps department or building into the Phone (Email Address) field correctly but when I map Department=department and Building=l (as a matter of fact if I try to map anything there) those fields stay blank as on @daniel_ross screenshot. Could it be jamf not Okta?

[aesin]

To be able to create smart groups using departments with jamf not being able to display those values properly, I have tried to create an extension attribute as below and it worked. Now when I go to the extension attribute tab within a computer record I can see a proper value there.

[stevewood]

@aesin One thing to keep in mind when trying to set the Department value, the value being passed by Okta has to be the same value as is declared in your list of Departments in Jamf.

For example if you are passing "Accounting" from Okta, but in Jamf you do not have an "Accounting" department, it will not update the computer with the proper department.

Another example, if you are passing "Finance" form Okta, but in Jamf you have "Finances", it will not update the computer with the department from Okta.

Because of that, I pass the department from Okta into Room.

[daniel_ross]

So what @stevewood just posted just solved all my issues!

Not in a million years would I have thought I have to put those buildings, groups etc. in as I was hoping JAMF would just pass that along for me.

@stevewood a million thanks and Karma points your way for this. Been banging my head against the wall with Okta support to figure this one out.

[stevewood]

@daniel_ross glad I could be of assistance! I discovered that when building out our provisioning scripts. We use the jamf binary to set some things when building a machine and I couldn't figure out why the Department field wouldn't update. Turned out it had to be identical.

This is true of any drop-down field that you try to set in Jamf, even EAs. If you have an EA that uses a pop-up/drop-down/whatever, when trying to PUT the value you have to make sure it is identical to what is in the EA setup. Hope that makes sense.

[aesin]

Yes, that worked for us too :-) Thank you @daniel_ross for reminding about that 'unnecessary' necessity! Funny thing I didn't remember about this at all even though it was well covered during my last certification and I had a case open with jamf support and they as well didn't point me into this direction. Thank you again @daniel_ross!

[DaK3ll3r]

Hi all! From the Okta end, for this to work, do we need to purchase the Universal Directory feature flag? I've gone over all the settings, and only get "Unable to connect to the LDAP Server" if I run any test queries.

[dstocking]

Hi all! From the Okta end, for this to work, do we need to purchase the Universal Directory feature flag? I've gone over all the settings, and only get "Unable to connect to the LDAP Server" if I run any test queries.

@dak3ll3r - I think you do need to purchase Universal Directory for this to work. Now that the feature is Generally Available, I can see "LDAP Interface" Directory Integration option under Directories > Directory Integrations. That's where I found my config info.

[DaK3ll3r]

@dstocking, it seems like it was included in our specific domain, but I had to contact Okta to enable the LDAP interface. It took a little while, but I can now see the interface and can configure the integration. Thanks!

[perrinbw]

Any advice on getting LDAP Groups to work for access to the JAMF console? Our mappings work when we test them in the LDAP Server settings, but will not work for the assigned groups. I've followed @zachary.fisher's settings above.

[wmateo]

@chumphries I am currently in the process of migrating my JAMF pro instance to JAMFCloud. Did you have to add LDAP server in addition to OKTA or just connecting OKTA and configuring all the mappings were enough? I do not want to have to put a JIM if I do not have to for LDAP authentication and scoping to different security groups.

[kstrick]

When we tried it about 2 months ago,
it was fine for user information, but is not usable for AD group membership.
It was a limitation of the service that it can only find OKTA groups membership, but not AD group membership.
Unsure if they will add this or not, as i assume it could potentially require them pulling a lot more data.

We currently use OKTA for SAML, but have a JIM for user information

[wmateo]

@stevewood @zachary.fisher Hi All

I was able to get this to work for the user mappings but when i test the group mappings it only returns the OKTA groups and not my AD ones. Am I missing anything?

[stevewood]

@wmateo

I believe this will only pull Okta groups and does not dive down into your AD environment. So if you have AD groups that you need to read, I believe you have to have a corresponding Okta group for that. However, I am not an Okta admin and have no access to our environment, so I could be completely off base.

Sorry.