LAPS on Windows: Killing the Shared Local Admin Password Problem

One reused local Administrator password turns a single compromised laptop into domain-wide lateral movement. Here's how LAPS fixes it, how to verify it on the machine in front of you, and how to prove coverage across a fleet.

Almost every Windows environment has a built-in local Administrator account on every machine. In too many of them, that account shares one password — baked into the golden image, typed into a hundred setups, and never changed since. It is the single most reliable lateral-movement primitive an attacker can hope for, and it is entirely self-inflicted.

The Local Administrator Password Solution (LAPS) exists to end this. It is not a new product to buy: modern LAPS ships in-box with current Windows and can also back onto Active Directory. This post covers why the shared password is so dangerous, exactly how LAPS closes the hole, and how to verify it — because an unverified control is just a hopeful assumption.

Why One Shared Password Is a Domain-Wide Failure

Picture a fleet where DESKTOP-01 through DESKTOP-500 all share the same local Administrator hash. An attacker phishes one user, runs as the local admin, and dumps the SAM:

# On a single compromised host, an attacker only needs the local hash:
reg save HKLM\SAM sam.hive
reg save HKLM\SYSTEM system.hive
# Offline: extract the local Administrator NT hash from the SAM.

That NT hash is all they need. Because the credential is identical everywhere, they never have to crack it — they pass the hash straight to the next 499 machines:

# Same local admin hash unlocks every other box (pass-the-hash):
# authenticate to \\DESKTOP-02 ... DESKTOP-500 with the SAME NT hash
# no password ever cracked, no lockout, no new prompt

This is why frameworks call it out explicitly. It maps to MITRE ATT&CK T1550.002 (Pass the Hash) and directly violates the CIS Windows Benchmark control that local administrator credentials must be unique per machine. One reused password converts a contained incident into a full-fleet compromise in minutes.

What LAPS Actually Does

LAPS gives every machine its own randomized local administrator password and rotates it on a schedule. The secret is stored centrally — in Active Directory, or in Microsoft Entra ID with Windows LAPS — and released only to authorized principals, with the retrieval audited.

Unique per host — every machine's local admin password is different, so a dumped hash unlocks exactly one box, not the fleet.
Automatic rotation — passwords expire and roll (commonly every 30 days), and roll again immediately after a checkout, so a leaked value has a short useful life.
Centralized, access-controlled storage — the password lives in the directory, readable only by the roles you grant; every read is logged for the audit trail.
Encrypted backups & history — Windows LAPS supports encrypting the stored password and keeping a rotation history so a recent-but-superseded value is still recoverable.

The result is that the local admin account stops being a shared master key and becomes a per-machine, short-lived, auditable break-glass credential.

Verify It on the Machine in Front of You

Deploying LAPS via GPO or Intune is only half the job. Group Policy silently fails, images get re-imaged without the policy, and a machine that "should" have LAPS often does not. Verify on the actual endpoint. On Windows LAPS you can force and inspect state directly:

# Windows LAPS: check effective policy + push a rotation now
Get-LapsAADPassword -DeviceIds (hostname)   # or Get-LapsADPassword for AD-backed
Invoke-LapsPolicyProcessing                  # apply/refresh the LAPS policy
Get-Command -Module LAPS                      # confirm the module is even present

The questions that matter per machine are blunt: Is the local Administrator password managed and rotating? When did it last change? Are there extra, unmanaged local admin accounts sitting beside the managed one? A machine can have LAPS on the built-in account and still expose a second, static svc-admin local account that never rotates — the attacker will happily take that instead.

This is squarely a single-machine hardening question, which is why WinSentinel audits it as part of a free, on-machine scan. The CLI is free and unlimited on every machine — run the full audit and it flags stale passwords, unmanaged local admins, and account sprawl right where you are:

# Free on every machine — full local audit, all modules, no limits:
dotnet tool install --global WinSentinel.Cli
winsentinel --audit

# Local admin accounts and password posture are part of the report,
# with a one-click fix for the findings it can safely remediate.

From One Machine to Proving Fleet Coverage

"We deployed LAPS" and "every machine actually has a rotating, unique local admin password" are different claims. Auditors and incident responders care about the second one. The gap is coverage: the three re-imaged laptops, the offline branch machine, the box that dropped out of the OU — each is a quiet exception that reopens the pass-the-hash path.

Answering that at scale is a fleet-orchestration problem, not a single-machine one. WinSentinel Pro rolls every node's local-admin posture into one view, so you can prove coverage and catch the exceptions:

Coverage rollups — what percentage of the fleet has a managed, recently-rotated local admin password, and which specific hosts do not.
Drift alerts — get notified when a machine that was compliant stops rotating, or when a new unmanaged local admin appears after a re-image.
Compliance evidence — export the per-node state mapped to CIS / SOC 2 controls, instead of screenshotting one directory attribute and hoping the rest match.

The single-machine audit tells you the box in front of you is safe. The fleet view tells you the other 499 are too — and names the ones that are not.

The Takeaway

A shared local Administrator password is not a minor hygiene issue; it is a pre-installed lateral-movement highway. LAPS is the fix, it ships with Windows, and the only thing standing between "configured" and "actually protected" is verification. Check the machine in front of you today, then close the coverage gap across everything else.

# Start here — one machine, full audit, free:
dotnet tool install --global WinSentinel.Cli
winsentinel --audit

# Ready to prove it across the fleet?
# winsentinel.ai/pricing