Local administrator password management with Windows LAPS

Every Windows machine has a local administrator account. If that account has the same password everywhere — which is the default outcome of building machines from an image — then one compromised machine hands the attacker local administrator on all of them.

This is a lateral movement path that requires no cleverness at all, and it remains extremely common. Windows LAPS solves it by giving each machine a unique, rotating password stored in a directory, readable only by the people you authorise.

Requirements

Windows LAPS is built into current Windows. It is not the separate download that the legacy product required — it arrived in Windows as a built-in feature, and it is managed through its own PowerShell module and policy settings. The legacy Microsoft LAPS and Windows LAPS are different implementations with different attributes, and both can be present in an estate that adopted the old one.

Choose a backend. Windows LAPS can store passwords in Windows Server Active Directory or in Microsoft Entra ID. Domain-joined machines use Active Directory; Entra-joined machines use Entra ID. A mixed estate uses both, and the management experience differs.

For the Active Directory backend, a schema extension. This is the step that needs planning, because a schema extension is a forest-wide, irreversible change.

Decide who may read passwords. This is the most important design decision and it is frequently made by accident. Anyone who can read the LAPS password for a machine effectively has local administrator on it.

The Active Directory deployment, in four steps

1. Extend the schema

# Requires Schema Admins. Forest-wide and irreversible.
Update-LapsADSchema

This adds the Windows LAPS attributes to the forest. Schema extensions cannot be undone — attributes can be deactivated but not removed — so this belongs in a change window with current backup evidence, following the same caution as any Tier 0 change.

2. Grant computers permission to write their own password

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=contoso,DC=com'

This allows computers in that organisational unit to update their own LAPS password. Without it, the client has nowhere to write and LAPS silently does nothing. Run it for every organisational unit containing machines in scope.

3. Grant read permission, narrowly

# Allow a specific group to read passwords for machines in an OU.
Set-LapsADReadPasswordPermission `
    -Identity 'OU=Workstations,DC=contoso,DC=com' `
    -AllowedPrincipals 'CONTOSO\Workstation-Support'

This is the decision that determines your actual security position. Grant it to a scoped support group for workstations, and to a separate, smaller group for servers. Do not grant a single group read access across the whole estate because it is simpler.

Be aware that Domain Admins and equivalent can read these values regardless, which is expected — but it also means the boundary you are creating is between support staff and the estate, not between administrators and anything.

Afterwards, audit who actually has the rights:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=contoso,DC=com'

Run this after deployment and periodically. Inherited permissions from higher in the tree frequently grant more than the person who ran step 3 intended, and this cmdlet is how you find that out.

4. Configure the policy

Deploy the Windows LAPS policy settings through Group Policy or Intune, specifying the backend, the password complexity and length, the rotation age, and the account to manage.

Two settings deserve thought:

• Which account. LAPS can manage the built-in administrator account or a named account it creates. A managed named account is generally the better choice, because the built-in administrator is well known and frequently disabled by policy.
• Post-authentication actions. LAPS can reset the password automatically a set time after the account is used. This is a strong control: it means a password that was read for a support call stops being valid shortly afterwards, rather than remaining until the next scheduled rotation.

Enable password encryption where your domain functional level supports it, so the stored value is encrypted and readable only by the authorised principals rather than sitting in clear text in the directory.

Operations: retrieving a password

Get-LapsADPassword -Identity 'WS-SAMPLE-01' -AsPlainText

The cmdlet handles decryption automatically where the password is stored encrypted. Password history is available where configured, which matters for restoring a machine from a backup taken before a rotation — without history, a restored machine’s current directory password does not match what is on the disk.

To force a rotation, for instance after a support call or a suspected exposure:

Reset-LapsPassword

Detection

Password reads are the signal worth capturing. A read is a person taking local administrator on a machine, and in a healthy estate it is infrequent and attributable.

• Audit read access to the LAPS attributes, and review it. A support engineer reading five passwords a week is normal; an account reading four hundred in an hour is an incident.
• Alert on changes to the read permissions, and on changes to the LAPS policy itself.
• Alert on schema and organisational unit permission changes in this area.

Directory object auditing needs to be configured to produce these events; it is not on by default at the granularity you want.

Validation

• Confirm a client has written a password: check the attribute is populated for a pilot machine, and note the expiry.
• Confirm an authorised support account can read it and use it to sign in locally.
• Confirm an unauthorised account cannot read it. This is the test that validates the permission model, and it is the one people skip.
• Confirm rotation happens on schedule, by checking the expiry advances.
• Confirm the post-authentication action fires if you configured one.
• Run Find-LapsADExtendedRights and confirm the actual rights match your intent.

Operations and estate coverage

Coverage is the real measure. Report on machines in scope that have no LAPS password recorded, and treat that list as the backlog. A LAPS deployment covering eighty per cent of the estate leaves the remaining twenty per cent as the lateral movement path, and an attacker only needs one.

Include servers, not just workstations — with a separate, smaller read group.

Handle the legacy product deliberately. If legacy Microsoft LAPS is present, plan the transition rather than running both against the same machines, and confirm which attributes each is using.

Do not exclude machines because they are awkward. The machine nobody manages is the one the attacker will find.

Rollback

Policy can be removed, which stops rotation and leaves the last set password in place on each machine — so removing the policy does not restore a shared password, it freezes a set of unique ones you can still read from the directory. That is a safe state, provided you do not also remove the read permissions.

The schema extension cannot be rolled back. That asymmetry is the one genuinely irreversible part of this deployment, and it is why step 1 belongs in a planned change with backup evidence rather than in an afternoon.

Verification and limits

The Windows LAPS PowerShell cmdlets and their purposes — Update-LapsADSchema, Set-LapsADComputerSelfPermission, Set-LapsADReadPasswordPermission, Get-LapsADPassword, Find-LapsADExtendedRights and Reset-LapsPassword — the Active Directory and Microsoft Entra ID backends, password encryption and post-authentication actions were checked against current Microsoft documentation on 20 September 2026.

Nothing here was deployed for this article. Update-LapsADSchema makes an irreversible forest-wide change and requires Schema Admins — treat it as a Tier 0 change with a maintenance window and current backups. Permission cmdlets alter directory access control; run Find-LapsADExtendedRights afterwards to confirm the result matches your intent. Availability and feature support depend on the Windows build and backend, so confirm both for your estate.

References

• Windows LAPS overview
• Get started with Windows LAPS and Windows Server Active Directory
• Windows LAPS PowerShell cmdlets overview
• Windows LAPS schema and rights extensions