macOS - System Preferences - Temporarily Elevate Permissions

What the temporary admin elevation Worklet does

This Automox Worklet™ adds the currently signed-in macOS user to the local admin group for a fixed window, then removes them automatically when the timer expires. The Worklet reads the active console user from scutil, runs dseditgroup -o edit -a <user> -t user admin to elevate, and writes a launchd property list and companion shell script that revoke the elevation on schedule. Default window is 600 seconds (ten minutes), exposed as the timer_to_remove_admin policy input.

The evaluation script is non-destructive. It exits 0 when no user is signed in, when the active user is root, or when the active user already belongs to the admin group. It exits 1 (non-compliant, remediation scheduled) only when a real interactive user is signed in and lacks admin rights. Pair that with the FixNow action surface in the Automox console and a helpdesk technician can elevate a remote user in seconds without standing up a temporary local account or pushing a permanent group change.

Remediation builds two artifacts on the endpoint and trusts launchd to enforce the countdown. The plist lives at /Library/LaunchDaemons/com.automox.remove.user.from.admin.group.plist, and the revoke script lives at /Library/Application Support/Automox/ax_remove_user_from_admin_group.sh. An EXIT trap in the remediation script reverts the dseditgroup change and deletes both files if any step fails partway through, so a half-applied elevation does not leave the user stuck in the admin group.

Why grant time-limited admin rights instead of permanent ones

Most macOS endpoints in a managed fleet run as standard users by policy. The moment a user needs to install a vendor pkg, run an installer signed by a new developer ID, or change a System Settings pane that requires the admin lock, the helpdesk has three options: push a managed install, hand over an admin password, or join the user to the admin group permanently. The first option does not cover ad-hoc troubleshooting. The other two trade a fifteen-minute task for a long-lived privilege escalation that nobody remembers to revoke. The audit trail goes cold and the endpoint stays out of compliance with least-privilege baselines such as CIS macOS Benchmark section 5.1 and NIST 800-53 AC-6.

Time-limited elevation through this Worklet replaces the password handoff with a single FixNow click from the Automox console. The elevation lands on the resolved ConsoleUser, the launchd plist guarantees the revoke even if the helpdesk technician forgets or the user logs out, and the activity log records which operator triggered the uplift, against which endpoint, for how many seconds. That is the artifact a CIS 5.1 or NIST 800-53 AC-6 reviewer expects in place of a permanent admin group join.

How temporary admin elevation works

1. Evaluation phase: The Worklet reads the active console user from scutil show State:/Users/ConsoleUser, filtering out the loginwindow placeholder. If no interactive user is signed in, evaluation exits 0 and no change is scheduled. If the resolved user has UID 0 (root), evaluation exits 1 with an error to stderr. Otherwise, the script runs id -Gn <user> and greps for the admin group. A match exits 0 (already elevated, no work needed). A miss exits 1 so Automox schedules remediation.

2. Remediation phase: Remediation runs dseditgroup -o edit -a <user> -t user admin to add the active console user. It then writes /Library/LaunchDaemons/com.automox.remove.user.from.admin.group.plist with a StartInterval equal to timer_to_remove_admin and a companion script at /Library/Application Support/Automox/ax_remove_user_from_admin_group.sh that sleeps for the timer, runs dseditgroup -o edit -d <user> -t user admin, then launchctl unload's the plist and deletes itself. The script is registered with launchctl load. A final id -Gn check confirms admin membership before exit 0. The remediation EXIT trap rolls back the dseditgroup change and removes both files if any step returns non-zero, so a failure cannot leave the user elevated past the planned window.

Temporary elevation requirements

• macOS endpoint with an interactive user signed in at the console (the Worklet exits 0 cleanly at the loginwindow and on screens with no active ConsoleUser)

• The active user is not root (UID 0) and not a service account; the evaluation script halts with an explicit error if root is the resolved console user

• Automox agent privileges to run dseditgroup, launchctl load, and write to /Library/LaunchDaemons/ and /Library/Application Support/Automox/ (the default agent context meets all three)

• timer_to_remove_admin policy input set in seconds; default 600 (ten minutes); set to the smallest window that fits the ticket – 300 for a quick installer, 1800 for a longer troubleshooting session

• Recommend running through the FixNow surface for ad-hoc helpdesk uplift rather than a scheduled policy, so the elevation is auditable to a specific operator and ticket ID in Automox activity logs

• If the endpoint reboots before the timer expires, the launchd plist re-runs at boot because RunAtLoad is true; the revoke completes once the user signs back in and the timer rolls over

Expected state after a temporary elevation

Immediately after remediation, the active console user is a member of the local admin group and can authenticate to admin-gated dialogs in System Settings, run sudo from Terminal, install pkg installers, and modify files protected by admin-only permissions. Verify from a Terminal session with dscl . -read /Groups/admin GroupMembership and confirm the username appears in the list. id -Gn <user> from the same shell should also include admin. The launchd job is registered: launchctl list | grep com.automox.remove.user.from.admin.group returns one entry.

After timer_to_remove_admin seconds elapse, the revoke script wakes up, runs dseditgroup -o edit -d <user> -t user admin, unloads the launchd job, and removes the plist and revoke script from disk. Re-check dscl . -read /Groups/admin GroupMembership and id -Gn <user>; both should drop the user. The /Library/LaunchDaemons/com.automox.remove.user.from.admin.group.plist and /Library/Application Support/Automox/ax_remove_user_from_admin_group.sh files should be gone. The Automox activity log captures the elevation event and exit code 0, giving you a per-endpoint audit record of who got uplifted, by which operator, and for how long.

If the revoke script ever fails to clean up (rare; usually a corrupted plist on a broken endpoint), run dseditgroup -o checkmember -m <user> admin to confirm membership status, then dseditgroup -o edit -d <user> -t user admin to revoke manually and rm the residual files. Re-running this Worklet on the same endpoint will exit 0 at the evaluation stage because the user is no longer in the admin group, and a fresh remediation cycle will install a clean plist and revoke script for the next ticket.