Jamf Temp Admin Script Issue

[rtylerdavis]

Hey all - I'm testing the Jamf "MakeMeAnAdmin" script found here. My first run I tested a reboot after making a few admin changes and after hitting the 30 minute mark, it didn't seem like the launch daemon worked, as the logs never appeared where they should have, and the LaunchDaemon plist was still on the drive.

I opened the plist to see what was written to it, and found that it was unreadable:

bplist00�
 
_ProgramArguments]StartIntervalULabelYRunAtLoad�W/bin/sh_6/Library/Application Support/JAMF/removeAdminRights.sh[removeAdmin    $28BEM���������

�����������������������

The admin access did work, just the ending launch daemon didn't seem to. Here's my policy log if it's of any assistance:

[STEP 1 of 4]
Executing Policy Support_30minTempAdmin
[STEP 2 of 4]
Running script Support_TempAdmin...
Script exit code: 0
Script result: id36704
button returned:Make me an admin, please
[STEP 3 of 4]
[STEP 4 of 4]

I'm going to test again shortly without rebooting, and see if the plist file it writes is more legible pre-reboot, but as far as I understand, a reboot shouldn't impact it.

[bentoms]

@rtylerdavis use defaults read on the file.

Or concert xml with plutil before reading.

It’s not corrupt, just in a slightly different encoding.

[rtylerdavis]

@bentoms you're right...didn't realize I could do a defaults read on a custom file path (I'm fairly new to the macOS world). Running a defaults read on it shows this:

    Label = removeAdmin;
    ProgramArguments =     (
        "/bin/sh",
        "/Library/Application Support/JAMF/removeAdminRights.sh"
    );
    RunAtLoad = 1;
    StartInterval = 1800;

Which appears to be all correct, as long as the StartInterval is definitely counted in seconds. I checked that listed directory for the removeAdminRights script, and it is there as well, and shows this:

if [[ -f /private/var/userToRemove/user ]]; then
    userToRemove=$(cat /private/var/userToRemove/user)
    echo "Removing $userToRemove's admin privileges"
    /usr/sbin/dseditgroup -o edit -d $userToRemove -t user admin
    rm -f /private/var/userToRemove/user
    launchctl unload /Library/LaunchDaemons/removeAdmin.plist
    rm /Library/LaunchDaemons/removeAdmin.plist
    log collect --last 30m --output /private/var/userToRemove/$userToRemove.logarchive
fi

So it looks like everything is in the right place, and working as expected, except it didn't actually run that script... I did lose admin rights, but I don't have the logs in the expected directory...

[mm2270]

I think in the past, possibly when that was all written, it was possible to unload a LaunchDaemon and still have it complete the job, meaning, finish the script and finally, remove itself. Unfortunately that doesn't seem to work anymore. Apple, in their continuing effort to secure the OS, changed it so as soon as a job gets unloaded, whatever it was running, meaning the script, terminates immediately. At least that's been my experience. So it's likely not finishing up by removing the LaunchDaemon plist (the rm line), and also the log line isn't running. That might be why you don't see either of those steps happening.
You said the admin access part worked. If that parts working, but the rest is not, then it's likely because the job is being unloaded before it can finish the script tasks. You could try moving the launchctl unload /Library/LaunchDaemons/removeAdmin.plist line to the end of the if/then block. That will at least give you the log entry, and possibly remove the script, but you'll probably be left with a dead LaunchDaemon left in the directory.

[cubnation]

Two scenarios were tested today
1. Elevate rights for five minutes, and return to general users after five minutes
2. Elevate the rights for five minutes, cover the MacBook screen, and you can no longer return to normal users