Connecting Okta as an LDAP Source?

saul_herman
New Contributor II

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.

68 REPLIES 68

zachary_fisher
New Contributor III

For you to see AD groups I believe you would have to set it up so group membership/syncing is done from ad to Okta. So they would really be Okta groups they mimic your AD groups. Personally not sure if that is possible as we are a full Okta shop where Okta is the master. I know you can push groups from Okta to gsuite. I imagine you can setup an import from AD perhaps to update the Okta groups maybe? I would have to do some testing and ask a fellow AD admin if that’s possible. But as said, this integration will only look at Okta groups and users.

kellyebler
New Contributor

@wmateo @stevewood

Not at all off base. We noticed that our AD groups weren't syncing either and Okta support said that they don't expose AD groups by design. So, we just worked around it by creating new Okta groups and making simple rules to place users into those Okta groups based on their AD group.

Example:

IF user is a member of any of 'AD - IT Dept' THEN Assign to 'OKTA - IT Dept'

Hope that helps.

wmateo
Contributor

@stevewood @zachary.fisher

The only trouble I am having is the user record does not pull in Department and building and I have followed your settings above. any suggestions?

wmateo
Contributor

Also, since I am new to OKTA on JAMF I should ask how about the thick admin tools? Remote, Imaging, and Admin. What are some of you doing to grant access to your support teams etc.

stevewood
Honored Contributor II

@wmateo if you have the correct attributes in the mappings tab of the LDAP server (Okta), then my guess would be that you are trying to pull in building or department names that do not line up with what you have in Jamf. Both Department and Building have to be spelled exactly the same as you have in Jamf.

For example, if under "Settings -> Network Organization -> Departments" you have "Executives" but in AD you have a person's department as "Executive" it will not populate from Okta. The two have to be indentical. This is also true if you're trying to set these values from the machine using the jamf recon -department <department> call.

So my first check would be to make sure you have the spelling identical in AD as it is in Jamf.

As to your other question about the other tools, we do not allow those other tools to our techs. However, if I needed to limit access to those apps, I would create an LDAP Group under "Settings -> System Settings -> Jamf Pro User Accounts & Groups" with the proper permissions, making sure that the name of the group in Jamf lines up with the name of the group in Okta. You could then manage membership in Okta (or in AD if your AD feeds Okta).

I'm just not certain what the behavior is if you have a user with two different sets of permissions. So if you have an "Admin Users" group that has full permissions in Jamf and a "Jamf Remote" group with permissions only for the Remote app, and a user is in both groups I believe they inherit the less restrictive (so "Admin users") permissions.

wmateo
Contributor

@stevewood Thanks Steve

I have done all of that. I think the challenge I am facing is where the JAMF Remote tool for example bypasses SSO altogether and it's expecting a local account. In fact the only way I can log in to JAMF Admin is with a local JSS acct.

stevewood
Honored Contributor II

@wmateo that local JSS account can be an ldap account in Okta. Doesn't get you the Okta login page, but it does auth off of Okta so you can control that account (term when user leaves for example) in Okta. Just create an LDAP account in the JSS.

So you could create a Standard Group in the JSS, set all of your permissions in that group, and then create an LDAP account in the JSS that is Group based. That is how we controll access for some of our users.

sslavieroGSMA
New Contributor III

@stevewood What settings did you use for the Connection options?

Does it need an Okta service account to access? If so, what permissions?

Certificates or anything else?

stevewood
Honored Contributor II

@sslavieroGSMA Not sure which options you are referring to. I did nothing in Okta (I have no access). We did have the Okta team create a service account, but not sure if there is a difference between that account and the normal accounts we have. And I have no idea on permissions, sorry.

No certs were needed.

Hope that helps.

gchadha1
New Contributor

Hi guys,

I have setup a new LDAP server with Okta in our JAMF Pro. The server is being setup correctly and I have tested and it is populating the user's correctly.

But the issue is with few attributes that are not populating in JAMF which are : Building and Department.
5f8de39fcab44166b7250c825001f808

No matter what I enter it doesn't display anything. Also, if I map same attribute in other field it shows: eg. I mapped Room with department and it is displaying Department.

Anyone else facing any similar issue? or know what could be wrong here?

Thanks,

kellyebler
New Contributor

@gchadha1 It's been a month or so since I tested this but I believe the Building and Department names need to be configured in Jamf first (and they need to match what you have in Okta) before they will be displayed there.

jchenTHC
New Contributor

Has anyone run into intermittent connection issues (on JAMF cloud)? Looking in the debug logs, when I'm unable to return any results, I'm getting this error:

Root exception is java.net.UnknownHostException

sburt
New Contributor III

For anyone experiencing issues where Group Membership is not working correctly, the "Member User Mapping" setting in "User Group Membership Mappings" should be "uniqueMember" and not "UniqueMember":

https://help.okta.com/en/prod/Content/Topics/Directory/LDAP-interface-connection-settings.htm

For us, this was causing LDAP tests to show users as members of groups but signing into Jamf Self Service via SSO was not returning the correct group membership for LDAP Group filtered policy scoping.

marklamont
Contributor III

@gchadha1 and @kellyebler . Yes they do have to exist in Jamf first. I fell foul of the same thing recently and it's a bit of a PITA really.

Garci4
New Contributor III

For any lurkers, if you have users that are not able to sign in after switching your LDAP to Okta, change the Users Mappings> User UUID: objectGUID to User UUID: uid

yungstump
New Contributor

Looking to connect Okta LDAP to our JAMF next week. Is there any concerns I should know about before connecting? Don't want to potentially lock any existing enrolled users out of their machine.

werner
New Contributor

About two to three weeks ago a change in Okta caused MFA to be enforced through the LDAP interface, which complicates the enrolling process when end users are doing it. So you have to enter "password,otp" where "password" is the okta password, "otp" the code in Okta verify, Google authenticator or SMS during prestage enrollment. Before the change, Okta verify will ask the user if they are signing in, they'd say it's the them and that would be the end of it.

Also, any scopes relying on LDAP groups doesn't seem to work during pre-stage enrollment. It's a open issue at JAMF. You'll have to scope to departments or some other means. But it doesn't seem that the department attribute of the person logging via LDAP is passed to JAMF... still investigating.

Otherwise it seems to work just fine.

nchan
New Contributor II

To help anyone who still has trouble, please take a read at considerations:
The Okta account used only needs to be Read-Only Admin
The Distinguished Username in the Connections tab -

uid=account@domain.com,ou=users,dc=domain,dc=okta,dc=com

Use wildcard when searching WORKS (as of Jan 1, 2021)
In the User Mappings tab, the Search Base is set to:

ou=users, dc=domain, dc=okta, dc=com

Lastly, make sure in Okta, you've already set up an LDAP interface, create an exclude MFA sign-in policy as well as a exclude MFA enrollment policy.

Mr_Suaz
New Contributor II

User Group Mappings doesn't seem to work properly for me. When I enter a user to do a test/search - I don't get a list of all the groups that member is apart of.

When I use User Group Membership Mappings and test User to a Group works.

danny_gutman
New Contributor III

I'm only able to lookup via email address, but my script to automatically assign users to machines gets loggedinusername, which is usually first initial last name; results in no lookup.

Anyone find a way around this?

mjerome-EC
New Contributor

@Mr_Suaz same with me. Did you find a fix? I just found out I need a fix by this Friday!

bilal_habib
New Contributor III

a7149d22a4194abda7873a0b0ebd55b9
For user group mappings this works for me

nchan
New Contributor II

@danny.gutman I made a workaround by creating a custom attribute for Okta profiles that stores just the username prefix (everything before the @domain.com). Our Okta is sourced by our HRIS but wherever yours is being sourced from, just map whatever is necessary to your newly created Okta profile attribute. Then in Okta LDAP configuration in Jamf, set the "username" mapping to that new Okta attribute. In Okta, I call mine "user.emailPrefix" and in Jamf, I map username to "emailPrefix"

beeboo
Contributor

I used the setup posted by @zachary.fisher and it works for me, though to be clear, it ONLY seems to search for the OKTA groups, not groups synced to Okta by AD or Workday.

Any group that has the format domain/tree(sub tree) does not show up with the proper results, only if they DONT have that.

Visual attached, but the redacted groups will not show up proper when you do the OKTA LDAP test in JSS, but for the non-redacted versions they show up properly
19374e2c23ef4d66a7ba2e189529ce3a

DJC
New Contributor

I need some help with wildcard searches.

 

When I have wildcard search off, the Okta LDAP test works fine. i.e. I can search for first.last@domain.com and it returns the result.

When I enable wildcard search, searching for anything results in Unable to connect to the LDAP Server error even searching for first.last@domain.com

A few posts above states wildcard is working as of 1/21. Does it work for anyone else?

nchan
New Contributor II
Try increasing the timeout to something like 900 and slowly lowering it
back down to a proper timeout setting.

--
This message may contain confidential and/or privileged information. 
If
you are not the addressee or authorized to receive this on behalf of the
addressee you must not use, copy, disclose or take action based on this
message or any information herein. 
If you have received this message in
error, please advise the sender immediately by reply email and delete this
message. Thank you.

DJC
New Contributor

that did not fix it. It doesn't time out and returns the error after a few seconds. 

DJC
New Contributor

A query into Okta support stated Okta does not support wildcard LDAP lookups in JAMF.

 

 

sbhai
New Contributor

We have "Use Wildcards When Searching" enabled and our Okta LDAP connection is working fine. JAMF Pro 10.32.1.