Okta LDAP + Jamf Connect + Computer Extension Attribute

nadav
New Contributor

Hi All,

We've managed to setup Okta LDAP as an LDAP server for Jamf PRO and it shows correct in tests.

We've been wanted to setup an Extension Attribute for computers based on the LDAP group membership of the relevant user.

But no matter what we do (we use the memberOf or uniqueMember attribute) it won't show up with any value.

We also have JAMF Connect if that's relevant but I haven't been able to populate the UserGroups field in the state plist no matter what I do either.

 

At the end of the day we are trying to limit policies based on LDAP groups - and while we manage to setup the rule, no Computer/User is assigned to the group. 

Any and all help would be greatly appreciated. Also let me know if you need any more info.

18 REPLIES 18

AVmcclint
Honored Contributor

Go to Settings > Computer Management > Inventory Collection and make sure "Collect user and location information from LDAP"  is checked

Thank you for the prompt assistance - that is already active and was all along.

 

nadav
New Contributor

and it didn't work :(

AJPinto
Honored Contributor III

Its too early for big braining, but you will want something like the command below. JAMF does not collect AD membership to report like you are wanting, but an extension attribute can grab it if you play with grep just right.

 

 

 

#!/bin/bash

currentUser=$(stat -f%Su /dev/console)
 dscl "/Active Directory/{your domain name here}/All Domains" read /Users/$currentUser | grep {whatever you are looking for} | cut -d' ' -f2

 

 

 

Though an extension attribute wont collect data until the Mac checks in AFTER the user logs in, however long that takes. I would not try to use something like this to scope anything in JAMF.

 

If your end goal is to limit policy scope to a given LDAP group(s), you will want to use policy limitations for that not an extension attribute. I find using JAMF Limitations to be extremely flaky, but it is what it is. In the policy/profile set your scope, then go to limitations and add your LDAP Group (if LDAP is missing you need to enable the collection in settings) and save. JAMF will not show you who is in scope for the policy, you will just see the entire scope but the limitations do work. 

Scope - Jamf Pro Documentation | Jamf

I am searching our LDAP servers for all AD groups with JAMF in the name.

AJPinto_2-1669040170371.png

 

 

 

nadav
New Contributor

Hi thanks for the info!

Using the script always returns

Data source (/Active Directory/.../All Domains) is not valid

No matter what domain I use.

As for the LDAP group limitation - that was the first thing I actually tried but it doesn't seem to deploy and the policy shows as 0 computers. that's why I went the path of an extension attribute.

AJPinto
Honored Contributor III

You need to quote the path or terminate spaces. Within the {your domain here} you don't need the fqdn, only THIS.something.com, its case sensitive if I am not mistaken. This will also only work if the Mac is domain bound. Though trying to use this to scope policies will not yield a positive experience. 

 

For the LDAP Limitation. It should show you number pending based on JAMFs understanding of LDAP membership. I have always found this function to be extremely flaky. If your connection time outs are too short, your LDAP instance cant reply to JAMF in time and JAMF will assume no access. Be careful though, if your times are too great you will break some configuration profiles. This also works off of inventory collection, so devices need to check in to update the scope.

 

AJPinto_1-1669048299640.png

 

Though, it may be best to take things back to the basics. Make sure your JAMF instance can search your LDAP server for a user. If your distinguished username is wrong JAMF will look in the wrong location of your forest for the information.

AJPinto_2-1669048631085.png

 

 

User Mapping can search for a userID.

User Group Mapping will search for an AD group.

User Group Membership Mapping will search to see if the specified user has the specified group. This is the best place to test.

AJPinto_4-1669049185339.png

 

 

 

 

 

nadav
New Contributor

Testing the ldap works perfect. but it still shows 0 matches

doing dscl and then ls shows i have no active directory.

I'm not sure if it recognizes the Okta ldap as such.

AVmcclint
Honored Contributor

Using Okta LDAP with JamfConnect is not the same as binding to AD. The dscl commands won't do anything for you. 

AJPinto
Honored Contributor III

My brain did not even click that. These are not mobile accounts, and don't have any AD groupings associated with them. Would inventory collection even work for this? Wouldn't JAMF just pick up on the local account, not the "linked" okta account? 

nadav
New Contributor
That’s what we’ve been experiencing- any way around this?--
Nadav Shatz
Tailor Brands | CTO

daniel_behan
Contributor III

JAMF Pro has an Extension Attribute Template that reads Group Membership from 

~/Library/Preferences/com.jamf.connect.state.plist

Look in Templates, JAMF Apps, JAMF Connect User Groups.

I’ve tried that but the plist file isn’t populated. Any idea how to get
jamf connect to populate it?--
Nadav Shatz
Tailor Brands | CTO

It should populate when the logged in user successfully connects to Okta.  You may want to coordinate a call with JAMF Support and Okta.  If you're successfully authenticating, maybe Okta isn't reading all the group memberships.

I'll try and set it up but i doubt they can make it work :(

--
Nadav Shatz
Tailor Brands | CTO

andrewsp
New Contributor II

Did you ever get anything figured out on this? my com.jamf.connect.state.plist files are not pulling the Okta groups either and I'm trying to scope based on group membership as well. 

nadav
New Contributor
As far as i can tell this isn't possible

--
Nadav Shatz
Tailor Brands | CTO

mardini
New Contributor II

I'm trying to figure out how to scope policies based on Okta groups and came across this thread. Has anyone been able to achieve this? Was it via an Extension attribute or did you use "limitations" in the policy scope? Any help would be greatly appreciated, thanks in advance!

andrewsp
New Contributor II

I ended up using limitations to scope the Okta groups, and then trigger them in one of two ways:

  1. Self Service – when users sign in to Self Service via Okta SSO they’ll see any policies where they’re a member of an Okta group used as a limitation scope
  2. I set up a daily policy that runs a script to get their Okta username from Jamf Connect, and then execute a “jamf policy -username” which executes any policies they’re a member of an Okta group used as a limitation

It’s been working well for me