Deploy Windows LAPS to Eliminate Shared Local Administrator Passwords

In most organizations, every workstation was imaged with the same local administrator password — and that password is five years old, known to every current and former IT employee, and identical on hundreds of machines. This is the single cheapest lateral-movement path that exists: an attacker who recovers the local admin hash from one machine can authenticate to every other machine that shares it, no Domain Admin required. LAPS ends this pattern by giving every computer a unique, random, automatically rotated local administrator password, stored centrally and readable only by authorized staff.

Windows LAPS vs legacy LAPS

• Windows LAPS is built into the OS since the April 2023 updates for Windows 10/11 and Server 2019+ — no MSI to deploy. It supports storing passwords in Active Directory or Entra ID, adds password encryption at rest in AD, password history, and managed rotation after use.
• Legacy Microsoft LAPS (the separate MSI) is deprecated. If it is currently deployed, plan the migration: Windows LAPS uses different policy settings and attributes, and both should not manage the same account simultaneously during transition — use the legacy emulation mode only as a bridge.

Deployment — Active Directory scenario

• Update the schema once per forest from an elevated PowerShell session with Schema Admin rights: Update-LapsADSchema. This adds the new attributes (including msLAPS-EncryptedPassword).
• Grant computers the right to update their own password attributes on each target OU: Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local".
• Configure the policy via GPO under Computer Configuration > Administrative Templates > System > LAPS: set the backup directory to Active Directory, password length 16+ with full complexity, rotation age 30 days or less, and enable password encryption (requires the domain functional level and DC support — strongly recommended, since unencrypted LAPS attributes are readable by anyone granted the extended right, and misconfigured ACLs are a classic pentest finding).
• Enable post-authentication actions: after the password is used, automatically rotate it and optionally log off or reboot the machine within a set grace period. This turns every retrieved password into a single-use credential.
• If the managed account is a renamed or custom local admin, specify its name in policy — LAPS manages the built-in Administrator by default, and machines where it is disabled need the correct target account.

Deployment — Entra ID / Intune scenario

• Enable LAPS at the tenant level under Entra ID device settings, then create an Account Protection policy in Intune (Endpoint security > Account protection > Local admin password solution) with equivalent settings — backup target Entra ID, rotation, complexity, post-authentication actions.
• Passwords are retrieved from the Entra portal or Graph, gated by the deviceLocalCredentials.Read.All permission and RBAC roles — grant retrieval to the helpdesk role, not to all admins.

Retrieval, delegation, and auditing

• Delegate read access deliberately: Set-LapsADReadPasswordPermission for the helpdesk/desktop-support groups per OU, and Set-LapsADResetPasswordPermission for those allowed to force rotation. Audit who currently holds the right with Find-LapsADExtendedRights — the historical LAPS breach pattern is over-broad read permissions, not the mechanism itself.
• Retrieve passwords with Get-LapsADPassword -Identity PC-1234 -AsPlainText, through ADUC's LAPS tab, or via the Entra portal. Retrievals of encrypted passwords generate audit events — forward Event ID 4662 on the attributes (and the client-side LAPS operational log) to your SIEM so every password read is attributable.
• Confirm rollout health by querying password ages across the fleet: machines whose LAPS password has never been set or has not rotated on schedule are the gaps to chase.

What LAPS does and does not solve

• It removes password reuse across machines, and post-authentication rotation removes credential lingering after support sessions. Combined with denying local accounts network logon (the Deny access to this computer from the network right for local accounts, or the built-in local account SID restrictions), pass-the-hash with local credentials is effectively dead.
• It does not reduce the need to minimize local admin membership overall — LAPS secures the break-glass account; day-to-day support should still run through named accounts and just-in-time elevation where available.

For a control that costs nothing, deploys in days, and closes one of the most exploited paths in Windows environments, LAPS has no real competition — if local admin passwords are still shared in your fleet, this item outranks nearly everything else on the list.