Removing admin rights from managed mobile accounts?

I'd create a run-once policy to run on login or logout, to run a script or a command like so:

/usr/sbin/dseditgroup -o edit -d $3 -t user admin

That should remove a user ($3) from the admin group.

Here's one that would remove admin rights from all users that have their user folders in the /Users directory.

#!/bin/sh
# For any user listed in the /Users folder, remove from the admin group
for user in `find /Users -maxdepth 1 -type d ! -name Shared -mindepth 1 |cut -d/ -f3`
    do

            /usr/sbin/dseditgroup -o edit -d $user -t user admin
            echo Removed $user from admin group

    done

Thanks Guys, I will play around with both of these.

Andrew, we have a local admin account on every system, I assume your script would nuke that also? Is it possible to target only mobile profiles?

The good news is that so far we're only looked at about 5 people, so if I have to add a specific account name to a script then no biggie.

Thanks guys

RobertHammen any idea why ```
/usr/sbin/dseditgroup -o edit -d $3 -t user admin
``` doesn't work when you do a "Run Command" in a policy? It returns "Group Not Found".

If these accounts are AD based, you can target all local accounts derived from Active Directory by pulling a list with the UIDs in the proper range and then loop through these to change the admin status. Managed mobile accounts from Active Directory are created with UIDs in the 1000 and up range, so targeting only those you'd exclude any local admin accounts.

#!/bin/sh

UserList=$( dscl . list /Users UniqueID | awk '$2 >= 1000 {print $1}' )

for USER in "$UserList"; do
    /usr/sbin/dseditgroup -o edit -d $USER -t user admin
done

There is ONE thing to keep in mind though. If these users were abusing admin rights there's no saying they haven't created another local admin account on their own from System Preferences (assuming it isn't disabled for them) which would mean the above script would miss any of those accounts. This would allow them to easily re-grant themselves admin status.
If this is a concern, you can try a different approach which would list all accounts (mobile or otherwise) from UID 501 and up, but then exclude the one local admin account you know should be on the Macs.
For example, say your local admin account is called "administrator" (I know, sneaky huh?) You can do something like instead to get all users to loop through, minus "administrator".

UserList=$( dscl . list /Users UniqueID | awk '$2 >= 501 {print $1}' | grep -v administrator )

The rest of the script would be the same as above.

Beyond all this, if you suspect hanky panky with admin accounts, it would be a good idea to use Casper to blast out a password change to the local admin account IT uses, just to be sure none of the users messed with it and changed the password, etc. If that account is also your Casper Suite service account, make sure to use the Change Management password option in the policy instead. But if they had been messing with that account, you'd start having problems running policies.

@jhbush1973 - Is the policy running as either login or from Self Service? Those are the only 2 times you can use $3 to get the current user name. That might be why you're seeing that error.

Adding an "and" with your admin username to the find command should do the trick. Here's a revised version, replace "ADMINUSER" with the name of your admin user account.

#!/bin/sh

# For any user listed in the /Users folder except Shared and *ADMINUSER*, remove from the admin group
for user in `find /Users -maxdepth 1 -type d ! -name Shared -a ! -name *ADMINUSER* -mindepth 1 |cut -d/ -f3`
    do
        /usr/sbin/dseditgroup -o edit -d $user -t user admin
        echo Removed $user from admin group
    done

and if you are truly paranoid about how back doors being setup...
dsenableroot -d -u localadmin -p password

Hey Everyone,

The positional parameters reserved by the JAMF binary (ie $1, $2, $3) are only utilized at certain times. $3 will pass the local user account, but only at login. It will also pass the current user in Self Service, but only if you have Self Service set up to require authentication. Please see this Kbase article for more information:

https://jamfnation.jamfsoftware.com/article.html?id=146

What you can do, is some basic Unix stuff, and call a command with in a command to grab the current user if you want to use the run command tab from a policy to do so. So, for example, I set up a policy that runs this command in the advanced tab in a policy:

echo "$(ls -l /dev/console | awk '{ print $3 }') is current user"

So, with in my echo command, I run another set of commands to output the current user, and my results are here via ssh into my VM when running the policy manually:

$ sudo jamf policy -trigger test -verbose
 verbose: Checking for an existing instance of this application...
Checking for policies triggered by "test"...
 verbose: Checking for active connection on interface "Ethernet"...
 verbose: Found active connection on "Ethernet"...
Gathering Policy Information from https://casper87.local:8443//...
 verbose: The Management Framework Settings are up to date.
 verbose: Found 1 matching policies.
 verbose: Removing any cached policies for this trigger.
 verbose: Parsing servers...
 verbose: Parsing Policy test poc shell command (3)...
Executing Policy test poc shell command...
    Running command echo "$(ls -l /dev/console | awk '{ print $3 }') is current user"...
    Result of command:
**tlarkin** is current user

    Submitting log to https://casper87.local:8443//...

So, if you did not want to use the login trigger of a policy, you could run some Unix commands to accomplish this another way. I know in my experience users hardly ever log in our out, especially on laptops. So, when I tried to deploy something via login, it was like playing a game of whack-a-mole since my mobile users hardly ever logged in and out.

I hope this helps.

Thanks,
Tom