LAPS - Local Administrator Password Solution

What is LAPS?

LAPS (Local Administrator Password Solution) is a Windows feature that manages the password of a local admin account. Every machine gets its own random password. LAPS rotates it automatically and stores it centrally, where only authorized accounts can read it.

By default this is the built-in Administrator account. LAPS recognizes it by the fixed RID 500 rather than by name, so it finds a renamed account too. With AdministratorAccountName you can point it at a custom account. The password rotates every 30 days by default. LAPS also replaces it after the account has been used to log in, 24 hours after that use by default.

Since the Windows update of 11 April 2023, Windows LAPS is built into Windows 10, Windows 11 and Windows Server 2019 and newer. That version replaces the old, separate Microsoft LAPS from 2016, which you still had to install yourself as a Group Policy extension and which could only store in on-prem AD. The old LAPS has been deprecated since Windows 11 23H2 and is blocked on new Windows versions, so for new deployments Windows LAPS is the standard.

Which problem does LAPS solve?

Many networks roll out workstations from the same image. That image contains a local admin account, and without any further measure every machine therefore shares the same local admin password. Someone who lands on one workstation and grabs the local admin hash can reuse that same hash via Pass-the-Hash on every other machine built from that image. That is how an attacker moves across the whole network.

LAPS breaks that chain by giving every machine its own random local admin password. The hash of one machine then works on no other, so lateral movement through a shared local account falls away. Microsoft names protection against Pass-the-Hash and lateral movement explicitly as a goal of LAPS.

Where does LAPS store the password?

Windows LAPS stores the password in exactly one directory, and the scenario determines which. A domain-joined device stores in on-prem AD, on the computer object. A device joined only to Entra ID stores in Entra ID, on the device object. With a hybrid join you choose AD or Entra ID yourself. A device that is not joined to a domain cannot store in on-prem AD, so there Entra ID is the only option. It is never both at once. For storage in Entra ID you first have to enable the feature at the tenant level in the Entra admin center (Identity > Devices > Device settings), otherwise Entra ID refuses new LAPS passwords.

Intune is not a storage location here, but the management and retrieval channel. You roll out the LAPS policy through Intune and can view or rotate the password from Intune, but the storage stays AD or Entra ID.

Setting up LAPS properly

The password is 14 characters by default. You can raise that to 64 with PasswordLength, and it is worth doing. Nobody types this password by hand, so a longer one costs you nothing.

Pay attention to how the password is protected at the storage location too. In Entra ID it is encrypted by default. In on-prem AD it is not automatic. Encryption in AD requires functional level 2016 or higher. Only then does it sit in msLAPS-EncryptedPassword, which only the designated principal (Domain Admins by default) can decrypt. Below that, it lies in plaintext in msLAPS-Password, protected only by the ACL. So turn on encryption as soon as your functional level allows it.

For on-prem AD you extend the schema once per forest, and you grant the device itself write rights on its own password. After that, an administrator retrieves the password with a single PowerShell line.

# Once per forest: extend the schema for Windows LAPS
Update-LapsADSchema

# Retrieve a password from on-prem AD (limited by the ACL)
Get-LapsADPassword -Identity WS01 -AsPlainText

Restrict and audit who may read the password. In AD you do that with ACLs on the confidential LAPS attributes, preferably only Domain Admins. In Entra ID it goes through RBAC roles, where by default only Global Administrator, Cloud Device Administrator and Intune Administrator read the plaintext. Check regularly that nobody outside those groups can reach it.

LAPS and attackers

LAPS protects only the local admin password, not domain accounts. Domain attacks such as Pass-the-Hash with a domain account, Kerberoasting or DCSync fall entirely outside the scope of LAPS. It removes the problem of the shared local password, nothing more.

The LAPS password is also only as safe as the read rights on it. Anyone with read rights on the LAPS attribute reads the passwords in plaintext, certainly when encryption is off. In a pentest this comes up regularly. An overly broad ACL or an over-delegated group lets a low-privileged account read the local admin passwords over LDAP, for example with the LAPS module of NetExec. BloodHound shows such a path as a ReadLAPSPassword edge. Overly broad read rights are the finding themselves.

So LAPS does not solve everything on its own. Combine it with a tiering model that keeps admin accounts away from ordinary workstations, and with monitoring that notices passwords being read.