Windows LAPS: migrating from legacy LAPS and locking down who can read passwords
A single local administrator password shared across the fleet remains one of the most effective lateral movement accelerators for an attacker. Windows LAPS, now built into the operating system, fixes that and adds features the old tool never had. It still needs a clean deployment and tight control over who can read the passwords.
From Microsoft LAPS to Windows LAPS
Legacy Microsoft LAPS relied on a client-side extension installed from an MSI and on the ms-Mcs-AdmPwd attribute, stored in clear text and protected only by ACLs. Windows LAPS has been built into Windows 10, Windows 11 and Windows Server 2019 and 2022 since the April 2023 updates, and ships natively in Windows Server 2025. It uses new attributes (msLAPS-Password, msLAPS-EncryptedPassword and others) and is managed through Group Policy or Intune. Microsoft considers legacy LAPS deprecated; an emulation mode helps with a gradual transition, but full migration should remain the goal.
Active Directory or Entra ID?
Each device backs up its password to one directory only. Domain-joined machines store it in Active Directory. Entra-joined or hybrid-joined devices can store it in Entra ID, provided the feature is enabled in device settings. Passwords are then read through the portal or Microsoft Graph, with dedicated permissions. In a hybrid estate, pick a reference directory for each device population and document it.
Encryption and read permissions
In AD, Windows LAPS can encrypt the password as long as the domain functional level is at least Windows Server 2016. The ADPasswordEncryptionPrincipal setting defines the group allowed to decrypt it (Domain Admins by default). Encryption also enables password history. Above all, it adds a second barrier: an account that can read the attribute but is not in the authorised group cannot use the value.
Update-LapsADSchema Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=contoso,DC=local" Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=contoso,DC=local" -AllowedPrincipals "CONTOSO\LAPS-Readers-Workstations" Find-LapsADExtendedRights -Identity "OU=Workstations,DC=contoso,DC=local"
The last command matters most during an audit: it reveals accounts and groups holding extended rights on the OU, often inherited from old delegations.
Backing up the DSRM account on domain controllers
A major addition: Windows LAPS can manage the Directory Services Restore Mode (DSRM) password on domain controllers. That password, often set at promotion time and never changed, grants powerful local access to the DC. DSRM backup requires encryption to be enabled. It is a high-value measure for limited effort.
Post-authentication actions
After the managed password has been used, Windows LAPS can, once a configurable grace period has elapsed, reset the password and optionally log off the session or restart the machine. A password looked up by a technician therefore does not stay valid forever.
Delegate precisely. Do not let workstation support read server passwords. Create separate reader groups per tier (workstations, servers, domain controllers) and align them with your tiering model.
What an audit checks
- the share of machines covered by an active and recently rotated LAPS policy;
- any coexistence with legacy LAPS and leftover
ms-Mcs-AdmPwdattributes; - holders of extended rights on OUs that contain computers;
- whether encryption and DSRM backup are enabled on domain controllers.