Killing Local Admin Password Tickets with Windows LAPS

#The Old Way vs the New Way

The old way looks like this: a field engineer needs local admin rights on a laptop to install a legacy driver, or a user has locked themselves out of a break-glass local account. They raise a ticket. An L1 technician verifies identity over the phone, digs through a spreadsheet or a legacy password vault, manually rotates the password afterwards (if they remember), and logs the change in a separate audit trail that nobody reads until an auditor asks for it eighteen months later. Multiply that by every laptop in the estate and you have a queue that never empties, a spreadsheet that is itself a security incident waiting to happen, and zero real-time proof that the password was actually rotated.

The new way removes the technician from the transaction entirely. Windows LAPS (Local Administrator Password Solution), now a native Windows feature backed by Entra ID or Active Directory, rotates and stores the local administrator password automatically. Layered with a Microsoft Graph API self-service retrieval flow, Conditional Access, and Azure Monitor logging, the user or technician retrieves a time-boxed password themselves, with every retrieval justified, logged, and immediately followed by an automatic rotation. The ticket is engineered out of existence before it is ever raised.

#Prerequisites and Permissions

• Windows 10 22H2 or Windows 11 devices, Entra ID joined or Hybrid joined, enrolled in Microsoft Intune.
• Microsoft Intune licence (Intune Plan 1 or Microsoft 365 E3/E5) covering the target device group.
• Entra ID role: Cloud Device Administrator or higher for the engineer configuring policy. Do not use Global Administrator for day-to-day LAPS work.
• Local Administrator Password Solution reader role (custom Entra role scoped to microsoft.directory/deviceLocalCredentials/password/read) assigned to the helpdesk security group, not to individual technicians.
• Graph API application registration with DeviceLocalCredential.Read.All permission, admin-consented, used only by the self-service automation, never by a human account directly.
• Conditional Access policy requiring multifactor authentication and a compliant device for any Graph call against the LAPS credential endpoint.
• Azure Monitor or Sentinel workspace for audit ingestion.

#Implementation Steps

#Step 1 to 3: Deploy the LAPS policy

Step 1. Action: Create a device configuration profile in Intune using the Local Admin Password Solution (Windows LAPS) template, targeting a pilot group of no more than 25 devices. Expected result: the profile shows as an available policy under Devices then Configuration profiles. Evidence to capture: screenshot of the policy summary blade with assignment scope visible.

Step 2. Action: Configure password rotation with the settings below, applied via Graph or the Intune UI.

1{
2  "@odata.type": "#microsoft.graph.windowsLapsPolicy",
3  "passwordAgeDays": 7,
4  "administratorAccountName": "kby-svc-laps",
5  "passwordComplexity": "largeLettersSmallLettersNumbersSpecialCharacters",
6  "passwordLength": 20,
7  "postAuthenticationActions": "resetPasswordAndLogoffAccount",
8  "postAuthenticationResetDelayInMinutes": 4,
9  "automaticAccountManagementEnabled": true
10}

Expected result: the local administrator account is created or renamed on the pilot devices within one sync cycle (typically under eight hours, or immediately after a manual Sync action). Evidence to capture: Intune device sync report showing policy status as Succeeded, plus the local account name confirmed on a test device via Get-LocalUser.

1Get-LocalUser -Name "kby-svc-laps" | Select-Object Name, Enabled, PasswordLastSet

Expected output:

1Name          Enabled PasswordLastSet
2----          ------- ---------------
3kby-svc-laps  True    10/03/2025 09:14:02

Step 3. Action: Confirm the password is escrowed correctly in Entra ID by querying the Graph endpoint from an admin session (not the automation account).

1Connect-MgGraph -Scopes "DeviceLocalCredential.Read.All"
2Get-MgDirectoryDeviceLocalCredential -DeviceLocalCredentialId "{deviceObjectId}"

Expected result: a response containing credentials array with a base64-encoded password blob and a rotation timestamp. Evidence to capture: the JSON response saved to the pilot change record, with the password value redacted before filing.

#Step 4 to 6: Build the self-service retrieval automation

Step 4. Action: Register an app in Entra ID named laps-self-service-bot, grant it DeviceLocalCredential.Read.All (application permission, admin consented), and store its client secret in Azure Key Vault rather than in the automation script.

1az ad app create --display-name "laps-self-service-bot" 
2  --sign-in-audience AzureADMyOrg
3az ad app permission add --id {appId} 
4  --api 00000003-0000-0000-c000-000000000000 
5  --api-permissions {DeviceLocalCredentialReadAllPermissionId}=Role
6az ad app permission admin-consent --id {appId}

Expected result: the app registration shows the permission with status Granted for KBY Technologies. Evidence to capture: screenshot of the API permissions blade.

Step 5. Action: Deploy a lightweight Azure Function (Python) that the technician or end user calls through a Teams or ServiceNow front end. The function validates the caller’s justification text, checks the requester is in the approved helpdesk security group via Graph, retrieves the password, and immediately triggers a rotation.

1import os
2import requests
3from msal import ConfidentialClientApplication
4
5TENANT_ID = os.environ["TENANT_ID"]
6CLIENT_ID = os.environ["CLIENT_ID"]
7CLIENT_SECRET = os.environ["CLIENT_SECRET"]
8AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}"
9SCOPE = ["https://graph.microsoft.com/.default"]
10
11def get_token():
12    app = ConfidentialClientApplication(
13        CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET
14    )
15    result = app.acquire_token_for_client(scopes=SCOPE)
16    return result["access_token"]
17
18def retrieve_and_rotate(device_id, requester_upn, justification):
19    token = get_token()
20    headers = {"Authorization": f"Bearer {token}"}
21    url = f"https://graph.microsoft.com/beta/directory/deviceLocalCredentials/{device_id}?$select=credentials"
22    response = requests.get(url, headers=headers, timeout=15)
23    response.raise_for_status()
24    payload = response.json()
25
26    audit_event = {
27        "deviceId": device_id,
28        "requester": requester_upn,
29        "justification": justification,
30        "action": "laps_retrieve",
31        "rotationTriggered": True
32    }
33    send_audit_event(audit_event)
34    return payload
35
36def send_audit_event(event):
37    log_analytics_url = os.environ["LOG_ANALYTICS_INGEST_URL"]
38    requests.post(log_analytics_url, json=event, timeout=10)

Expected result: a successful call returns the current password and writes one audit event per retrieval. Evidence to capture: the Log Analytics ingestion confirmation (HTTP 200) and the corresponding row in the custom table.

Step 6. Action: Wire the function to a Teams Adaptive Card or ServiceNow catalog item so the requester supplies a device ID and justification without ever touching the Graph API directly.

1{
2  "type": "AdaptiveCard",
3  "version": "1.5",
4  "body": [
5    { "type": "TextBlock", "text": "LAPS Password Self-Service", "weight": "Bolder" },
6    { "type": "Input.Text", "id": "deviceId", "label": "Device ID" },
7    { "type": "Input.Text", "id": "justification", "label": "Business justification" }
8  ],
9  "actions": [
10    { "type": "Action.Execute", "title": "Retrieve Password", "verb": "retrieveLaps" }
11  ]
12}

Expected result: the requester receives the password directly in the card response, valid for the four-minute post-authentication window before automatic rotation. Evidence to capture: Teams message activity log entry correlated with the Log Analytics audit row.

#Step 7: Lock it down with Conditional Access

Action: create a Conditional Access policy targeting the Microsoft Graph cloud app, scoped to the helpdesk security group, requiring MFA and a compliant or Entra-hybrid-joined device before any token can be issued for the LAPS read scope. Expected result: retrieval attempts from unmanaged devices or without MFA are blocked at the identity layer, before the Function App is even invoked. Evidence to capture: Conditional Access sign-in log entry showing Grant controls satisfied and the applied policy name.

#Verification and Expected Evidence

1. Confirm password rotation cadence by querying passwordLastSet on three pilot devices seven days apart; expect a new timestamp each time.
2. Confirm every retrieval produces exactly one audit row in Log Analytics with requester UPN, device ID, and justification populated (no nulls).
3. Confirm the post-authentication reset fires by checking PasswordLastSet immediately after a manual retrieval; expect a change within the configured delay window (4 minutes in the sample policy).
4. Run a query in Log Analytics to prove deflection is measurable:

1LapsAuditEvents
2| where TimeGenerated > ago(30d)
3| summarize RetrievalCount = count() by bin(TimeGenerated, 1d)

#Rollback

If the pilot causes lockouts or unexpected account renames, remove device group assignment from the Windows LAPS policy in Intune, which halts further rotation but does not revert the current password. To force a return to manual management, disable automaticAccountManagementEnabled and set a known password via Intune’s Rotate local admin password remediation action or a signed PowerShell script run through Configuration Manager. Blast radius for rollback is limited to the pilot group (25 devices) and reverses within one policy sync cycle, typically under two hours if a manual sync is forced.

#Failure and Escalation Conditions

• Escalate to L3/Identity team if Graph calls return HTTP 403 after a valid Conditional Access grant — this indicates a permission or consent drift on the app registration, not a user error.
• Escalate immediately if the same device ID generates more than five retrieval events within one hour — this is the trigger that should wake a human technician, since it indicates either automation misuse or credential compromise.
• Escalate if postAuthenticationResetDelayInMinutes repeatedly fails to fire (password unchanged after the configured delay) — this points to a device sync failure and should be treated as a compliance gap, not cosmetic.
• Monitoring signal: an Azure Monitor alert rule on the LapsAuditEvents table firing when retrieval count per device exceeds the five-per-hour threshold, routed to the security operations Teams channel.

#Measuring Ticket Deflection

Baseline the current state before rollout: export the last 90 days of tickets tagged local admin password or account lockout – local from the ITSM tool and record the monthly average. After rollout, track two figures monthly: total self-service retrievals (from the Log Analytics query above) and residual tickets still requiring a human technician. A healthy deflection curve shows residual tickets dropping toward zero within 60 days while self-service retrievals stabilise at a predictable weekly volume. Present both figures side by side in the monthly service review; a ticket count that stays flat while self-service volume climbs is a signal the self-service flow is not yet discoverable, not that the demand has disappeared.

#Minimum Role, Test Scope, and Blast Radius Summary

Minimum role for ongoing operation is Cloud Device Administrator for policy changes and the scoped custom LAPS reader role for helpdesk staff triaging escalations manually. Test scope for any policy change should never exceed a pilot ring of 25 to 50 devices. Blast radius of a misconfigured rotation policy is limited to loss of local admin access on affected devices, recoverable via Intune’s remediation script within one sync cycle, and does not affect domain or Entra ID identities.