Windows LAPS
Windows LAPS gives every domain-joined machine a unique, automatically rotated local administrator password stored in Active Directory, so a single leaked credential no longer unlocks every server in the building.
The built-in, native replacement for the legacy Microsoft LAPS download.
The AD schema attribute storing the current password, marked confidential.
The one policy setting that decides whether LAPS does anything at all.
What Is Windows LAPS?
Windows Local Administrator Password Solution is a Windows feature that automatically manages the password of a local administrator account on Active Directory-joined and Microsoft Entra-joined devices, and backs that password up to AD or Entra ID. It also manages the Directory Services Restore Mode account password on domain controllers.
Think of a shared local administrator password across every server as a single master key cut identically for every door in the building. It is convenient right up until it leaks, at which point every lock it opens is compromised at once. Windows LAPS replaces that master key with a different, randomly generated key per door, changed on a schedule, held in a safe only certain people can open.
Windows LAPS ships natively as part of Windows and is not the same product as legacy Microsoft LAPS, the standalone MSI download Microsoft released in 2016. Windows LAPS is a separate, native implementation with more features — password encryption in AD, password history, backup to Microsoft Entra ID — and legacy Microsoft LAPS is now deprecated: its installer is blocked outright on Windows 11 23H2 and later.
How It Works
Once policy targets a device, Windows LAPS generates a new password for the managed local account, stores it as an attribute on that computer’s own AD object, and sets an expiration time. Only accounts explicitly granted read permission on that attribute — by default, Domain Admins — can retrieve it.
Password stored in plain form in AD, secured only by the attribute’s access control list.
Password stored encrypted; only the configured decryption principal can read it in plain text. Requires domain functional level 2016 or later.
For Entra-joined or hybrid-joined devices, the password backs up to Microsoft Entra ID instead of AD, secured by Entra RBAC.
A managed device re-checks its policy roughly every hour, and also in response to Group Policy change notifications. If the stored expiration timestamp has passed, the device generates a new password immediately and writes it back to AD — no administrator action required for routine rotation.
Why This Matters for Active Directory
A shared local administrator password is a textbook pass-the-hash and lateral-movement enabler: compromise one workstation, extract that one password’s hash, and an attacker can authenticate as local administrator on every other machine that shares it. Windows LAPS breaks that chain by making every machine’s local administrator password unique, so a credential harvested from one box is useless against the next.
This lines up with the same automatic-credential-management idea covered in Group Managed Service Accounts (gMSA) — AD generating and rotating a secret so no human has to know, type, or remember it. gMSA solves this for service accounts; Windows LAPS solves the equivalent problem for local administrator accounts.
Domain Functional Level and DC Requirements
What Windows LAPS can do in a given domain depends on the domain functional level and how current the domain controllers are — this is worth checking before assuming encryption or DSRM management are available.
| Domain Details | Clear-Text Storage | Encrypted Storage | DSRM Management |
|---|---|---|---|
| DFL earlier than 2016 | Yes | No | No |
| DFL 2016+, with some Server 2016 or earlier DCs | Yes | Yes | Only on Server 2019+ DCs |
| DFL 2016+, all DCs on Server 2019 or later | Yes | Yes | Yes |
Extending the Schema and Setting Permissions
Before any device can back up a password to AD, the schema needs the Windows LAPS attributes added — a one-time, forest-wide operation. Run it from any server with the LAPS PowerShell module, whether or not that server is itself a domain controller. It requires an account with rights to extend the schema, which in practice means Schema Admins membership against a reachable schema master.
# One-time, forest-wide: add the ms-LAPS-* attributes to the AD schema
Update-LapsADSchema -Verbose
With the schema extended, three more one-time steps grant the permissions Windows LAPS needs to actually operate — each scoped to an OU (or the domain root) using -Identity.
# Let computer objects in this OU update their own LAPS password attribute
Set-LapsADComputerSelfPermission -Identity "OU=Servers,DC=lab,DC=example,DC=com"
# Grant a specific group permission to query (read) the password
Set-LapsADReadPasswordPermission -Identity "OU=Servers,DC=lab,DC=example,DC=com" -AllowedPrincipals @("LAB\LapsPasswordReaders")
# Grant a specific group permission to force an early password expiration
Set-LapsADResetPasswordPermission -Identity "OU=Servers,DC=lab,DC=example,DC=com" -AllowedPrincipals @("LAB\LapsPasswordExpirers")
Because every Windows LAPS password attribute is marked confidential, anyone holding an extended-rights grant on the target OU can read it regardless of the permissions set above. Find-LapsADExtendedRights audits exactly who that is, so unexpected access does not go unnoticed.
# Audit who holds extended rights on this OU — a path around normal LAPS permissions
Find-LapsADExtendedRights -Identity "OU=Servers,DC=lab,DC=example,DC=com"
Configuring Policy
Windows LAPS policy is configured through Group Policy, in the Group Policy Management Editor under Computer Configuration > Policies > Administrative Templates > System > LAPS — or through the Windows LAPS CSP via Microsoft Intune for Entra-joined devices. The GPO template ships at %windir%\PolicyDefinitions\LAPS.admx, but it is not copied to a Central Store automatically; do that by hand if the environment uses one.
BackupDirectory is mandatory — every other setting is ignored while it is left at its default of Disabled. Set it to 2 to back up to Active Directory, or 1 for Microsoft Entra ID only.
| Setting | Default | Purpose |
|---|---|---|
BackupDirectory | 0 (Disabled) | Where the password backs up: 0 disabled, 1 Entra ID, 2 Active Directory. Gates every other setting. |
AdministratorAccountName | Empty (built-in account) | Only needed to manage a custom local admin account instead of the built-in one — Windows LAPS never creates the account itself. |
PasswordAgeDays | 30 | Maximum password age, 1–365 days (minimum 7 if backing up to Entra ID). |
PasswordLength | 14 | Password length, 8–64 characters. Ignored unless PasswordComplexity is set. |
PasswordComplexity | 4 | 1–3 exist only for legacy compatibility; 4 (upper, lower, number, special) is the recommended minimum. |
ADPasswordEncryptionEnabled | True | Encrypts the password in AD rather than storing clear text. Requires DFL 2016+. |
ADPasswordEncryptionPrincipal | Domain Admins | Who can decrypt the stored password — separate from who can merely query it. |
PostAuthenticationActions | 3 (reset password + sign out) | What happens once the post-authentication grace period expires after the managed account is used. |
PostAuthenticationResetDelay at its 24-hour default unless there is a specific reason to shorten it — it controls how long a just-used LAPS password remains valid before PostAuthenticationActions forces a reset, and a value of 0 disables that protection entirely.
Commands
Once policy is applied and at least one processing cycle has run, these are the day-to-day commands for retrieving, rotating, and expiring managed passwords.
# Retrieve the current password for a managed computer, in clear text
Get-LapsADPassword -Identity dc01 -AsPlainText
# Retrieve the current password plus password history for a computer
Get-LapsADPassword -Identity dc01 -AsPlainText -IncludeHistory
# Force the stored expiration time to now, so the device rotates at its next policy cycle
Set-LapsADPasswordExpirationTime -Identity dc01
# Run on the managed device itself: process LAPS policy immediately rather than waiting up to an hour
Invoke-LapsPolicyProcessing
# Run on the managed device itself: force an immediate local password rotation
Reset-LapsPassword
Get-LapsADPassword should return DecryptionStatus: Success (or NotApplicable for clear-text storage) and a populated PasswordUpdateTime. A DecryptionStatus of Unauthorized means the account running the command is not the configured ADPasswordEncryptionPrincipal — a permissions gap, not a broken deployment.
Verifying Rotation
Windows LAPS logs to a dedicated event log channel on the managed device. Two event IDs matter most day to day.
| Event ID | Meaning |
|---|---|
10018 | The password was successfully generated and backed up to Active Directory. |
10027 | Password creation failed — almost always PasswordLength or PasswordComplexity configured incompatibly with the device’s local password policy. |
Deployment Issues
| Symptom | Likely Cause | Fix |
|---|---|---|
Get-LapsADPassword returns no password at all |
BackupDirectory is still at its default of Disabled, so no other policy setting takes effect. |
Set BackupDirectory to 2 in the Windows LAPS GPO and allow a policy processing cycle to complete, or run Invoke-LapsPolicyProcessing on the device to skip the wait. |
DecryptionStatus: Unauthorized when querying a password |
The querying account isn’t the group or user configured in ADPasswordEncryptionPrincipal, even though it may have read (query) permission. |
Query permission and decryption permission are separate — confirm the account is a member of the configured ADPasswordEncryptionPrincipal, not just granted read access via Set-LapsADReadPasswordPermission. |
| Event 10027 in the Windows LAPS event log | PasswordLength or PasswordComplexity conflicts with the device’s own local account password policy (e.g. a shorter minimum length enforced locally). |
Align the local security policy’s password requirements with the configured Windows LAPS settings, or relax whichever one is stricter than necessary. |
Schema extension fails when running Update-LapsADSchema |
The account running the cmdlet lacks rights to modify the schema, or the schema master domain controller is unreachable. | Run the cmdlet with an account in Schema Admins, and confirm connectivity to the domain’s schema master with Get-ADForest | Select-Object SchemaMaster. |
| A domain controller’s DSRM password never rotates | ADBackupDSRMPassword defaults to False and has to be explicitly enabled, and encrypted storage requires DFL 2016+. |
Confirm the domain functional level, then explicitly enable ADBackupDSRMPassword and ADPasswordEncryptionEnabled in the policy applied to domain controllers. |
Final Thoughts
Windows LAPS is one of the highest security-value, lowest-effort changes available in a Windows Server environment: no third-party agent, no license beyond what’s already included, and the only real cost is the discipline of setting up permissions deliberately rather than defaulting everyone into Domain Admins to read a password.
Anywhere a shared local administrator password currently exists across more than one machine, that is a live pass-the-hash risk today, not a hypothetical one — and it is exactly the gap Windows LAPS was built to close.
Get-LapsADPassword -Identity <computer> -AsPlainText showing a recent PasswordUpdateTime and DecryptionStatus: Success, and check the device’s Windows LAPS event log for 10018 rather than 10027.
Next, it’s worth covering Credential Guard and the Protected Users group — Windows LAPS closes the shared-local-admin-password gap, and those two features close a related gap around how privileged domain credentials are cached and used during everyday sign-ins.