Deploy Windows LAPS: unique local admin passwords

If every workstation shares the same local Administrator password, one compromised laptop is a compromised fleet. An attacker who dumps the local SAM or grabs the NTLM hash can authenticate to every other machine with that hash, no cracking required. This is still one of the most common paths from a phishing foothold to a domain-wide incident.

Windows LAPS (Local Administrator Password Solution) fixes this by giving each device its own random local administrator password, rotating it on a schedule and storing it in Active Directory or Microsoft Entra ID where only authorised groups can read it. Since the April 2023 cumulative updates, it is built into Windows 10, Windows 11 and Windows Server 2019 and later. Nothing to install on clients.

What changes compared with legacy LAPS

The original "Microsoft LAPS" was a separate MSI with a client-side extension and its own ms-Mcs-AdmPwd attribute. Windows LAPS is a native OS feature with a different set of attributes and several upgrades:

The two can coexist during a migration but must not manage the same account on the same machine. Plan to move each OU to Windows LAPS and then remove the legacy client.

Prerequisites

• Clients and servers on a supported build with a cumulative update from April 2023 or later.
• For Active Directory backup: permission to extend the schema (Schema Admins) once per forest.
• For encrypted passwords in AD: domain functional level Windows Server 2016 or higher.
• A security group for the people allowed to read passwords, for example LAPS-Workstation-Readers. Do not use Domain Admins for this: helpdesk should be able to recover a workstation password without holding Tier 0 rights.

Step 1: extend the schema and set permissions

Run the following from a machine with the LAPS PowerShell module (any supported Windows build) as a Schema Admin:

Import-Module LAPS
Update-LapsADSchema

Next, allow computers to write their own password to their computer object, per OU:

Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=example"
Set-LapsADComputerSelfPermission -Identity "OU=Tier1-Servers,DC=corp,DC=example"

Then grant read access to the right group, again per OU, so workstation readers never see server passwords:

Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example" `
  -AllowedPrincipals "CORP\LAPS-Workstation-Readers"
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example" `
  -AllowedPrincipals "CORP\LAPS-Workstation-Readers"

Finally, audit who else can already read confidential attributes on those OUs. "All extended rights" granted years ago to a service account or a helpdesk group quietly includes LAPS read access:

Find-LapsADExtendedRights -Identity "OU=Workstations,DC=corp,DC=example"

Anything in that output that is not a LAPS group, SYSTEM or Domain Admins deserves a ticket.

Step 2: configure the policy

The Group Policy settings live under Computer Configuration > Policies > Administrative Templates > System > LAPS. On Intune-managed devices the same settings are in Endpoint security > Account protection > Local admin password solution.

On domain controllers, the same policy can back up the DSRM (Directory Services Restore Mode) password. Apply that from a separate GPO linked to the Domain Controllers OU with its own reader group, since DSRM access is a Tier 0 secret.

Recent releases (Windows 11 24H2 and Windows Server 2025) add automatic account management, where LAPS creates and manages a local account for you, and passphrase-style passwords. If your fleet is mixed, stick to the classic settings above and add the new options in a separate GPO filtered to newer builds.

Step 3: force processing and verify

On a pilot machine, trigger a policy cycle and ask LAPS to process immediately:

gpupdate /target:computer
Invoke-LapsPolicyProcessing

Then read the event log. LAPS writes to Applications and Services Logs > Microsoft > Windows > LAPS > Operational. A successful cycle ends with an event stating the password was updated and backed up. Failures there are explicit: missing permissions on the OU, wrong account name, or a DC that does not yet know the schema.

From an admin workstation, as a member of the reader group:

Get-LapsADPassword -Identity PC-0142 -AsPlainText

The output shows the account, the password, when it was set and when it expires. For Entra ID-backed devices, use Get-LapsAADPassword from the Microsoft Graph PowerShell setup, or the device page in the Entra or Intune admin center.

To rotate on demand, for example after a technician used the password:

Reset-LapsPassword            # run locally on the device
Set-LapsADPasswordExpirationTime -Identity PC-0142   # or expire it from AD

Step 4: make local admin accounts useless over the network

LAPS makes each password unique. You should also make sure local administrator accounts cannot be used for remote logon at all, which removes an entire class of lateral movement even if a password leaks:

• Deny access to this computer from the network and Deny log on through Remote Desktop Services: add Local account and member of Administrators group (well-known SID S-1-5-114). Found under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
• Keep UAC remote restrictions on: LocalAccountTokenFilterPolicy must be absent or 0 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. The Microsoft security baseline enforces this through the "Apply UAC restrictions to local accounts on network logons" setting.

With both in place, the LAPS password is for console and break-glass use only, which is exactly what a local administrator password should be.

Common problems

Event says the account was not found. The managed account name in policy does not exist on the device. Either create it through your build process or leave the setting empty to manage the built-in Administrator.

Password never appears in AD. The computer cannot write to its object. Re-run Set-LapsADComputerSelfPermission on the correct OU and check that the computer object is actually in that OU (and not in the default Computers container, where GPOs linked to OUs do not apply).

Helpdesk sees "access denied" with encryption on. Read permission on the attribute is not enough; the user must be in the group configured as an authorized decryptor.

Passwords land in the old ms-Mcs-AdmPwd attribute. When only the legacy LAPS policy applies and the legacy client is not installed, Windows LAPS runs in legacy emulation mode and honours that old policy. Apply a Windows LAPS policy to the OU (it takes precedence) and retire the legacy GPO when you switch. If the legacy client is still installed and managing the same account, Windows LAPS steps aside to avoid a conflict, so uninstall it.

Checklist

• Schema extended, computer self-permission set per OU
• Separate reader groups for workstations, servers and DSRM
• Find-LapsADExtendedRights output reviewed and cleaned
• Policy: length 20+, complexity 4, age 30 days, encryption on, history enabled
• Post-authentication reset enabled
• Local accounts denied network and RDP logon via S-1-5-114
• Legacy LAPS client removed after migration
• Alert on LAPS Operational errors from your log pipeline

LAPS is one of the few controls on this site that costs almost nothing, breaks almost nothing and removes a technique attackers use in nearly every Windows intrusion. It is the right first step on the hardening map, followed by admin tiering and Protected Users.