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.
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.
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.
IF user is a member of any of 'AD - IT Dept' THEN Assign to 'OKTA - IT Dept'
Hope that helps.
@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 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 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.
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.
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?
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":
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.
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.
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 -
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.
@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"
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
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 firstname.lastname@example.org 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 email@example.com.
A few posts above states wildcard is working as of 1/21. Does it work for anyone else?