Self Service- Get the signed in users Jamf group?

Release Candidate Programs Tester

Hey all,

Is it possible, preferably without using the API, to get a list of Jamf groups for a user based on the account they used to sign into Self Service?

Our field techs have 2 users ID's in JSS; one is a standard user account, the other an elevated permissions account. The techs are all members of a JSS static group (Field Techs)

I have a Self Service policy that runs a script.  The script captures the user ID of the person signed into Self Service. If someone signs in with a standard user account, the script behaves in a particular way.  If they sign in using the elevated account, the script modifies its behavior to enable certain options for the field techs.

The goal there was to modify the script behavior based on whether it was a standard account or elevated account that signed in, so that if a non-Field tech user signed in they would see a limited version of the script functions.

My problem is that techs tend to sign in with their standard user account more often than the elevated account, meaning the tech will not have access to all the options unless they sign out and in again.  Not the end of the world, but not especially convenient either.

So, my thinking was that if I could get the group (Field Techs) and modify my script to enable those functions based on the group membership, then it wouldn't matter which account they used, as long as both accounts were members of the Field Techs group.


I know I can use the API for this, but I was hoping to avoid the extra complexity involved.





Honored Contributor II

Seems like this entire work flow may be more complicated then it needs to be. Have you considered using a policy limitation, and having users log in to Self Service? You could target policies at users with specific AD group membership. 

Release Candidate Programs Tester

@AJPinto All users are logging into self service to access this script. The challenge is that all users need to be able to login regardless of their group membership, but to change script behavior based on that group membership.

For example, this script will display a dialog window; if a normal end user signs in, the dialog shows one version of text. If a technician signs in, the text is different (different enough that I needed to make it work this way to satisfy the needs of the group making the request).

To avoid maintenance issues I was trying to stay away from having 2 versions of the script scoped to each group accordingly, but I'm not sure if that will be possible.

Release Candidate Programs Tester

I took a different tact on this, following the advice of @AJPinto .  Instead of capturing Self Service User ID and wondering if I can get the group membership, I added a script parameter which allows me to use 1 script (achieved that goal!) across multiple policies with different scopes.  The script parameter will allow me to limit or enable the functions I want for each policy, meeting the desired requirements.