Okta LDAP User Group Membership with Jamf Pro: The Missing Link

For some time now, I’ve had the annoying problem of being unable to use LDAP group membership from Okta within Jamf Pro. Following this guide https://jrdsgl.com/integrating-okta-ldap-to-jamf-pro/ (although there are a number of others out on the interwebs) I was able to successfully query users and groups, but critically not user group membership.

Having previously worked at an organization that still bound Macs to Active Directory (say what you will), I had long enjoyed the administrative benefits of this functionality by being able to assign LDAP groups to limitations and exclusions within automated and Self Service policy scopes. This provides two very useful features:

  1. It allowed me to limit sensitive CLI and Self Service policies only for IT technician use on any device.
  2. I could provide conditional access to select users based on their group membership, regardless of the Mac they might use.

Through the LDAP test mechanism within Jamf, I was able to query my and other users successfully (returning the object ID) but for the life of me could never query a given user and group (which the user was a part of) and return “Yes”.

After much trial and error, it occurred to me that guides consistently showed setting the ‘Membership Location’ option to ‘Group Object’ and that instead I might base this on the ‘User Object’ instead. If you’re at all familiar with Active Directory, when you access a user record there is a ‘Member Of’ tab which lists all the groups the user is part of. Sure enough, using the ‘User Object’ option and setting the value to memberOf correctly marked users as members of the appropriate groups!

If you have your LDAP configured correctly, you can achieve the previously mentioned benefits by configuring any Jamf policies with a Scope of ‘All Computers’ with Limitations based on the desired LDAP User groups. If you happen to have local admin users for specific management tasks, you can specify these individual usernames as well.

A potential undesirable side effect (depending on how you look at it) is that if you remotely connect to your users’ Macs and attempt trigger policies manually, simply running sudo jamf policy and a custom trigger will use the logged in user’s username by default. As a result, it may be necessary to run sudo jamf policy -username <user> where <user> is a user that’s a member of an LDAP group or is explicitly specified under your policy’s Limitations. While this solves a potential problem for IT staff, this leaves open an opportunity for clever users to take advantage of this (as I’ve written recently, the list of things a local admin user can’t do on an institutionally owned and managed Mac grows smaller and smaller…). In my own testing, use of the -username argument:

  • …with a valid LDAP username that is a member of an LDAP Group listed as a policy limitation will successfully trigger a policy.
  • …with a valid LDAP username this is not a member of an LDAP Group listed as a policy limitation will not trigger a policy.
  • …with a non-existent LDAP username will instead behave as if you hadn’t specified -username at all and use the logged-in user’s username.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s