Engineer Out Standing Local Admin Requests With JIT Elevation

#The Current Method: Standing Local Admin Rights on macOS

The recurring audit finding is simple: users hold persistent membership in the local admin group on their Mac, indefinitely, whether or not they are actively doing administrative work that day. This is an observation about group membership state, not a claim about any individual’s conduct. Standing membership means the privilege exists continuously, so every subsequent audit cycle re-discovers the same exposure, and remediation typically becomes a one-off removal that gets re-requested and re-granted the next time the user needs elevated access — a break-fix loop that never closes the underlying control gap.

The organisational assumption behind this playbook is that the fleet is under active MDM management with a defined help-desk or self-service escalation path, and that macOS’s built-in identity and group tooling (dscl, dseditgroup, sysadminctl) is available on the endpoint. Apple documents endpoint identity and configuration management as part of its Apple Platform Deployment guidance; this playbook treats that guidance as the boundary for platform-level concepts and does not assert current version-specific command behaviour beyond what is stable across supported macOS releases.

#The Improved Workflow: Just-in-Time Elevation

The recommendation is to replace standing admin membership with a bounded elevation: a user or a triggering system requests admin rights, the request is checked, membership is granted for a fixed window, and membership is removed automatically at expiry rather than by a second manual ticket. The distinguishing property is that the default state of every account is non-admin, and elevation is the exception, logged and time-boxed, rather than membership being the exception’s absence.

#Guardrails

• Treat every grant and every revocation as a state-changing action: log scope (user, device), expected evidence (before/after membership check) and a stop condition before the action runs, not after.
• Fail closed: if the risk check, the scheduler registration check, or the identity confirmation cannot complete, deny or revoke rather than defaulting to access.
• Never let the self-service trigger itself require standing admin rights to operate; that would simply move the standing-rights problem rather than remove it.
• Keep grant and revocation as two independently verifiable actions rather than a single script whose success is inferred from a single exit code.

#Validation

Validation must be evidence-based rather than assumed from a script’s return code.

• Action: Run dseditgroup -o checkmember -m <user> admin immediately after a grant. Pass condition: membership is confirmed present and matches the intended grant window.
• Action: Run launchctl list | grep <revocation-label> after scheduling. Pass condition: the job is present and its next-run interval matches the intended elevation window.
• Action: After the scheduled window elapses, re-run the membership check. Pass condition: membership is confirmed absent.
• Action: Query unified logging for the grant and revoke event pair (log show filtered by timestamp and predicate). Pass condition: both events are present and timestamped consistently with the grant window.
• Action: Confirm the denied-request path by forcing a risk-check failure in a test environment. Pass condition: no admin membership is granted and a denial event is logged.

#Common Mistakes

• Assuming the grant script’s exit code proves the revocation job registered — these are separate operations and must be checked separately.
• Building the self-service trigger so that requesting elevation itself requires elevated rights, which defeats the purpose of the workflow.
• Treating a successful grant as complete audit evidence without also confirming the subsequent revocation and its log entry.
• Defaulting to approval when the risk check is unreachable, instead of failing closed.
• Hardcoding credentials or shared secrets inside the grant or revoke script rather than using your organisation’s existing secrets handling.

#Recovery

If a grant is issued but the revocation job fails to register, or if a revocation fails to execute at expiry, treat this as an incident, not a background task.

1. Immediately run the manual revocation: dseditgroup -o edit -d <user> -t user admin.
2. Confirm removal with dseditgroup -o checkmember -m <user> admin; the expected result is a negative membership response.
3. Terminate or clear the orphaned scheduled job with launchctl list followed by the appropriate unload/remove action for that job label, to prevent a stale revocation firing against a since-changed account state.
4. Write a manual log entry (or trigger the same logging path the automation would have used) recording the manual intervention, the reason, and the timestamps, so the audit trail is not silently incomplete.
5. Re-run the full grant-verify-schedule-verify sequence from Step 1 only after the failure cause is identified; do not simply retry blindly.

#Measurable Outcome

Success is defined by observable state, not by an assumed improvement. Track, per audit cycle: the count of accounts holding standing (non-expiring) local admin membership, which should trend to zero for in-scope users; the proportion of elevation requests that have a matching, logged revocation event within the intended window; and the count of revocation-registration failures caught by Step 6’s verification, which should be investigated individually rather than averaged away. No specific percentage or time-saved figure is asserted here, because no verified before/after measurement was supplied with this assignment; instrument these three counts in your own environment before reporting a numeric improvement.

#Checklist

• Confirm current admin group membership before any grant action runs.
• Confirm the grant action changed membership as expected, using an independent check, not the script’s own exit code.
• Confirm the revocation job registered with the scheduler before treating the elevation as complete.
• Confirm the revocation actually executed at expiry and membership returned to non-admin.
• Confirm both the grant and revoke events appear in unified logging with consistent timestamps.
• Confirm the denial path works for a failed or rejected risk check, fail-closed by default.
• Escalate and manually revoke immediately if any verification step above fails, per the Recovery section.