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

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

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

@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.

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.

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

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

@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.

I (currently) work for Okta...

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

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...

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?

@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.

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?

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

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?

@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.

Thank you! @stevewood

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.

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!

@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.

@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.

@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!

@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.

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

@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.