Windows LAPS: unique local administrator passwords for Windows Server, and who is allowed to read one

What it is

Windows LAPS (Local Administrator Password Solution) is described in Microsoft's documentation as "a Windows feature that automatically manages and backs up the password of a local administrator account" on a Windows Server or Windows client machine. It is documented for Windows Server 2025, and for Windows Server 2022 and 2019 from the April 11, 2023 update on; Windows Server 2016 is not supported. It is a separate implementation from the deprecated legacy Microsoft LAPS download.

The problem it solves: without it, many fleets share one local administrator password across every machine (set once at imaging time), so compromising it on one machine compromises all of them. LAPS instead gives each machine's local administrator account its own randomized password, rotated on a schedule, retrievable only by an explicitly authorized principal.

Why it matters

A shared local admin password turns a single leaked credential (from one machine's memory, a backup, or a misconfigured share) into fleet-wide lateral movement. Per-machine, rotated passwords with access-controlled retrieval limit a compromised credential to the one machine it came from, and the retrieval itself is logged.

How to apply

• Extend the Active Directory schema once per forest, from a Schema Admins session: Update-LapsADSchema, which "extends the Active Directory (AD) schema with the Windows Local Administrator Password Solution (LAPS) schema attributes."
• Allow the managed computers to write their own password: Set-LapsADComputerSelfPermission -Identity <OU>. Without this the client cannot store a password in AD.
• Configure the policy (backup directory, rotation interval, target local account, encryption) through Group Policy or Intune. A device backs up to either AD or Entra ID, never both; Entra-only joined devices can use only Entra ID.
• Delegate read access deliberately to a narrow group: Set-LapsADReadPasswordPermission -Identity <OU> -AllowedPrincipals <group>. Domain Admins already have read permission by default. With password encryption enabled (requires domain functional level 2016), the ADPasswordEncryptionPrincipal policy setting separately decides who can decrypt; its default is Domain Admins.
• Retrieve a password when authorized: Get-LapsADPassword -Identity <computername> -AsPlainText. The cmdlet "allows administrators to retrieve LAPS passwords and password history for an Active Directory computer or domain controller object," and decrypts encrypted-mode passwords automatically for a caller with the right permission.
• Audit who read which machine's password: Set-LapsADAuditing -Identity <OU> -AuditedPrincipals <group> adds the auditing entries to the OU, and the reads then appear as directory-service access events on the domain controllers once Directory Service Access auditing is enabled.

Pitfalls

• Assuming LAPS is active because the schema was extended; the client-side policy also has to target the machine before it starts rotating anything (Invoke-LapsPolicyProcessing on the client applies it immediately, and the Microsoft-Windows-LAPS/Operational event log shows the result).
• Granting broad read permission to the LAPS password attributes "to be safe," which recreates the shared-secret risk LAPS exists to remove.
• Forgetting that a machine removed from the domain (or never successfully applying policy) never gets a LAPS-managed password and may still be running the imaging-time default.