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]

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]

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

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

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]

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

[MSB]

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 

[wmateo]

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

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

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

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

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.

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]

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

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]

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]

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

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]

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]

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]

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]

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]

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?

[mdjerome]

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

[bilal_habib]

For user group mappings this works for me

[nchan]

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

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

[DJC]

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]

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]

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

[DJC]

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

[sbhai]

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

[afarnsworth]

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

• Enable the Use SSL box and in the Host field enter the domain from the Host field shown on your Okta LDAP Interface page (Should be domain.ldap.okta.com)
• Enter 636 in the port field
• Authentication Type should be set to Simple
• LDAP Server Account
  • Distinguished Username should follow this convention "uid=ldap_account@domain.com,dc=okta_domain,dc=okta,dc=com"
  • Enter the password for the Okta Service Account you created before 
  • Connection Timeout should be 15 seconds
  • Search Timeout should be 60 seconds
  • Referral Response should be "Use default from LDAP service"
  • Enable Use Wildcards When Searching

In the Mappings > User Mappings tab

• Object Class Limitation should be set to All ObjectClass Values
• Object Class(es) should be set to inetOrgPerson
• Search Base this will always be in the following format
  • ou=users,dc=okta_domain,dc=okta,dc=com
• Search Scope will be All Subtrees
• Attribute Mapping will be:
  
• User Group Mappings - Replace okta_domain with your Okta domain
  
• User Group Membership Mappings
  
• After that click Save and then Test to do a user lookup and see if it works.

[seansalmassi]

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.

[kevinv]

Please upvote for adding Okta as a native option for Cloud Identity Providers:
https://ideas.jamf.com/ideas/JN-I-16061