Windows LAPS is the native Microsoft feature that rotates, encrypts, and stores a unique local admin password on every domain-joined machine. It replaces the legacy Microsoft LAPS MSI, which is deprecated. It has been built into every supported Windows OS since the April 2023 cumulative update.

If you are still running the same local admin password across your estate, one compromised endpoint hands over the rest of it. That is the lateral movement path behind most of the ransomware you read about. This guide walks through a full Windows LAPS deployment in under 40 minutes, including the AD schema extension, GPO configuration, legacy LAPS migration, and the event log channel you will use for detection.

Most AD environments still have the same local admin password on every domain-joined machine. It was set during imaging years ago and never rotated. Sometimes it is in a password manager the helpdesk shares. Sometimes it is on a sticky note in the server room. The effect is the same. One compromised machine is a skeleton key to the rest.

The attack path looks like this:

1. Attacker gets SYSTEM on one workstation (phishing, stolen laptop, unpatched CVE)

2. Dumps the local SAM with secretsdump, mimikatz, or built-in tools

3. Extracts the local admin NTLM hash

4. Replays that hash against every other machine in the subnet

5. If any of those machines have a cached domain admin token, the attacker now has domain admin

Windows LAPS breaks step four. Every machine gets its own unique random password, rotated on a schedule you control, stored encrypted in Active Directory or Entra ID, with read access restricted to named groups. One compromised machine stays one compromised machine.

Want this delivered weekly? The Hardening Brief sends one config change like this every Tuesday. Free.

The original Microsoft LAPS (released 2016) was a separate MSI you installed on DCs and managed endpoints. It worked. It also required ongoing maintenance, separate schema extensions, and manual installation on every managed machine.

Windows LAPS, released April 2023, is a different product that happens to share a name. Key differences:

- No MSI or agent, built into the OS

- Supports both Active Directory and Entra ID as backup directories

- Native password encryption in AD (legacy LAPS stored cleartext)

- Password history

- DSRM account password management for DCs

- Native PowerShell module, no external dependencies

Legacy Microsoft LAPS is deprecated as of Windows 11 23H2 and the MSI installer is blocked on newer OS versions. If you are still running it, start your migration. Windows LAPS includes a Legacy Emulation Mode built specifically for the transition. Use it to move, not to stay.

Before you start:

- At least one DC on Windows Server 2019 or later, fully patched to April 2023 or newer

- Managed clients on Windows 10 21H2, Windows 11, or Windows Server 2019+, with the April 2023 update applied

- Schema Admin and Enterprise Admin rights for the one-time schema extension

- An OU structure that cleanly separates the computers you want to manage

No licensing cost. Windows LAPS is free on every supported platform. If you back up to Entra ID, a Microsoft Entra ID Free license is enough.

On a Windows Server 2019+ DC, open PowerShell as admin:

You should see Update-LapsADSchema, Set-LapsADComputerSelfPermission, Get-LapsADPassword, Reset-LapsPassword, and a handful of others. If nothing comes back, the DC is missing the April 2023 cumulative update. Patch the DC, check again.

There is no separate installer. The module ships in the OS.

Windows LAPS needs new attributes on the computer class in AD. One-time, forest-wide. Run it on the Schema Master DC as a user who is in both Schema Admins and Enterprise Admins:

The cmdlet prompts for confirmation. Accept with A. It adds:

- ms-LAPS-Password (plaintext, only used if encryption is disabled - avoid this)

- ms-LAPS-EncryptedPassword (encrypted, the production default)

- ms-LAPS-PasswordExpirationTime (next scheduled rotation)

- ms-LAPS-EncryptedPasswordHistory (password history)

- ms-LAPS-EncryptedDSRMPassword (DSRM password for DCs themselves)

To confirm it worked, re-run with verbose:

Schema extensions are permanent. Test in a lab first if your environment is heavily regulated.

Managed machines need SELF permission to write their own password and expiration to their computer object in AD:

Replace the OU DN with your actual target. Run it against each OU you want covered. The permission is inherited, so no per-machine config.

Do not use Domain Admins as your LAPS password reader group. If you run a proper tiering model (and if you are reading this, you should be), create one dedicated reader group per tier. Something like LAPSPasswordReaders-T1 and LAPSPasswordReaders-T2. Scope each group to the OUs at that tier. Helpdesk reads T2. Server admins read T1. You should disabled the RID-500 admin accounts on T0 systems.

This is the single biggest difference between a "we deployed LAPS" environment and a "we deployed LAPS correctly" environment. Domain Admins should not be reading workstation passwords at all. If your helpdesk can read a DC password, you have not hardened anything.

The tiering model is its own subject and there is more to say on it than fits here. Covering that properly in a future Hardening Brief issue.

Every password read should be logged. This is not optional for compliance, and you will want it after any incident:

AuditedPrincipals should match the reader group for that tier. If you did not set up per-tier reader groups in Step 3, you will end up auditing Domain Admins here, which both leaks too much signal and exposes that your LAPS reads are not tier-separated. Events land in the DC Security log as 4662.

Open GPMC, create a GPO, link it to the OU with your managed computers. Then:

Four settings are the minimum viable config.

Active Directory for domain-joined. Azure Active Directory for Entra-joined. Hybrid can use either. A device backs up to one directory, not both.

- Complexity: large + small + numbers + specials

- Length: 20 minimum, more if compliance requires it

- Age (days): 30

Leave blank or unconfigured to manage the built-in RID 500 account. LAPS targets by SID, not name, so renaming the local admin does not break this. Only set a custom name if you deliberately created a separate local admin account for LAPS to manage.

Reset password and logoff, 24h grace. After a helpdesk session that used the password, the password rotates and the local session ends. That closes the window where a retrieved password could be reused.

Force a GPO refresh on a test machine with gpupdate /force. Wait 60 seconds. First rotation follows.

PowerShell (scriptable, audited):

GUI: right-click the computer object in ADUC -> Properties -> LAPS tab. Current password, expiration, history (if enabled) all sit there. Both methods trigger the audit event from Step 4. Use the audit trail.

Deploying LAPS is one line item. The full Active Directory hardening checklist covers 40+ more.

Windows LAPS writes operational events to its own channel:

Event IDs to watch:

- 10003: password updated in the directory

- 10017: policy processing started

- 10022: password read by principal → the tripwire for unauthorized access

- 10026: rotation failed → investigate the same day

Forward 10022 and 10026 from every DC to your WEC. Those are your two real alerts you need to watch for.

If the deployment causes problems:

1. Unlink or disable the LAPS GPO

2. gpupdate /force on affected machines

3. Existing passwords remain valid until rotation or manual clear so no lockouts

4. If you need to force a specific known password, use Reset-LapsPassword

The schema extension from Step 2 stays but does nothing without the GPO. Leave it. A dormant schema attribute is harmless.

If you are on the old MSI, do not run both products on the same machines. Windows LAPS includes a Legacy Emulation Mode that reads and writes the legacy attributes, so you can migrate in phases:

1. Enable Windows LAPS in Legacy Emulation Mode via GPO

2. Confirm legacy attributes are being populated by Windows LAPS

3. Uninstall the legacy Microsoft LAPS MSI from managed machines

4. Switch the GPO to use the new Windows LAPS attributes

5. Remove legacy LAPS attribute reads from your tooling

This is the supported path. Microsoft will keep supporting legacy LAPS until the last OS version that shipped with it reaches end of life, but it gets no new features, and it is blocked from installation on Windows 11 23H2 and later.

Schema extension failures.

If Update-LapsADSchema fails, it is almost always because one DC is behind on patches. Run Windows Update on every DC before you extend. One stale DC causes replication inconsistencies that kill the cmdlet.

GPO scoping mistakes.

If the LAPS GPO is linked above an OU that mixes managed computers with kiosks that rely on a shared local account, the kiosks get rotated passwords too, and your kiosk workflows break on Monday. Scope carefully at the OU level.

Entra vs AD confusion.

An Entra-joined-only device cannot back up to Active Directory. If you set the backup directory to AD on one of those devices, LAPS silently fails. Event ID 10026 is how you find out. Check your Entra devices separately.

Post-authentication actions too aggressive.

A zero-hour grace period kicks admins out of live sessions the moment they authenticate. Keep the 24h default unless your threat model actively requires tighter cleanup.

Forgotten renamed admin accounts.

If you renamed the built-in Administrator via a separate GPO, Windows LAPS still manages it correctly. The account is identified by RID 500, not by name. You only need to specify a name in the LAPS GPO if you want LAPS to manage a different, custom local admin account.

Windows LAPS is one of the cheapest, highest-impact hardening actions left in a Windows environment. Twenty to forty minutes to deploy on a typical domain. No licensing. No agents. No reboots on clients. Every environment running Active Directory without LAPS is accepting a known lateral-movement path for no real reason.

The six steps: verify module, extend schema, grant self permissions, enable auditing, configure GPO, verify retrieval are the minimum viable config. For production, layer in password history, encrypted-only storage, event forwarding of the Operational channel, and audit review of who reads what.

If you are still running legacy Microsoft LAPS: it is a dead product. Start the migration. Windows LAPS has emulation mode for a reason.

Internal links to add once published:

- Issue #3: NTLMv1 and why it’s still showing up in your enviroment

- Issue #4: RC4 Kerberos deprecation

- Issue #5: gMSA and Kerberoasting defense

External references:

- Microsoft Learn: Windows LAPS overview

- Microsoft Learn: Update-LapsADSchema cmdlet reference