+3Hi 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.
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
+8For 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.
+12@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.
+4For 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
+4Looking 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.
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.
+1To 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.
+3User 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.
+7I'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?
+1@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"
+7I 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
+9I 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?
+1I 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?
+9that did not fix it. It doesn't time out and returns the error after a few seconds.
+1A query into Okta support stated Okta does not support wildcard LDAP lookups in JAMF.
We have "Use Wildcards When Searching" enabled and our Okta LDAP connection is working fine. JAMF Pro 10.32.1.
+1@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.
Is there way can add All users from OKTA to JAMF pro users , In search it allow adding users one by one . Is there a way to Automatically sync users and Groups from OKTA to JAmf pro
+8A quick write up of how to get this setup and working top to bottom since I can't find anything on this:
Enable Directory Integration in Okta Admin
You will need to login to the Okta Admin portal and under Directory > Directory Integrations you can create an LDAP Interface. You should see something similar to below, we will come back to this later.
Create Read Only Admin Service Account in Okta
You'll now want to create an account in Okta that will be used as a service account for Jamf to query LDAP with. This user account should have Read-only Administrator permissions delegated to it in Okta.
Setup LDAP Server in Jamf Pro
In Jamf Pro go to Settings > System > LDAP servers and click New then Configure Manually
In the Connections tab
In the Mappings > User Mappings tab
+2Please upvote for adding Okta as a native option for Cloud Identity Providers:
https://ideas.jamf.com/ideas/JN-I-16061
A quick write up of how to get this setup and working top to bottom since I can't find anything on this:
Enable Directory Integration in Okta Admin
You will need to login to the Okta Admin portal and under Directory > Directory Integrations you can create an LDAP Interface. You should see something similar to below, we will come back to this later.
Create Read Only Admin Service Account in Okta
You'll now want to create an account in Okta that will be used as a service account for Jamf to query LDAP with. This user account should have Read-only Administrator permissions delegated to it in Okta.
Setup LDAP Server in Jamf Pro
In Jamf Pro go to Settings > System > LDAP servers and click New then Configure Manually
In the Connections tab
In the Mappings > User Mappings tab
I did try to follow your steps but getting ERROR:Unable to connect to the LDAP Server.
Not sure what the issue is I also added global session policy in Okta that not requiring MFA from the service user with read only admin permissions.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
