Deploying Windows LAPS: schema, permissions, policy

A shared local Administrator password is the cheapest lateral movement path in any Windows estate. Dump the local SAM on one workstation and the same NTLM hash authenticates to every machine imaged from the same build, which is why pass-the-hash remains effective in networks that have otherwise invested heavily in hardening. Windows LAPS fixes this by giving every device a unique, randomly generated local admin password that rotates automatically and is stored in Active Directory or Microsoft Entra ID.

The service account pillar introduces LAPS in a few lines. This guide is the full deployment: prerequisites and schema, the permission model that decides who can read passwords, encryption, the Group Policy settings that matter, migration from legacy Microsoft LAPS, and how to prove every device is actually rotating.

Measure: prerequisites and current state

Windows LAPS is built into Windows 11, Windows 10 and Windows Server 2019 and later through the April 2023 cumulative updates, and is native in Windows Server 2025. There is nothing to install on clients. Legacy Microsoft LAPS (the AdmPwd MSI and ms-Mcs-AdmPwd attribute) is deprecated, and recent Windows 11 releases block the legacy client-side extension.

Measure how many devices have any LAPS coverage today:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
$props = @('OperatingSystem', 'LastLogonTimestamp')
foreach ($attr in 'ms-Mcs-AdmPwdExpirationTime', 'msLAPS-PasswordExpirationTime') {
    if (Get-ADObject -SearchBase $schemaNC -LDAPFilter "(lDAPDisplayName=$attr)") { $props += $attr }
}
$computers = Get-ADComputer -Filter 'Enabled -eq $true' -Properties $props

$computers | Group-Object {
    if ($_.'msLAPS-PasswordExpirationTime') { 'Windows LAPS' }
    elseif ($_.'ms-Mcs-AdmPwdExpirationTime') { 'Legacy LAPS' }
    else { 'None' }
} | Select-Object Name, Count

Requesting an attribute that is not in the schema makes Get-ADComputer fail, so the script only asks for the LAPS attributes that exist: forests without the legacy ms-Mcs-AdmPwd* extension, or not yet extended for Windows LAPS, still get a count. If msLAPS-PasswordExpirationTime is missing from the schema, that is itself a useful answer. Note whether the domain functional level is Windows Server 2016 or higher, since encryption depends on it.

Audit: who can already read passwords

Before extending anything, look at who holds All Extended Rights or Control Access on computer OUs. Those principals can read confidential attributes, including LAPS passwords, once they exist. Legacy LAPS deployments frequently leak this way through helpdesk delegations.

# After the schema update, this reports every principal with extended rights on each OU
Find-LapsADExtendedRights -Identity "OU=Workstations,DC=corp,DC=example,DC=com"

# Legacy LAPS equivalent, if the AdmPwd.PS module is still present
Find-AdmPwdExtendedRights -Identity "Workstations" | Format-List

Remove unexpected grants before rollout. The same review belongs in your broader ACL audit.

Enforce: schema and permissions

Extend the schema

Run once per forest from a machine with the LAPS PowerShell module, as a member of Schema Admins, ideally from a privileged access workstation.

Update-LapsADSchema -Verbose

This adds msLAPS-PasswordExpirationTime, msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-EncryptedPasswordHistory, msLAPS-EncryptedDSRMPassword and msLAPS-EncryptedDSRMPasswordHistory to computer objects. It does not touch the legacy attributes.

Grant self-write, read and reset

Each computer must be able to write its own password. Readers and resetters are granted per OU, following your tier model: workstation OUs to workstation support, server OUs to server admins, domain controllers to Tier 0 only.

$wks = "OU=Workstations,DC=corp,DC=example,DC=com"
$srv = "OU=Servers,DC=corp,DC=example,DC=com"

Set-LapsADComputerSelfPermission -Identity $wks
Set-LapsADComputerSelfPermission -Identity $srv

Set-LapsADReadPasswordPermission  -Identity $wks -AllowedPrincipals "CORP\T2-Workstation-Admins"
Set-LapsADResetPasswordPermission -Identity $wks -AllowedPrincipals "CORP\T2-Workstation-Admins"
Set-LapsADReadPasswordPermission  -Identity $srv -AllowedPrincipals "CORP\T1-Server-Admins"

# Audit every password read on these OUs (Directory Service Access auditing must be enabled)
Set-LapsADAuditing -Identity $wks -AuditedPrincipals "Everyone" -AuditType Success
Set-LapsADAuditing -Identity $srv -AuditedPrincipals "Everyone" -AuditType Success

Reads then appear as event 4662 on the DC servicing the request, which lets you alert on bulk retrieval. The auditing and detection pillar covers the audit policy that makes 4662 visible.

Enforce: the Group Policy settings

Windows LAPS settings live under Computer Configuration > Policies > Administrative Templates > System > LAPS. If you do not see the folder, copy LAPS.admx and LAPS.adml from an updated Windows machine into the central store. Intune-managed devices use the LAPS CSP with the same settings.

On Windows Server 2025 and Windows 11 24H2, additional settings let LAPS create and manage the local account itself and generate passphrases; they are optional and depend on the OS version of the managed device.

The post-authentication action matters most. A LAPS password that stays valid for 30 days after a technician types it into a compromised machine is barely better than a static one.

Force processing and check the log

Invoke-LapsPolicyProcessing
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Errors in that log (usually missing self-permission or no DC reachable) are the fastest way to diagnose a device that never reports.

Domain controllers and Entra-backed devices

Domain controllers have no local SAM accounts in normal operation; the account that matters is the Directory Services Restore Mode (DSRM) administrator. Windows LAPS can manage the DSRM password when Enable password backup for DSRM accounts is set in a GPO linked to the Domain Controllers OU, the backup directory is Active Directory and password encryption is enabled. The password lands in msLAPS-EncryptedDSRMPassword, and the authorized decryptors should be Domain Admins or a dedicated Tier 0 recovery group, never a helpdesk group. Document the retrieval in your forest recovery plan, because you will need it when DCs cannot be trusted to answer LDAP queries: record which Tier 0 accounts can decrypt it and practise retrieval during recovery rehearsals.

For Entra-joined and hybrid-joined devices managed by Intune, the same settings are delivered through the LAPS CSP with Backup directory set to Microsoft Entra ID. Retrieval then runs through the Entra admin center or Microsoft Graph, controlled by the DeviceLocalCredential.Read.All Graph permission or a role such as Cloud Device Administrator, and every read is recorded in Entra audit logs. A device can back up to only one directory at a time, so decide per device population rather than per policy setting, and avoid a GPO and an Intune policy both targeting the same machine.

Migrating from legacy Microsoft LAPS

Windows LAPS can process legacy LAPS GPO settings in emulation mode when the legacy client-side extension is not installed, but the cleaner path is a planned cutover:

1. Extend the schema and set permissions as above; legacy attributes stay intact.
2. Deploy the Windows LAPS GPO to a pilot OU. If the legacy CSE is installed and managing the same account, Windows LAPS defers to it, so uninstall the legacy MSI on pilot machines or target a different account.
3. Confirm msLAPS-PasswordExpirationTime populates and passwords are retrievable with Get-LapsADPassword.
4. Update helpdesk tooling and runbooks from Get-AdmPwdPassword to Get-LapsADPassword.
5. Unlink the legacy GPO, remove the MSI through software deployment, and after a full rotation cycle clear ms-Mcs-AdmPwd values so stale passwords do not linger.

Verify

# Coverage: enabled computers without a current Windows LAPS expiration timestamp
Get-ADComputer -Filter 'Enabled -eq $true' -Properties msLAPS-PasswordExpirationTime, LastLogonTimestamp |
  Where-Object { -not $_.'msLAPS-PasswordExpirationTime' -and
                 [datetime]::FromFileTime($_.LastLogonTimestamp) -gt (Get-Date).AddDays(-30) } |
  Select-Object Name

# Sample a device: source, expiry and whether it is encrypted
Get-LapsADPassword -Identity "WKS-01" | Select-Object ComputerName, Source, PasswordUpdateTime, ExpirationTimestamp, DecryptionStatus

# Confirm readers are who you expect
Find-LapsADExtendedRights -Identity "OU=Workstations,DC=corp,DC=example,DC=com"

Source should read EncryptedPassword on devices where encryption is enabled; CleartextPassword means the encryption policy has not applied. As a negative test, run Get-LapsADPassword -AsPlainText from an account that should not have access and confirm it fails. Tools such as PingCastle also flag missing or partial LAPS coverage.

What it breaks

• Helpdesk processes built on a known password. Imaging scripts, remote support tools and break-glass procedures that assume a common local admin password stop working. Document retrieval through Get-LapsADPassword or the Entra portal before rollout.
• Encryption and older readers. Encrypted passwords can only be read with the Windows LAPS tools on updated machines; legacy LAPS UI and third-party tools that read ms-Mcs-AdmPwd see nothing.
• Post-authentication resets log off sessions of the managed account after the grace period, which can interrupt long troubleshooting sessions if set too short.
• Restoring an old image or VM snapshot brings back a password that no longer matches AD. Password history in encrypted mode is what lets you recover.
• Devices that rarely reach a DC keep their password past expiry and rotate on the next contact; Entra backup is often a better fit for them.

Related reading: the LAPS glossary entry for a quick definition, the Passwords & Service Accounts topic, and migrating service accounts to gMSA, which applies the same unique-and-rotating principle to domain service identities.