Engineer Out Standing Local Admin Requests With JIT Elevation

#The Old Way vs the New Way

A user rings the desk needing to install a printer driver, a VPN client, or a line-of-business tool that insists on writing to Program Files. The old way: a technician remotes in, opens Computer Management, drops the user into the local Administrators group, closes the ticket, and moves on. Nobody sets a reminder to remove that access. Six months later a compliance audit or a ransomware incident review finds dozens of standing local administrators scattered across the estate, and someone has to explain why. The manual grant-and-forget model is one of the most common findings in internal security reviews, and it quietly generates two tickets for every one it closes: the original elevation request, and the eventual clean-up ticket nobody wants to own.

The new way removes standing privilege entirely. A user requests elevation through a self-service form, an automation pipeline grants local administrator rights for a fixed, short window, logs the grant against a ticket reference, and revokes it automatically without a human touching a scheduled task or a spreadsheet. No standing access, no forgotten clean-up, and a full audit trail sitting in the SIEM before the technician has finished their coffee. This is Just-In-Time (JIT) local admin elevation, and it converts a recurring compliance finding into a self-closing control.

#Prerequisites and Permissions

• Windows 10/11 or Windows Server endpoints managed by an on-premises or hybrid identity source (Active Directory or Microsoft Entra ID).
• PowerShell 5.1 or later, with remote management enabled via WinRM, or an RMM/endpoint management platform capable of pushing scripts to target devices on demand.
• A dedicated service account or managed identity with rights to modify local group membership remotely. This account must not be a Domain Admin; delegate narrowly to Administrators group membership only, ideally via a Restricted Groups exception or a scoped local security policy.
• A ticketing platform capable of firing outbound webhooks, or a self-service intranet form connected to an automation runbook (Azure Automation, Power Automate, or an equivalent orchestration layer).
• A centralised logging destination such as Microsoft Sentinel, Windows Event Forwarding, or a syslog collector to capture every grant and revoke event with a ticket reference attached.
• Minimum role required to build and test this pattern: Helpdesk Automation Engineer or L2 Systems Administrator with delegated group-membership rights on the target OU. Domain Admin rights are neither required nor appropriate for this workflow.

#Implementation Steps

#Step 1: Build the elevation grant script

Action: deploy a script that adds the requesting user to the local Administrators group with a bounded ticket reference, then immediately schedules its own reversal on the same device. Expected result: the user gains elevation and a self-cancelling scheduled task is created in the same operation. Evidence to capture: the script’s console output and the corresponding Application event log entry.

1param(
2    [Parameter(Mandatory=$true)][string]$UserName,
3    [Parameter(Mandatory=$true)][string]$TicketId,
4    [int]$DurationMinutes = 25
5)
6
7$LogSource = "JITAdminAutomation"
8if (-not [System.Diagnostics.EventLog]::SourceExists($LogSource)) {
9    New-EventLog -LogName Application -Source $LogSource
10}
11
12try {
13    Add-LocalGroupMember -Group "Administrators" -Member $UserName -ErrorAction Stop
14
15    $expiry = (Get-Date).AddMinutes($DurationMinutes)
16    $taskName = "JIT-Revoke-$UserName-$TicketId"
17    $scriptArgs = "-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\Revoke-JITAdmin.ps1 -UserName $UserName -TicketId $TicketId"
18
19    $action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument $scriptArgs
20    $trigger = New-ScheduledTaskTrigger -Once -At $expiry
21    Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -RunLevel Highest -User "SYSTEM" -Force | Out-Null
22
23    $message = "GRANTED: $UserName added to local Administrators. Ticket: $TicketId. Expires: $expiry"
24    Write-EventLog -LogName Application -Source $LogSource -EntryType Information -EventId 4001 -Message $message
25    Write-Output $message
26}
27catch {
28    Write-EventLog -LogName Application -Source $LogSource -EntryType Error -EventId 4002 -Message "FAILED grant for $UserName. Ticket: $TicketId. Error: $_"
29    throw
30}

#Step 7: Forward every event to the SIEM

Action: configure Windows Event Forwarding or the Sentinel Log Analytics agent to collect Event IDs 4001 through 4004 from the Application log, source JITAdminAutomation. Expected result: every grant and revoke pair is queryable centrally within minutes. Evidence to capture: a saved KQL query returning matched grant/revoke pairs by ticket ID.

1# Conceptual KQL equivalent run against Log Analytics, shown here as pseudocode
2# for teams scripting the query via the Log Analytics REST API in Python
3query = (
4    'Event | where Source == "JITAdminAutomation" '
5    '| where EventID in (4001, 4002, 4003, 4004) '
6    '| project TimeGenerated, Computer, EventID, RenderedDescription '
7    '| order by TimeGenerated desc'
8)

#Verification and Expected Evidence

1. Confirm the grant executed: run Get-LocalGroupMember -Group “Administrators” on the target immediately after the workflow completes. Expected result: the requesting username is present. Evidence: command output plus the Event ID 4001 log entry, both attached to the ticket.
2. Confirm the scheduled task exists: run the Get-ScheduledTask query from Step 6. Expected result: a single Ready-state task per ticket ID, never duplicated. Evidence: task name string matching the ticket reference.
3. Confirm automatic revocation at expiry: re-run Get-LocalGroupMember two minutes after the scheduled expiry. Expected result: the user is absent from the group. Evidence: Event ID 4003 log entry correlated to the same ticket ID as the original grant.
4. Confirm SIEM ingestion: search Sentinel or Log Analytics for the ticket ID string. Expected result: a matched grant/revoke pair within the requested duration window. Evidence: exported KQL query result attached to the ticket as closing evidence.

#Rollback

If the automation grants access to the wrong user or the wrong device, or fails to revoke on schedule, roll back manually and immediately: run Revoke-JITAdmin.ps1 against the affected device with the correct username and ticket ID. To stop the bleeding while investigating, disable the webhook trigger or the automation runbook in the ticketing platform so no new grants fire during remediation. Blast radius is intentionally narrow: this pattern only ever touches one device’s local Administrators group. It never writes to Active Directory group membership, Group Policy, or any domain-level privileged group, so a failure in this automation cannot escalate beyond the single endpoint it targeted.

#Failure and Escalation Conditions

• If Remove-LocalGroupMember fails at revoke time because the device is offline, the scheduled task should be configured to retry on next logon. Escalate to L2 if a device has not logged a revoke event within four hours of its scheduled expiry.
• If more than three grant requests target the same device within 24 hours, treat this as a signal of repeated privilege misuse or a misconfigured software package. Escalate to security operations and suspend auto-approval for that device pending review.
• If the SIEM shows a grant event with no corresponding revoke event past the scheduled expiry plus a ten-minute grace period, this should wake an on-call technician. A missing revoke is the single condition in this workflow that must never wait until morning.
• Any request referencing a server operating system, a domain controller, or an account already holding a privileged Entra ID role must hard-fail the automation and route to manual L3 review. Never auto-approve elevation on tier-0 assets, regardless of stated justification.

#Measuring Ticket Deflection

Baseline the prior quarter’s volume of “need admin rights” and “please remove admin rights” tickets before deployment. After go-live, track two figures side by side: the number of JIT grants issued through the automated form, and the number of manual local-admin-group tickets still being opened by hand. The manual figure should trend towards zero within four to six weeks as the self-service form absorbs demand. The second, arguably more important figure for a Security & Compliance category is the count of standing local administrators discovered during quarterly access reviews. That number should also trend towards zero, because it converts a recurring audit finding into a control that closes itself every 25 minutes rather than every audit cycle. Report both figures monthly: tickets deflected from the desk, and standing privilege eliminated from the estate.