Skip to main content
Question

Okta LDAP + Jamf Connect + Computer Extension Attribute


Forum|alt.badge.img+3
  • New Contributor
  • 8 replies

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

AVmcclint
Forum|alt.badge.img+21
  • Esteemed Contributor
  • 1043 replies
  • November 21, 2022

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


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 21, 2022
AVmcclint wrote:

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.

 


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 21, 2022
nadav wrote:

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

 


and it didn't work :(


AJPinto
Forum|alt.badge.img+26
  • Legendary Contributor
  • 2725 replies
  • November 21, 2022

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.

 

 

 


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 21, 2022
AJPinto wrote:

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.

 

 

 


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
Forum|alt.badge.img+26
  • Legendary Contributor
  • 2725 replies
  • November 21, 2022
nadav wrote:

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.


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.

 

 

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.

 

 

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.

 

 

 

 

 


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 21, 2022
AJPinto wrote:

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.

 

 

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.

 

 

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.

 

 

 

 

 


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
Forum|alt.badge.img+21
  • Esteemed Contributor
  • 1043 replies
  • November 21, 2022

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


AJPinto
Forum|alt.badge.img+26
  • Legendary Contributor
  • 2725 replies
  • November 21, 2022
AVmcclint wrote:

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


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? 


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 21, 2022
AJPinto wrote:

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? 


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

Forum|alt.badge.img+11
  • Valued Contributor
  • 196 replies
  • November 21, 2022

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.


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 22, 2022
daniel_behan wrote:

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

Forum|alt.badge.img+11
  • Valued Contributor
  • 196 replies
  • November 22, 2022
nadav wrote:
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.


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • November 22, 2022
daniel_behan wrote:

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

Forum|alt.badge.img+7
  • Contributor
  • 16 replies
  • January 30, 2023
nadav wrote:
I'll try and set it up but i doubt they can make it work :(

--
Nadav Shatz
Tailor Brands | CTO

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. 


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • 8 replies
  • January 30, 2023
andrewsp wrote:

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. 


As far as i can tell this isn't possible

--
Nadav Shatz
Tailor Brands | CTO

Forum|alt.badge.img+3
  • New Contributor
  • 4 replies
  • August 5, 2023

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!


Forum|alt.badge.img+7
  • Contributor
  • 16 replies
  • August 5, 2023
mardini wrote:

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!


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


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings