Interesting thing though... When I map Phone=department or Phone=l (or Email Address=department or Email Address=l, etc.) it maps department or building into the Phone (Email Address) field correctly but when I map Department=department and Building=l (as a matter of fact if I try to map anything there) those fields stay blank as on @daniel_ross screenshot. Could it be jamf not Okta?

To be able to create smart groups using departments with jamf not being able to display those values properly, I have tried to create an extension attribute as below and it worked. Now when I go to the extension attribute tab within a computer record I can see a proper value there.

@aesin One thing to keep in mind when trying to set the Department value, the value being passed by Okta has to be the same value as is declared in your list of Departments in Jamf.

For example if you are passing "Accounting" from Okta, but in Jamf you do not have an "Accounting" department, it will not update the computer with the proper department.

Another example, if you are passing "Finance" form Okta, but in Jamf you have "Finances", it will not update the computer with the department from Okta.

Because of that, I pass the department from Okta into Room.

So what @stevewood just posted just solved all my issues!

Not in a million years would I have thought I have to put those buildings, groups etc. in as I was hoping JAMF would just pass that along for me.

@stevewood a million thanks and Karma points your way for this. Been banging my head against the wall with Okta support to figure this one out.

@daniel_ross glad I could be of assistance! I discovered that when building out our provisioning scripts. We use the jamf binary to set some things when building a machine and I couldn't figure out why the Department field wouldn't update. Turned out it had to be identical.

This is true of any drop-down field that you try to set in Jamf, even EAs. If you have an EA that uses a pop-up/drop-down/whatever, when trying to PUT the value you have to make sure it is identical to what is in the EA setup. Hope that makes sense.

Yes, that worked for us too Thank you @daniel_ross for reminding about that 'unnecessary' necessity! Funny thing I didn't remember about this at all even though it was well covered during my last certification and I had a case open with jamf support and they as well didn't point me into this direction. Thank you again @daniel_ross!

Hi all! From the Okta end, for this to work, do we need to purchase the Universal Directory feature flag? I've gone over all the settings, and only get "Unable to connect to the LDAP Server" if I run any test queries.

Hi all! From the Okta end, for this to work, do we need to purchase the Universal Directory feature flag? I've gone over all the settings, and only get "Unable to connect to the LDAP Server" if I run any test queries.

@dak3ll3r - I think you do need to purchase Universal Directory for this to work. Now that the feature is Generally Available, I can see "LDAP Interface" Directory Integration option under Directories > Directory Integrations. That's where I found my config info.

@dstocking, it seems like it was included in our specific domain, but I had to contact Okta to enable the LDAP interface. It took a little while, but I can now see the interface and can configure the integration. Thanks!

Any advice on getting LDAP Groups to work for access to the JAMF console? Our mappings work when we test them in the LDAP Server settings, but will not work for the assigned groups. I've followed @zachary.fisher's settings above.

@chumphries I am currently in the process of migrating my JAMF pro instance to JAMFCloud. Did you have to add LDAP server in addition to OKTA or just connecting OKTA and configuring all the mappings were enough? I do not want to have to put a JIM if I do not have to for LDAP authentication and scoping to different security groups.

When we tried it about 2 months ago,
it was fine for user information, but is not usable for AD group membership.
It was a limitation of the service that it can only find OKTA groups membership, but not AD group membership.
Unsure if they will add this or not, as i assume it could potentially require them pulling a lot more data.

We currently use OKTA for SAML, but have a JIM for user information

@stevewood @zachary.fisher Hi All

I was able to get this to work for the user mappings but when i test the group mappings it only returns the OKTA groups and not my AD ones. Am I missing anything?

@wmateo

I believe this will only pull Okta groups and does not dive down into your AD environment. So if you have AD groups that you need to read, I believe you have to have a corresponding Okta group for that. However, I am not an Okta admin and have no access to our environment, so I could be completely off base.

Sorry.

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.

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

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

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.

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

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

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

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

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

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,

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