Windows LAPS Implementation: Step-by-Step Enterprise Guide (2026)

If an attacker compromises a single endpoint in your environment and finds a reused local Administrator password, they own every other workstation that shares it. That single misconfiguration is how a phishing click on one helpdesk laptop becomes a 4,000-endpoint ransomware incident — and it’s exactly what Windows LAPS (Local Administrator Password Solution) was built to prevent. This is the complete step-by-step Windows LAPS implementation guide for enterprise environments in 2026: AD schema preparation, KDS root key generation, encrypted password storage, Group Policy reference, PowerShell administration, and the full DSRM password backup workflow for Domain Controllers.

Windows LAPS is no longer the legacy MSI you used to bolt onto member servers. It’s a native Windows component shipped with every supported Windows 11 and Windows Server 2022+ release, supports both on-prem Active Directory and Microsoft Entra (Azure AD) backends, encrypts stored passwords at rest, and — critically — manages the Directory Services Restore Mode (DSRM) password on Domain Controllers, something the legacy product never could.

TL;DR — Windows LAPS deployment in one screen

The 8 actions that get you to a working enterprise deployment:

1. Schema — Update-LapsADSchema on a Schema Admin account
2. Encryption key — Add-KdsRootKey -EffectiveImmediately on a DC
3. Self-update permission — Set-LapsADComputerSelfPermission per OU
4. Read permission (RBAC tiered) — Set-LapsADReadPasswordPermission to scoped groups only
5. Group Policy — Configure backup directory, password settings, post-auth actions, encryption
6. DC DSRM — Enable DSRM backup on Domain Controllers (unique to Windows LAPS)
7. Deploy + verify — Invoke-LapsPolicyProcessing then Get-LapsDiagnostics
8. Retrieve passwords — Get-LapsADPassword -Identity HOST -AsPlainText

Total time for a clean lab deployment: under one hour. Production rollouts with phased enforcement: 2–4 weeks.

Why Windows LAPS matters in 2026

A few realities that make this a top-tier priority, not a “nice-to-have”:

Lateral movement is almost always credential-driven. The 2024 Microsoft Digital Defense Report puts >80% of ransomware incidents on a credential-abuse path. Once attackers get a foothold, they harvest cached credentials and password hashes with Mimikatz, Lazagne, or built-in procdump lsass.exe. If your local Administrator accounts share a password, one compromised hash unlocks the entire fleet — what red teams call pass-the-hash propagation.

Pass-the-hash mitigation is a CIS Controls v8 mandate. CIS Control 5.4 (Unique Local Admin Passwords) and Control 6 (Access Control Management) both explicitly call out LAPS-style rotation as a baseline requirement. Auditors check for it. Cyber insurance providers ask about it.

Windows LAPS is now free, native, and cloud-aware. Microsoft’s April 2023 update brought Windows LAPS into the OS itself, retired the legacy MSI installer, added password encryption (the legacy product stored passwords in plaintext within the AD attribute), and introduced Microsoft Entra (Azure AD) as a supported backend. If you’re still running Microsoft LAPS legacy in 2026, you’re carrying technical debt with active attack surface.

Companion control to NTLM hardening. Disabling local admin credential reuse closes the relay/pass-the-hash chain at the credential level; disabling NTLM closes it at the protocol level. Deploy both.

Windows LAPS vs Legacy Microsoft LAPS: what actually changed

This is the comparison most administrators want when planning their migration. Print it.

If you’re migrating, run both side by side during transition (Windows LAPS will ignore legacy attributes by default) and decommission the legacy MSI and its GPOs after a 30-day verification window.

Windows LAPS architecture

Three components do the work:

1. The client extension is built into the OS. It runs as part of the Group Policy Client service and applies whichever LAPS policy it finds (GPO, Intune MDM channel, or local registry).
2. The directory backend (AD or Entra) stores the encrypted password and metadata. In AD, that means five new attributes on every computer object; in Entra, equivalent properties on the device object.
3. The management surface is split: Group Policy for AD-joined hosts, Intune CSP (./Device/Vendor/MSFT/LAPS) for MDM-managed hosts, or direct registry under HKLM\Software\Microsoft\Policies\LAPS for testing.

The encryption flow is what makes this version a meaningful improvement over the legacy product. When password encryption is enabled, the client retrieves the KDS root key from a DC, derives a key bound to a specific principal (a user or group authorized to decrypt — set via “Configure authorized password decryptors”), encrypts the password with that key, and writes the ciphertext to msLAPS-EncryptedPassword. Only members of the authorized decryptor group can read the password in plaintext. Domain Admins are not implicitly authorized — that’s a feature, not a bug.

Prerequisites checklist

Before you run a single command, confirm:

• Domain functional level Windows Server 2016 or higher (required for KDS root key infrastructure used in encryption)
• At least one DC at Windows Server 2019 with the April 2023 cumulative update (or 2022 / 2025)
• Schema Admin account available for Update-LapsADSchema
• Console / out-of-band access to one DC in case Group Policy misconfiguration locks you out remotely
• GPO backup taken (Backup-GPO -All -Path C:\GPOBackups)
• Pilot OU defined — never apply LAPS policy domain-wide on day one
• RBAC tier groups created — e.g., LAPS-Readers-Tier0, LAPS-Readers-Tier1, LAPS-Readers-Tier2
• Naming convention for managed account decided — usually the built-in Administrator (RID 500), but can be a custom local admin
• Legacy LAPS inventoried — if installed, plan parallel run then decommission
• DSRM password backup policy approved for DCs — this is sensitive

How to implement Windows LAPS step by step

The next sections expand each step with the technical detail you’ll need.

Step 1: Update the AD schema (technical detail)

You only do this once per forest. It’s irreversible — there’s no Remove-LapsADSchema. Test in a lab forest first if your governance requires it.

# Confirm forest functional level
Get-ADForest | Select-Object Name, ForestMode

# Confirm schema version BEFORE
(Get-ADObject -Identity (Get-ADRootDSE).schemaNamingContext -Properties objectVersion).objectVersion

# Run the schema extension
Import-Module LAPS
Update-LapsADSchema -Verbose

# Confirm the new attributes exist
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter 'name -like "msLAPS-*"' |
  Select-Object Name, ObjectClass

You should see five msLAPS-* attribute objects. If you only see one or two, the schema extension partially failed — re-run as a Schema Admin, ideally on the FSMO Schema Master.

Step 2: Generate the KDS root key (encryption foundation)

Without a KDS root key, Enable password encryption = Enabled is a no-op. Worse, the policy may silently fall back to plaintext storage (legacy attribute path) — exactly what you’re trying to avoid.

# Check if a KDS root key already exists (e.g., from gMSA setup)
Get-KdsRootKey

# If empty, create one. In a multi-DC environment, omit -EffectiveImmediately
# and use -EffectiveTime ((Get-Date).AddHours(10)) so replication completes.
Add-KdsRootKey -EffectiveImmediately

# Verify
Get-KdsRootKey | Select-Object KeyId, EffectiveTime, CreationTime

Step 3: Grant computer self-update permissions

Every computer object needs the ability to write its own LAPS attributes. This is a one-time Set-LapsADComputerSelfPermission per OU containing managed computers.

# Recursively grant on the parent OU
Set-LapsADComputerSelfPermission -Identity 'OU=Servers,DC=corp,DC=local'
Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=local'
Set-LapsADComputerSelfPermission -Identity 'OU=Domain Controllers,DC=corp,DC=local'

# Verify the ACE was added
$ou = Get-ADOrganizationalUnit -Identity 'OU=Servers,DC=corp,DC=local'
(Get-Acl "AD:$($ou.DistinguishedName)").Access |
  Where-Object { $_.IdentityReference -eq 'NT AUTHORITY\SELF' -and $_.ActiveDirectoryRights -match 'WriteProperty' }

If the permission isn’t there, you’ll see Event ID 10039 (insufficient permissions) flooding the client’s Microsoft-Windows-LAPS/Operational log.

Step 4: Grant scoped read permissions (RBAC tiering)

This is the single most-skipped step, and the one that leaves the most security debt. Most administrators grant Domain Admins blanket read — which means a single compromised DA account exposes every managed password in the forest.

The right approach is tiered delegation aligned with Microsoft’s three-tier admin model:

# Create the read-only groups (universal security groups, in their own protected OU)
New-ADGroup -Name 'LAPS-Readers-Tier0' -GroupScope Universal -GroupCategory Security -Path 'OU=Tier0-Groups,DC=corp,DC=local'
New-ADGroup -Name 'LAPS-Readers-Tier1' -GroupScope Universal -GroupCategory Security -Path 'OU=Tier1-Groups,DC=corp,DC=local'
New-ADGroup -Name 'LAPS-Readers-Tier2' -GroupScope Universal -GroupCategory Security -Path 'OU=Tier2-Groups,DC=corp,DC=local'

# Grant scoped read per OU
Set-LapsADReadPasswordPermission -Identity 'OU=Domain Controllers,DC=corp,DC=local' -AllowedPrincipals 'CORP\LAPS-Readers-Tier0'
Set-LapsADReadPasswordPermission -Identity 'OU=Servers,DC=corp,DC=local'             -AllowedPrincipals 'CORP\LAPS-Readers-Tier1'
Set-LapsADReadPasswordPermission -Identity 'OU=Workstations,DC=corp,DC=local'        -AllowedPrincipals 'CORP\LAPS-Readers-Tier2'

# Audit who currently has the extended right
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'

Find-LapsADExtendedRights is the killer audit cmdlet. Run it quarterly and after any AD permission change — it lists every principal with ExtendedRight on the LAPS attributes, making over-privileged-read drift obvious.

Step 5: Configure LAPS Group Policy

Here’s the complete GPO reference table for Windows LAPS, with recommended values for an enterprise baseline:

GPO link strategy: one policy linked to each tier OU, configured with that tier’s reader group. This makes the encryption key derivation tier-scoped — a Tier 2 LAPS-Reader cannot decrypt a Tier 0 password even if the AD ACL were misconfigured.

Step 6: Enable DSRM password backup on Domain Controllers

This is the capability that makes Windows LAPS materially better than the legacy product. The DSRM (Directory Services Restore Mode) password is the local account password used when a DC boots into safe mode for AD recovery. Historically it was manually set, rarely rotated, and almost never tested.

Windows LAPS rotates it on the same schedule as the regular Administrator password, stores the encrypted value in msLAPS-EncryptedDSRMPassword, and lets you retrieve it with the standard Get-LapsADPassword cmdlet — just specify the DSRM source:

# Retrieve current DSRM password
Get-LapsADPassword -Identity DC01 -Source EncryptedDSRMPassword -AsPlainText

# Force an immediate DSRM rotation (after restoration drill, for example)
Reset-LapsPassword -Identity DC01

# Audit who has decryptor permission on DSRM attribute specifically
Find-LapsADExtendedRights -Identity 'OU=Domain Controllers,DC=corp,DC=local'

Keep the DSRM read permission on Tier 0 only — never delegate this to Tier 1/2 reader groups.

Step 7: Deploy and verify

After GPO is configured and linked:

# Force policy refresh
gpupdate /force

# Force LAPS to evaluate the policy immediately
Invoke-LapsPolicyProcessing

# Read the resolved policy
Get-LapsAADPassword -Identity (hostname)   # for Entra-backed
# or
Get-LapsADPassword  -Identity (hostname) -AsPlainText   # for AD-backed

# Generate a full diagnostics bundle
Get-LapsDiagnostics -OutputFolder C:\temp

# Watch the event log
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
  Format-Table TimeCreated, Id, LevelDisplayName, Message -AutoSize

Event IDs to know:

Step 8: Retrieve, rotate, and audit passwords

Daily-operations workflow for a helpdesk or SOC analyst with read permission:

# Read the current password
Get-LapsADPassword -Identity WKSTN-001 -AsPlainText

# Show the full attribute set (rotation timestamp, account name, source)
Get-LapsADPassword -Identity WKSTN-001 -IncludeHistory | Format-List

# After a privileged session ends, force immediate rotation
Reset-LapsPassword -Identity WKSTN-001

# Show password history (last 12 rotations, if encrypted history is enabled)
Get-LapsADPassword -Identity WKSTN-001 -IncludeHistory -AsPlainText

For SOC visibility, enable Event ID 4662 auditing on the LAPS attributes (configured in Default Domain Controllers Policy → Audit Object Access → Directory Service Access) and forward Domain Controller Security logs to your SIEM. Every password retrieval generates a 4662 with the principal name and the attribute GUID — full read-audit trail.

Windows LAPS PowerShell command cheat sheet

The full LAPS module, the way you’ll actually use it. Copy-paste-ready.

# === SETUP ===
Import-Module LAPS
Update-LapsADSchema -Verbose
Add-KdsRootKey -EffectiveImmediately   # or -EffectiveTime for multi-DC

# === DELEGATION ===
Set-LapsADComputerSelfPermission   -Identity 'OU=Workstations,DC=corp,DC=local'
Set-LapsADReadPasswordPermission   -Identity 'OU=Workstations,DC=corp,DC=local' -AllowedPrincipals 'CORP\LAPS-Readers-Tier2'
Set-LapsADResetPasswordPermission  -Identity 'OU=Workstations,DC=corp,DC=local' -AllowedPrincipals 'CORP\LAPS-Resetters-Tier2'

# === AUDIT ===
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'

# === OPERATIONS ===
Get-LapsADPassword     -Identity WKSTN-001 -AsPlainText
Get-LapsADPassword     -Identity WKSTN-001 -IncludeHistory -AsPlainText
Reset-LapsPassword     -Identity WKSTN-001
Invoke-LapsPolicyProcessing                         # force immediate evaluation on local host
Get-LapsDiagnostics    -OutputFolder C:\temp

Save this as LAPS-Cheatsheet.ps1 and pin it on your admin jump host.

Security best practices

Twelve enterprise patterns that separate a real LAPS deployment from a checkbox one:

1. Always enable encryption. Plaintext storage in 2026 is indefensible at audit.
2. Tier your reader groups. Tier 0 / 1 / 2 — never blanket Domain Admins.
3. Rotate KDS root keys periodically. Microsoft doesn’t enforce a rotation interval, but every 5 years is a defensible baseline.
4. Audit read access with Event 4662. Forward to SIEM with a 90-day retention minimum.
5. Enable post-authentication actions. Reset the password after each privileged session, not just on schedule.
6. Lower password age in high-security tiers. 30 days for general fleet; 7 days for Tier 0 servers.
7. Run Find-LapsADExtendedRights quarterly. Detect ACL drift before it becomes an audit finding.
8. Use Just-In-Time (JIT) access for password retrieval. Combine LAPS with Privileged Access Management (PIM) — read permission is granted only during an approved access window.
9. Protect the LAPS-Readers groups themselves. Place them in a protected OU; restrict membership-modify rights to a small group of identity admins; review membership monthly.
10. Don’t disable the built-in Administrator. Renaming/disabling it breaks Name of administrator account to manage = blank. If you want a renamed account, configure that explicitly in policy.
11. Test rollback. Document the GPO unlink procedure; practice it on a non-production OU.
12. Decommission legacy LAPS deliberately. Remove the GPO settings, uninstall the MSI, clean up ms-Mcs-AdmPwd attribute reads from any tooling that still references it.

Common mistakes (and how to avoid them)

The recurring failures I see during LAPS engagements:

Troubleshooting guide

When something doesn’t work, this is the order of operations:

1. Confirm the LAPS service is running on the client:

Get-Service -Name LAPS

If it’s stopped, start it: Start-Service LAPS. If it’s missing, the OS doesn’t have Windows LAPS — confirm the build (winver) and patch level.

2. Generate a diagnostics bundle:

Get-LapsDiagnostics -OutputFolder C:\temp

Open the resulting .cab. Inside, LAPS.Diagnostics.log shows policy resolution; LAPS.Diagnostics.json shows the parsed configuration; the event log dump shows recent failures.

3. Re-evaluate policy on demand:

Invoke-LapsPolicyProcessing -Verbose

The verbose output names the exact policy source and reports success/failure for the password rotation.

4. Verify backend connectivity:

# For AD-backed
nltest /sc_query:corp.local
Get-ADDomainController -Discover -Domain corp.local

# For Entra-backed
dsregcmd /status   # look for "AzureAdJoined : YES" and "TenantId : ..."

5. Validate encryption end-to-end:

# Should return a value, not a long error
Get-KdsRootKey
# Should show the authorized decryptor group SID
Get-LapsDiagnostics ... | look for AuthorizedDecryptors

If after all five steps the password still doesn’t rotate, escalate by capturing a network trace with Wireshark filtered to LDAP/MS-RPC traffic to your DC — the LAPS write attempt is observable.

Windows LAPS audit checklist

Use this as a quarterly self-audit. Each item is a yes/no.

• Domain functional level is 2016 or higher
• At least one DC at Server 2019+ with April 2023 cumulative update
• AD schema includes all five msLAPS-* attributes
• KDS root key exists and is older than 24 hours
• Set-LapsADComputerSelfPermission applied to every OU containing managed computers
• Set-LapsADReadPasswordPermission granted only to tiered reader groups (Tier 0/1/2)
• Domain Admins do not have implicit LAPS read
• GPO sets Enable password encryption = Enabled
• GPO sets Configure password backup directory = Active Directory (or Azure AD)
• GPO sets Password complexity = 4, Length ≥ 20, Age ≤ 30 days
• GPO sets Post-authentication actions = Reset password and log off
• GPO sets Configure size of encrypted password history ≥ 6
• DC-specific GPO sets Enable password backup for DSRM account = Enabled
• Event ID 4662 auditing enabled on LAPS attributes
• SIEM ingests Microsoft-Windows-LAPS/Operational from all DCs and a representative client sample
• Find-LapsADExtendedRights reviewed in the last 90 days
• Legacy Microsoft LAPS MSI uninstalled from every host
• Legacy ms-Mcs-AdmPwd* GPO settings removed
• LAPS recovery runbook exists, documenting GPO unlink steps
• Tier-0 admins can retrieve DSRM password via Get-LapsADPassword -Source EncryptedDSRMPassword

If you’re sub-90% on this checklist, your LAPS deployment has visible audit and operational gaps. Fix the no-answers in priority order before chasing additional hardening controls.

Frequently asked questions

Conclusion: ship it this sprint

Windows LAPS is the highest-ROI hardening control in the Windows ecosystem right now: an hour of deployment work eliminates an entire class of lateral-movement attack, satisfies CIS Control 5.4, and gives auditors evidence they actually want to see. The legacy product is technical debt; the modern Windows LAPS is free, native, encrypted by default, and supports both AD and Entra ID backends.

The roadmap from this article:

1. This week: lab deployment on a single test OU. Verify encryption, retrieval, and rotation.
2. Next sprint: pilot rollout to one production OU (server tier first, workstations second). Tiered RBAC from day one.
3. Within 30 days: full enterprise rollout with DSRM backup on DCs and SIEM-forwarded retrieval audit.

Pair this with the NTLM disable guide to close both the credential-reuse vector (LAPS) and the credential-relay vector (NTLM) at the same time — combined, they remove the two most-abused Windows attack surfaces in a single quarter’s hardening work.

If you ran into a Windows LAPS deployment issue not covered here — especially the weird Entra-hybrid edge cases — drop a line. We maintain a running list of “LAPS deployment gotchas” from reader reports.

Share this guide

LinkedIn:

Windows LAPS — the native, encrypted, DC-aware replacement for legacy Microsoft LAPS — eliminates an entire class of lateral-movement attacks for one hour of deployment work. Here’s the full 8-step enterprise rollout: schema, KDS key, tiered RBAC, GPO, DSRM, deploy, verify, audit. 👇

X / Twitter (one-tweet summary):

Windows LAPS rollout in 8 commands: Update-LapsADSchema · Add-KdsRootKey · Set-LapsADComputerSelfPermission · Set-LapsADReadPasswordPermission · Configure GPO · Enable DSRM backup · Invoke-LapsPolicyProcessing · Get-LapsADPassword. Full step-by-step guide:

References

• Microsoft Learn: Windows LAPS overview
• Microsoft Learn: Windows LAPS scenarios using Windows Server Active Directory
• Microsoft Learn: Windows LAPS troubleshooting
• Microsoft Learn: Intune CSP for Windows LAPS
• CIS Microsoft Windows 11 Enterprise Benchmark (Section: Local Admin Password Solution)
• Microsoft Tier model for AD admin tiering
• MITRE ATT&CK T1078.003 — Local Accounts
• MITRE ATT&CK T1550.002 — Pass the Hash