Windows LAPS with Intune: Why the Password Never Shows Up (And How to Fix 7 Common Failures)

TL;DR: Windows LAPS is built into Windows 10/11 since April 2023 and replaces the legacy LAPS MSI. Deploying it through Intune works differently from GPO — it requires a separate tenant-level toggle in Entra ID, the right RBAC permissions, and specific KB updates. This post walks through 7 common reasons why LAPS appears "deployed" in Intune but produces no password in the portal — with concrete Event IDs, PowerShell commands, and remediation steps.

The Problem

You deployed a Windows LAPS policy through Intune. The policy assignment report shows "Succeeded" across your device fleet. Devices are Entra-joined, enrolled in Intune, fully managed. Everything looks fine — until you open a device in the Intune Admin Center and find the "Local admin password" tab either greyed out, completely empty, or showing no password expiration date.

This is the most common scenario that emerges after migrating from legacy LAPS (the MSI + GPO combination) to Windows LAPS built on the LAPS CSP. Admins see the policy as applied, but don't realize the policy assignment is only half the equation. The other half is a collection of prerequisites that must be met on the device, tenant, and RBAC level simultaneously.

A second problem involves mixed environments: some devices on Windows 10 20H2 without the required April 2023 cumulative update, others on Windows 11, some on older builds. LAPS silently fails on devices that don't meet the OS requirements, and Intune doesn't surface this in an obvious way — the policy still shows "Success" in the assignment report.

A third scenario is organizations that ran legacy LAPS for years and are now trying to replace it with Windows LAPS through Intune — without fully removing the old solution first. Policy conflicts, race conditions on the managed account, and unexpected password lockouts are the result.

Why This Happens

Windows LAPS is not "a new version of legacy LAPS." It's a completely different mechanism — built on the Windows LAPS CSP (Configuration Service Provider) rather than the legacy Group Policy extension (AdmPwd.dll). Several architectural differences create deployment traps that don't exist with GPO-based LAPS:

Entra ID requires a tenant-wide feature toggle. For Entra-joined devices (not hybrid-joined), Microsoft blocks devices from posting LAPS passwords to the cloud until a global switch is enabled at the tenant level. The Intune policy reaches the device and is processed successfully, but the device cannot upload the password to Entra ID because the feature is disabled tenant-wide. Important nuance: for Hybrid Entra Join backing up to on-premises AD, this step is not required.

LAPS RBAC in Intune is more granular than expected. Password rotation is a separate action called Remote tasks: Rotate Local Admin Password, which is NOT included in any built-in Intune role — not even in Endpoint Security Manager. You must create a custom role.

OS support depends on specific KB updates from April 2023. The LAPS CSP is not available on older Windows builds. On Windows 10, KB5025221 (build 19042.2846 or later) is required. Without it, the LAPS CSP doesn't exist on the device, the policy shows "Success" in Intune, but nothing happens locally.

Legacy LAPS blocks Windows LAPS when both target the same account. If AdmPwd.dll is still installed and both the old GPO and the new Intune policy target the Administrator account, the results are unpredictable. The CSP takes precedence according to Microsoft's documentation on supported policy roots, but legacy LAPS can overwrite the password before the CSP syncs it to the portal.

Step-by-Step Resolution

Step 1: Enable Windows LAPS in Entra ID (Entra-joined devices only)

If your devices are Entra-joined (not hybrid), you must enable the feature at the tenant level:

1. Sign in to https://entra.microsoft.com as a Cloud Device Administrator
2. Navigate to: Identity → Devices → Overview → Device settings
3. Find Enable Local Administrator Password Solution (LAPS) and set it to Yes
4. Save

You can also do this via Microsoft Graph:

# Check current state
$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy"
$policy.localAdminPassword

# Enable LAPS in Entra ID
$body = @{
    localAdminPassword = @{
        isEnabled = $true
    }
}
Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy" `
    -Body ($body | ConvertTo-Json)

Step 2: Verify KB requirements on Windows 10 and 11 devices

Windows LAPS CSP requires the April 11, 2023 cumulative update:

• Windows 10 20H2/21H2/22H2: KB5025221 (build 19042.2846 or later)
• Windows 11 21H2: KB5025224 (build 22000.1817 or later)
• Windows 11 22H2: KB5025239 (build 22621.1555 or later)

Check the build version on a device:

# Check OS build
Get-ComputerInfo | Select-Object OsVersion, WindowsVersion, OsBuildNumber

# Verify the LAPS CSP registry key exists
Get-Item "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\LAPS" -ErrorAction SilentlyContinue

If the registry key doesn't exist, the device is missing the required KB and the LAPS CSP is unavailable — regardless of what Intune reports for the policy assignment.

Step 3: Confirm the local administrator account exists

Windows LAPS can only manage an account that already exists. On devices running anything older than Windows 11 24H2, LAPS does NOT create accounts automatically. (Windows 11 24H2 introduced Automatic Account Management mode.)

Check on the device:

# List local accounts
net user

# Check if the Administrator account is enabled
Get-LocalUser -Name "Administrator" | Select-Object Name, Enabled

# Enable it if disabled
Enable-LocalUser -Name "Administrator"

If the Intune policy specifies a custom account name in "Name of administrator account to manage" and that account doesn't exist on the device, LAPS logs Event ID 10013 and does nothing. Check for trailing spaces in the account name field — this is a documented cause of 10013.

Step 4: Create the LAPS policy in Intune

In Intune Admin Center: Endpoint Security → Account protection → Create Policy → Windows 10 and later → Local admin password solution (Windows LAPS)

Key settings:

• Backup directory: Azure Active Directory (for cloud backup) or Active Directory (for on-premises)
• Password age days: 30 default, 14-30 recommended
• Password length: 15 characters minimum
• Password complexity: 4 (uppercase + lowercase + digits + special characters)
• Post-authentication actions: Reset password and logoff

Critical assignment rule: assign the policy to device groups, not user groups. Assigning to user groups can cause the LAPS configuration to change each time a different user signs in to a shared device, creating conflicts.

Step 5: Check the LAPS Event Log on the device

After deploying the policy, the Event Log is your first diagnostic stop:

Event Viewer → Applications and Services Logs → Microsoft → Windows → LAPS → Operational

Key Event IDs:

If you see 10013: the account doesn't exist or the name in policy has a typo or trailing space.
If you see 10026 or 10028: the device has a registration problem in Entra. Run dsregcmd /status and look at the Device Status and SSO Data sections.

Step 6: Force LAPS policy processing

Instead of waiting for the hourly scheduled cycle, trigger processing manually:

# Run on the target device as Administrator
Invoke-LapsPolicyProcessing

# Get full diagnostics
Get-LapsDiagnostics

# Check current LAPS password from a management workstation
Get-LapsAADPassword -DeviceIds "<DeviceId>" -IncludePasswords

If LAPS is correctly configured, you should see Event ID 10004 within a few minutes of running Invoke-LapsPolicyProcessing, and the password should appear in the Intune/Entra portal.

Step 7: Set up RBAC for the help desk

Password rotation is NOT available in any built-in Intune role. You must create a custom role:

1. Intune Admin Center: Tenant administration → Roles → Create custom role
2. Add permissions:
   • Managed devices: Read
   • Organization: Read
   • Remote tasks: Rotate Local Admin Password
3. Assign the role to the help desk group with the appropriate device scope

To read the actual password (not just trigger rotation), the account needs the Microsoft Entra role Cloud Device Administrator or a custom Entra role with microsoft.directory/deviceLocalCredentials/password/read.

Common Pitfalls and Edge Cases

Pitfall 1: Legacy LAPS and Windows LAPS race condition on the same account

If legacy LAPS MSI is still installed and both the old GPO policy and the new Intune policy target the Administrator account, you get a race condition. The LAPS CSP wins according to Microsoft's supported policy roots hierarchy, but legacy LAPS can overwrite the password before the CSP syncs it to the portal.

Migration requires either the immediate transition approach (disable legacy LAPS GPO and deploy Windows LAPS policy simultaneously) or the side-by-side approach with a second local account:

# Check if legacy LAPS CSE is still registered
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}" -ErrorAction SilentlyContinue

# Remove legacy LAPS MSI
msiexec.exe /q /uninstall {97E2CA7B-B657-4FF7-A6DB-30ECC73E1E28}

Pitfall 2: Windows 11 24H2 Pro doesn't include LAPS by default

Windows 11 24H2 Pro edition doesn't ship with LAPS built in. You won't see LAPS policy settings or Event Viewer logs unless you deploy the legacy LAPS MSI as a prerequisite — which is counterintuitive. This doesn't affect Enterprise or Education editions, which include LAPS natively. Audit your device fleet edition mix before rolling out LAPS at scale.

Pitfall 3: Deleting a device from Entra ID destroys the LAPS password permanently

When a device is deleted from Entra ID (common during stale device cleanup), the LAPS credential stored in the cloud is gone with no recovery path. If you delete a device and then re-enroll it, LAPS generates a new password only after the next processing cycle — the old password is unrecoverable.

The practical consequence: if a device is locked out (user forgot their password, local admin is the only way in) and the LAPS password is gone, you're looking at a full device reset. Always export LAPS passwords before cleanup operations:

# Export LAPS passwords before deregistering stale devices
$cutoff = (Get-Date).AddDays(-90)
$staleDevices = Get-MgDevice -Filter "operatingSystem eq 'Windows'" |
    Where-Object { $_.ApproximateLastSignInDateTime -lt $cutoff }

$staleDevices | ForEach-Object {
    $laps = Get-LapsAADPassword -DeviceIds $_.DeviceId -IncludePasswords -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        DeviceName     = $_.DisplayName
        DeviceId       = $_.DeviceId
        Password       = $laps.Password
        PasswordExpiry = $laps.PasswordExpirationTime
        LastSignIn     = $_.ApproximateLastSignInDateTime
    }
} | Export-Csv -Path "laps_backup_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Pitfall 4: Local password policy conflicts block LAPS (Event ID 10027)

If the local or domain password policy enforces a minimum length longer than what LAPS is configured to generate, LAPS cannot set the password and logs Event ID 10027. Classic example: domain GPO requires 20 characters minimum, LAPS policy is set to 14. LAPS generates a 14-character password, Windows rejects it.

Diagnose:

net accounts

Fix: set LAPS password length to at least the domain policy minimum, add 2-3 characters of margin. Complexity level 4 in LAPS (all character types) typically satisfies domain complexity requirements.

Pitfall 5: Post-authentication actions cause unexpected logoffs

The Post-authentication actions: Reset password and logoff setting forces a logoff after the local admin account is used. For help desk workflows this is the intended behavior, but if an admin uses the local account for a long operation (deployment, servicing), they'll be forcibly logged off when the grace period expires (default 24 hours after password use). Set Post-authentication reset delay (hours) to match your actual servicing windows — not the security-ideal value, but the operationally realistic one.

Summary

• Windows LAPS via Intune requires three prerequisites before the policy does anything: LAPS enabled in Entra ID (for Entra-joined devices), the April 2023 KB on all devices, and the managed local account already existing
• Event IDs 10013, 10026, and 10028 are the three most common failures — each has a different root cause and a different fix
• Legacy LAPS migration: disable the old GPO and deploy the new Intune policy simultaneously, not sequentially
• Help desk password rotation requires a custom Intune role — no built-in role includes Rotate Local Admin Password
• Deleting a device from Entra destroys the LAPS password permanently — export before any device cleanup run
• Assign LAPS policy to device groups, not user groups — user group assignment causes configuration conflicts on shared devices