Windows · LAPS

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.

Quick idea: Windows LAPS generates a unique local administrator password on every managed device, rotates it on a schedule, and stores it in Active Directory where only explicitly authorised accounts can read it back.
Windows LAPS

The built-in, native replacement for the legacy Microsoft LAPS download.

ms-LAPS-Password

The AD schema attribute storing the current password, marked confidential.

BackupDirectory

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.

Important: Windows LAPS is available on Windows Server 2019 and Windows Server 2022 with the April 11, 2023 update or later, Windows Server 2025 natively, and Windows 10/11 with the same April 2023 update or later. There is nothing to install — it ships in the OS and only needs to be configured.

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.

Clear-Text Storage

Password stored in plain form in AD, secured only by the attribute’s access control list.

Encrypted Storage

Password stored encrypted; only the configured decryption principal can read it in plain text. Requires domain functional level 2016 or later.

Entra ID Backup

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.

In Active Directory: Windows LAPS can also manage a domain controller’s DSRM account password — the local recovery credential used when booting a DC into Directory Services Restore Mode. Rotating that automatically closes a credential that, in most environments, is set once at promotion and never touched again.

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 2016YesNoNo
DFL 2016+, with some Server 2016 or earlier DCsYesYesOnly on Server 2019+ DCs
DFL 2016+, all DCs on Server 2019 or laterYesYesYes

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")
Key point: Members of Domain Admins already have both read and expiration permission by default — these cmdlets are for delegating those rights to a narrower group, such as a help desk team, without adding them to Domain Admins.

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.

Important: Setting 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
BackupDirectory0 (Disabled)Where the password backs up: 0 disabled, 1 Entra ID, 2 Active Directory. Gates every other setting.
AdministratorAccountNameEmpty (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.
PasswordAgeDays30Maximum password age, 1–365 days (minimum 7 if backing up to Entra ID).
PasswordLength14Password length, 8–64 characters. Ignored unless PasswordComplexity is set.
PasswordComplexity41–3 exist only for legacy compatibility; 4 (upper, lower, number, special) is the recommended minimum.
ADPasswordEncryptionEnabledTrueEncrypts the password in AD rather than storing clear text. Requires DFL 2016+.
ADPasswordEncryptionPrincipalDomain AdminsWho can decrypt the stored password — separate from who can merely query it.
PostAuthenticationActions3 (reset password + sign out)What happens once the post-authentication grace period expires after the managed account is used.
Practical rule: Leave 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
Healthy output: 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
10018The password was successfully generated and backed up to Active Directory.
10027Password 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.

Key takeaway: After enabling Windows LAPS, confirm success with 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 in this series

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.