The Twenty-Year Local Admin Password Crisis: From GPP cpassword to Windows LAPS

1. One Password, Fifty Thousand Laptops#

In May 2012, a domain user with twelve lines of PowerShell could read the local Administrator password for every machine in the organisation. The tool was Get-GPPPassword.ps1 ^[1]. The "encryption" was AES-256-CBC with a 32-byte key Microsoft had published in its own protocol specification ^[2] -- not leaked, published, as a feature, so that third-party Group Policy implementations could read the format. Eleven years later, on April 11, 2023, Microsoft finally shipped the in-box fix ^[3].

This is an article about those eleven years.

The pattern was old before 2012. Through the 2000s, the only practical way to provision the local Administrator account on a Windows fleet was to bake one shared password into the reference image and ship the image to every endpoint. Helpdesk knew the password. Pentesters guessed at it. And once Benjamin Delpy's Mimikatz had pulled the hash from a single phished workstation in 2011, the rest of the org fell to a single psexec spray. Microsoft documented the threat model precisely in its December 2012 Mitigating Pass-the-Hash whitepaper ^[4], which named the shared local Administrator credential as the architectural enabler of the entire intrusion class ^[5].

Microsoft also had a fix. It had shipped one in 2008 with Group Policy Preferences (GPP), the feature that could push a per-machine local-admin password from a Group Policy Object to every endpoint. GPP put the password in an XML file in SYSVOL. SYSVOL was world-readable to every authenticated user in the domain. Microsoft encrypted the password with AES-256-CBC -- and then published the key. The result, after a four-author weaponisation chain in mid-2012 [@sogeti-2012-wayback; @obscuresec-gpp-2012; @rewtdance-gpp-2012; @metasploit-gpp], was that GPP made the original problem worse: instead of one shared password recoverable by physical access to a help-desk laptop, it was now one shared password recoverable by any authenticated domain user with a copy of Get-GPPPassword.ps1. Microsoft "patched" it on May 13, 2014 with MS14-025 ^[6], which disabled new authoring but deleted nothing already deployed. Twelve years later, PingCastle still finds the artefacts in production AD ^[7].

The first real fix was Generation 2: the legacy Microsoft LAPS, shipped May 1, 2015 as a separate MSI ^[8]. It stored a per-machine random password in the ms-Mcs-AdmPwd attribute on the computer object, marked CONFIDENTIAL ^[9]. The directory-side ACL was tighter than SYSVOL, but the deployment surface (install on every endpoint, extend the schema, delegate the OU) capped its real coverage; the password sat in plaintext in AD, one DCSync from "plaintext everywhere"; and a delegation pattern that helpdesks regularly issued -- "All Extended Rights" on the computer OU -- silently included read access to the CONFIDENTIAL attribute ^[9]. SpecterOps modelled that bypass as the ReadLAPSPassword BloodHound edge on August 7, 2018 ^[10].

Generation 3 -- Windows LAPS, in-box, no MSI -- shipped on Patch Tuesday April 11, 2023 ^[3] across Windows 11 22H2 and 21H2, Windows 10 22H2, Windows Server 2022, Windows Server 2019, and Windows Server Annual Channel. Windows Server 2016 was explicitly excluded ^[11]. The new architecture wrapped the password with CNG DPAPI's group key-protector against a configurable principal, exposed Microsoft Entra ID as a peer backup directory ^[12], and added a post-authentication rotation primitive that closed the screenshotted-password OPSEC tail on the next managed-account logon ^[13].

Microsoft knew the right architecture for managing local Administrator passwords in December 2012, when its own Pass-the-Hash whitepaper named the shared-credential pattern as the architectural enabler of lateral movement. It took until April 11, 2023 to ship that architecture as a Windows default. Eleven years is a long time. The intervening generations each solved part of the previous problem and introduced a new one. The 2026 baseline is, for the first time, an OS-default solution rather than an out-of-band one -- and for the first time, the residual attack surface is the actual surface rather than an artefact of incomplete shipping.

gantt
dateFormat YYYY-MM-DD
axisFormat %Y
title Local-administrator password management on Windows, 1998-2026

section Generation 0 -- Imaged-build era
Shared local admin password baked into image          :gen0, 1998-01-01, 2008-02-26

section Generation 1 -- GPP cpassword
Group Policy Preferences ships in WS2008 RTM           :g1a, 2008-02-27, 2014-05-12
Linda Moore re-posts "Passwords in GPP (Updated)"     :milestone, 2009-04-22, 1d
Sogeti / obscuresec / rewtdance / Metasploit chain    :crit, 2012-04-01, 2012-07-31
MS PtH whitepaper v1 (architecture articulated)       :milestone, 2012-12-01, 1d
MS14-025 disables new authoring (no remediation)      :milestone, 2014-05-13, 1d

section Generation 2 -- Legacy MSI LAPS
Microsoft LAPS GA (KB3062591 MSI)                      :g2a, 2015-05-01, 2023-04-10
Metcalf publishes All-Extended-Rights bypass           :milestone, 2016-08-01, 1d
SpecterOps BloodHound 2.0 ships ReadLAPSPassword edge :milestone, 2018-08-07, 1d

section Generation 3 -- In-box Windows LAPS
Windows LAPS ships in-box (AD backup)                  :crit, 2023-04-11, 2026-12-31
Windows LAPS with Entra ID GA                          :milestone, 2023-10-23, 1d
Win 11 24H2 passphrases and Automatic Account Mgmt    :milestone, 2024-10-01, 1d
Win 11 25H2 Administrator Protection (orthogonal)     :milestone, 2025-11-19, 1d

The article that follows traces the architecture of each generation, the attacks each one solved and each one enabled, and what "standard local admin password management" looks like as a 2026 default. To see why this took twenty years, we have to start in 1998, before Active Directory.

2. Origins: Why Every Workstation Had the Same Local-Admin Password (1998-2008)#

Picture a system administrator in 2005. They are holding a CD-R labelled Win-Build-7.iso and a sticky note with a 12-character password. Those two artefacts are the entire local-Administrator-credential lifecycle for ten thousand desktops. The CD will be cloned to a USB drive, the USB drive will reseed Norton Ghost, and Ghost will paint the build onto every new workstation the company buys for the next eight months. Each painted machine will boot with the sticky-note password as its built-in local Administrator. Helpdesk knows the password because they typed it into the image. Five hundred field technicians know the password because they have to be able to recover unmanaged laptops off-network. The pentester who shows up in March will know the password by Tuesday lunch.

This was not a deviation. It was the architecture.

The mechanics were a function of how Windows was deployed at scale. Microsoft Sysprep /generalize strips a reference image's machine SID before duplication, but it leaves the SAM intact. Whatever local Administrator password sits in the reference image is the local Administrator password on every endpoint painted from that image. Imaging pipelines were built around this: Norton Ghost in the late 1990s, Microsoft Deployment Toolkit (MDT) and later System Center Configuration Manager Operating System Deployment in the 2000s, all assumed the same SAM. Sean Metcalf's December 2015 SYSVOL retrospective walks the era end-to-end and explains why every shop in the world ended up with a single password ^[14].

The operational reality kept the pattern alive. Help-desk needed one known credential to break-glass a laptop that had wandered off the corporate network for six months. Field technicians needed one known credential to swap a failed hard drive on a roof-top kiosk in Houston without phoning home. A known-to-the-org local-admin password was the only realistic fallback path, and the alternative -- a different password per machine, stored somewhere retrievable -- required a retrieval primitive Microsoft had not yet shipped.

The threat model that made the trade-off catastrophic did not get articulated by Microsoft itself until December 2012, in version 1 of the Pass-the-Hash whitepaper ^[4]. The chain was already common knowledge in offensive-security circles: phish a single user, run Benjamin Delpy's 2011-vintage Mimikatz to pull credentials from LSASS, capture the NT hash of the built-in Administrator account, replay that hash to every other host via psexec or wmiexec, and pivot up to the first server an enterprise admin has touched. MITRE catalogues the default-account abuse as T1078.001 ^[15] and the hash-replay step as T1550.002 ^[5]. The whitepaper's recommended controls included exactly the architecture Microsoft would eventually ship as LAPS: per-machine random local-admin passwords, rotated frequently, retrievable only by an authorised principal.

The third-party prehistory matters because it set the terms Microsoft would eventually use. PolicyMaker, the engineering parent of what became Group Policy Preferences, was a product of DesktopStandard Corporation that Microsoft acquired in October 2006 ^[14]. Thycotic was founded in 1996 by Jonathan Cogley and shipped its Secret Server vault from the mid-2000s ^[16]; Lieberman Software (later acquired by Bomgar in January 2018) had operated as Lieberman and Associates since 1978 ^[17]; Quest Software was founded in 1987 in Newport Beach, California and was a public company well before the mid-2000s LAPS prehistory began -- its August 14, 1999 NASDAQ IPO saw its shares surge to $47 in a single Wall Street session [@wikipedia-quest; @latimes-quest-ipo-1999]. None of those vendors solved the local-admin-on-every-Windows-machine problem from inside the OS, and Microsoft's own first-party tooling -- restricted groups, logon scripts, Group Policy Object security templates -- offered no rotation primitive at all. The gap was not a knowledge gap; it was a first-party-feature gap.

In February 2008, Microsoft shipped Windows Server 2008. With it came Group Policy Preferences -- and with GPP came a "Local Users and Groups" preference that could push a per-machine local-admin password from a domain GPO to every endpoint in scope. It was the first first-party rotation mechanism Microsoft had ever shipped. It made the problem dramatically worse.

3. Decoration Is Not Encryption: GPP cpassword (2008-2012)#

Microsoft Server 2008 reached release-to-manufacturing in February 2008. Group Policy Preferences shipped with it. The new "Local Users and Groups" preference -- alongside Scheduled Tasks, Services, Data Sources, Drive Maps, and Printers -- could push a password from a GPO down to every endpoint in scope. The password went into an XML file in SYSVOL, the domain's replicated policy share. SYSVOL was world-readable to every authenticated user in the domain. The password was AES-256-CBC encrypted in the XML, in a field called cpassword. The key was a 32-byte value published in [MS-GPPREF] section 2.2.1.1.4 ^[2], in Microsoft's own Open Specifications protocol corpus -- as a feature, so that third-party Group Policy implementations could interoperate.

Microsoft was not unaware. On April 22, 2009, the Group Policy Team blog re-posted (and updated) a piece by Linda Moore titled "Passwords in Group Policy Preferences (Updated)" ^[18]. The phrasing is unambiguous.

"the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it." -- Linda Moore, Group Policy Team blog, April 22, 2009 ^[18]

The post recommended a list of mitigations: prefer secure mechanisms, audit who can read the SYSVOL share, prefer not to use the field at all. None of those mitigations could rotate the key. None could revoke the static AES-256 key value published in [MS-GPPREF]. Microsoft was telling its customers, in 2009, three years and eight months before the public weaponisation, that the credential they were storing was decryptable by every user in the domain by design.

Three years later, the offensive-security community spent twelve weeks turning the publication into a default-on red-team primitive.

In April and May of 2012, Emilien Girault of Sogeti ESEC published a Python decryptor on the firm's research blog ^[19]. The site has since been retired and the canonical reference is the Wayback Machine capture. In mid-May 2012, Chris Campbell (@obscuresec) published Get-GPPPassword.ps1, a PowerShell port that fetched the relevant XML from SYSVOL, decoded the base64, and called .NET's AES primitives with the published key ^[1]. The script was folded into PowerSploit at Exfiltration/Get-GPPPassword.ps1, where its header still reads "Author: Chris Campbell (@obscuresec)" ^[20] and explicitly credits Emilien Girault for the underlying research. In June 2012, Ben Campbell (the rewtdance.blogspot.com blog handle), working with scriptmonkey (a named collaborator with his own blog at blog.owobble.co.uk), extended the attack to all six XML wire-format carriers that [MS-GPPREF] permits ^[21]. The rewtdance post body credits the collaboration verbatim: "Working with scriptmonkey (http://blog.owobble.co.uk/), who already had a DC configured, we verified this theory." On July 25, 2012, the Metasploit module post/windows/gather/credentials/gpp.rb landed ^[22] with five co-authors: Ben Campbell, Loic Jaquemet, scriptmonkey, theLightCosine, and mubix. A companion auxiliary scanner, auxiliary/scanner/smb/smb_enum_gpp.rb, was authored independently by Joshua D. Abraham of Praetorian ^[23].

The whole exercise was twelve lines of code. The interesting part was not the cryptography. The interesting part was that the operation was decryption-by-reference: with a published key, the AES envelope was not protecting a secret, it was carrying a secret in a format the protocol specification told everyone how to read.

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

import base64
# Pure-Python AES illustration (no third-party dependency).
# In a real script, use a library; this is for demonstration of how trivial the
# operation is once the key is public.

KEY_HEX = (
"4e9906e8fcb66cc9faf49310620ffee8"
"f496e806cc057990209b09a433b66c1b"
)

def restore_b64_padding(s):
return s + "=" * (-len(s) % 4)

def decrypt_cpassword_demo(cpassword_b64):
# Steps (no actual AES here; this is to show the public algorithm):
# 1. Restore base64 padding stripped by Microsoft.
# 2. Decode to ciphertext bytes.
# 3. AES-256-CBC decrypt with the published 32-byte KEY and a 16-byte zero IV.
# 4. Strip the PKCS#7 padding and UTF-16-LE decode the plaintext.
ciphertext = base64.b64decode(restore_b64_padding(cpassword_b64))
return f"would AES-256-CBC decrypt {len(ciphertext)} bytes with the public key"

print(decrypt_cpassword_demo("j1Uyj3Vx8TY9LtLZil2uAuZkFQA/4latT76ZwgdHdhw"))

sequenceDiagram
participant User as Authenticated user
participant DC as SYSVOL on a DC
participant Local as Local decryptor
participant Target as Any workstation
User->>DC: SMB read of Groups.xml in SYSVOL Preferences path
DC-->>User: XML body containing cpassword attribute
User->>Local: AES-256-CBC decrypt with the published 32-byte key
Local-->>User: plaintext local-Administrator password
User->>Target: SMB authenticate as Administrator (cleartext or pass the hash)
Target-->>User: SYSTEM-level command execution

By 2013, "GPP cpassword finding" was a standard early-engagement primitive on every internal pentest, captured in Sean Metcalf's December 2015 retrospective on the class: this is what happens when an "encryption" feature is shipped with a published key ^[14]. MITRE catalogues the class as T1552.006 under Unsecured Credentials: Group Policy Preferences ^[24]. Microsoft's first first-party rotation primitive had taken a problem -- one shared password, recoverable from the helpdesk -- and made it strictly worse: one shared password, recoverable from a SYSVOL read by any user in the forest.

Encryption with a published key is plaintext with extra steps. The cryptography is not broken; the threat model is. AES-256-CBC is a perfectly good block cipher. But the only secret in a symmetric encryption envelope is the key; once the key is public, "AES-encrypted" is a notation, not a protection. The cpassword field was not a vulnerability in the bug sense -- there was no defect to patch, because the disclosure was deliberate. The "fix," when it came, could change the editor UI but could not change the key.

On May 13, 2014, Microsoft shipped MS14-025 to close the hole. It did, and it did not.

4. The Patch With a Tail: MS14-025 (May 13, 2014)#

Microsoft Security Bulletin MS14-025 / KB2962486 shipped on Patch Tuesday, May 13, 2014 -- seven Patch Tuesdays after the Sogeti / obscuresec / rewtdance (Ben Campbell with scriptmonkey) / Metasploit weaponisation chain crossed the threshold from research toy to default-on red-team primitive [@ms14-025-bulletin; @ms14-025-kb]. The bulletin closed the hole. Half-closed it. The lesson the half is teaching took twelve years to land.

What MS14-025 did: it removed the password input field from the Group Policy editor user interface for five preference categories -- Local Users and Groups, Scheduled Tasks, Services, Data Sources, and Drive Maps ^[25]. The Remote Server Administration Tools (RSAT) update disabled the creation of new GPP items containing a cpassword field at all. The CVE assigned to the issue was CVE-2014-1812 ^[6]. The bulletin's own Executive Summary called the underlying class an Elevation of Privilege vulnerability and explained that "an attacker who successfully exploited the vulnerability could decrypt the password stored in the Group Policy preference" ^[6].

What MS14-025 did not do is more important than what it did.

It did not delete existing Groups.xml, Services.xml, ScheduledTasks.xml, DataSources.xml, or Drives.xml from any SYSVOL anywhere. It did not rotate the credentials those XML files contained. It could not revoke the 32-byte AES key published in [MS-GPPREF] 2.2.1.1.4, because the protocol-specification publication was permanent under Microsoft's Open Specifications Promise ^[2]. And the editor UI fix had an asymmetry with the wire format that practitioners had to discover on their own: the bulletin and KB enumerated five preference types, but [MS-GPPREF] permits a cpassword field in six XML carriers. The sixth is Printers\Printers.xml, which Microsoft's UI never exposed a password field for and which the bulletin therefore did not name -- but which Ben Campbell's June 2012 enumeration with scriptmonkey had already flagged as an exploitable carrier ^[21].

The bulletin's own Additional Action Required section made the cleanup story explicit.

"Customers with existing Group Policies that use Group Policy preferences to set passwords will need to take additional action to remove those policies." -- Microsoft Security Bulletin MS14-025, Additional Action Required ^[6]

The fix-and-no-cleanup pattern was not new in 2014. What was new was the time horizon the pattern would persist over. MS14-025 disabled new authoring in May 2014; in 2026, twelve years later, PingCastle's A-PwdGPO rule still finds residual Groups.xml files in production Active Directory ^[7]. MITRE catalogues the same primitive as T1552.006 ^[24]. There is no first-party Microsoft cmdlet to find or remediate the artefacts. Practitioners have built Get-GPPDeployedPasswords scripts; PingCastle ships the scan; Semperis Purple Knight ships a similar one. Microsoft does not.

A vulnerability mitigation without a remediation pass leaves a multi-decade tail. MS14-025 is the canonical example: the editor UI was hot-patched in May 2014, no SYSVOL artefacts were deleted, no credentials were rotated, the underlying AES key was not revocable, and a third-party scanner cohort (PingCastle, Purple Knight, BloodHound) had to fill the gap that Microsoft never closed. The architectural lesson recurs in section 6 (legacy-LAPS coexistence with Windows LAPS), in section 10 (the open-problems list still names un-cleaned SYSVOL cpassword artefacts as problem one), and in section 11 (audit step 1 is always "sweep SYSVOL first"). A patch that does not clean up after itself becomes a permanent feature of the threat model.

One year after the half-fix, Microsoft shipped the actual fix. It was deployable on every endpoint -- if you were willing to install an MSI on every endpoint, extend the schema, and accept that the password lived in plaintext in Active Directory.

5. The First Real Fix and Its Own Attack Class: Legacy Microsoft LAPS (May 1, 2015 to April 2023)#

On May 1, 2015, Microsoft Security Advisory 3062591 announced "Local Administrator Password Solution (LAPS) Now Available" ^[8]. The advisory page is now only available on the Wayback Machine; the modern Download Center entry for the legacy MSI carries a deprecation note dated to Windows 11 23H2 ^[26]. The deliverable was a 1.6 MB LAPS.x64.msi (and a smaller x86 sibling). It was not in the operating system. You had to install it on every endpoint. The architecture was simple, the deployment was painful, and the engineering core had not actually been written by Microsoft.

Inside the MSI was Jiri Formacek's AdmPwd. The provenance is on the project's GitHub README, verbatim: "This is source code for AdmPwd project that has been previously hosted on MSDN gallery -- project has been used as base for Microsoft branded LAPS solution." ^[27]. The often-omitted prehistory is that Microsoft Services had been quietly recommending AdmPwd to customers for years before the 2015 release; what Microsoft Security shipped was a packaging exercise on top of a working open-source primitive.

The architecture, attribute by attribute, looked like this. The legacy LAPS Group Policy Client-Side Extension lived in admpwd.dll. It ran on every Group Policy refresh -- the standard 90-minute interval with up to 30 minutes of randomised jitter on member computers. When the local password's age exceeded PasswordAgeDays (default 30 days, not one day), the CSE generated a new random password, set it on the local Administrator account via the Security Account Manager, and wrote the plaintext to the computer object's ms-Mcs-AdmPwd attribute in Active Directory ^[9]. A second attribute, ms-Mcs-AdmPwdExpirationTime, held a Windows FILETIME timestamp of when the next rotation was due.

The good architectural news: the password was no longer in SYSVOL, and the directory's access control could be tighter than the SYSVOL share's read-everywhere default. The bad architectural news arrived in three layers.

First, the deployment surface was the cap on the legacy generation's coverage. To make legacy LAPS work in a forest, an administrator had to (a) Update-AdmPwdADSchema once per forest to add the two attributes, (b) Set-AdmPwdComputerSelfPermission per OU so that the computer accounts could write their own attributes, (c) install LAPS.x64.msi on every endpoint, (d) install the ADMX template on every administrative workstation, and (e) configure a GPO with PasswordAgeDays, complexity, and length. Any step missed left a host out of scope. PingCastle's coverage rules continue to report on incomplete LAPS deployments precisely because the failure mode is silent: missing the MSI on a single OU produced no error, just a host with the same local-Administrator password it had been imaged with ^[7].

Second, the directory-side ACL had a delegation footgun. The CONFIDENTIAL bit gates ordinary reads; it does not gate the "All Extended Rights" delegation. Helpdesk OUs routinely delegate "All Extended Rights" so that helpdesk technicians can reset passwords on user accounts in their scope. The same "All Extended Rights" grant, applied to a computer OU, silently includes the CONTROL_ACCESS right -- which is exactly what reading ms-Mcs-AdmPwd requires. Sean Metcalf's August 2016 ADSecurity write-up documented the class in detail and noted that Microsoft shipped Find-AdmPwdExtendedRights as an audit primitive but did not block the delegation pattern at the schema layer ^[9]. The fix was operational: audit every "All Extended Rights" delegation on every computer OU, then remove the ones that did not need to read LAPS passwords. The fix was not architectural.

Third, SpecterOps formalised the class as a primary BloodHound primitive. On August 7, 2018, BloodHound 2.0 shipped with the ReadLAPSPassword edge as one of its four named new attack primitives -- alongside CanRDP, ExecuteDCOM, and AllowedToDelegate ^[10]. The current edge documentation covers both the legacy ms-Mcs-AdmPwd and the modern msLAPS-* attribute paths ^[28]. The edge runs from a user or a group to a computer and indicates that LAPS is installed and the principal can read the password for the local Administrator account from LDAP. Inside a typical enterprise graph, the edge is dense.

"The ReadLAPSPassword edge runs from a user or a group to a computer and indicates that LAPS is likely installed on the target computer and the principal can read the password for the local administrator account from LDAP." -- SpecterOps, BloodHound 2.0 announcement, August 7, 2018 ^[10]

flowchart TD
Endpoint["Endpoint with admpwd.dll CSE"]
GPRefresh["Group Policy refresh, 90 minutes with jitter"]
Rotate["Generate per-machine random password
per PasswordAgeDays (default 30)"]
SAMWrite["Set local Administrator password via SAM"]
ADWrite["Write plaintext to ms-Mcs-AdmPwd
(CONFIDENTIAL, searchFlags 0x80)"]
LDAPRead["Helpdesk LDAP read"]
Bypass{"All Extended Rights
delegation on OU?"}
ReadSucceeds["Read succeeds (silent CONTROL_ACCESS bypass)"]
ReadFails["Read fails (correctly ACL-gated)"]
Endpoint --> GPRefresh
GPRefresh --> Rotate
Rotate --> SAMWrite
Rotate --> ADWrite
ADWrite --> LDAPRead
LDAPRead --> Bypass
Bypass -- yes --> ReadSucceeds
Bypass -- no --> ReadFails

The other structural limit was the directory's own integrity boundary. The password sat in plaintext in the directory. A stolen NTDS.dit -- obtained via DCSync, NTDSUtil dump, or physical theft of a DC's disk -- exposed every managed local-Administrator password in the forest at once. There was no encryption-at-rest in legacy LAPS, by design. The trust model was "the directory is tier 0 and DCSync is a domain-compromise event already," which is operationally true and architecturally lazy.

Microsoft fixed both of those structural defects on April 11, 2023. The fix shipped in the operating system, with no MSI. We come to it next.

6. The In-Box Era: Windows LAPS (April 11, 2023 to Present)#

Patch Tuesday, April 11, 2023. The April cumulative update for Windows 11 22H2 was KB5025239. The Windows 11 21H2 update was KB5025224. Windows 10 22H2 was KB5025221. Windows Server 2022 was KB5025230. Windows Server 2019 was KB5025229. The Server Annual Channel shipped it too. Windows Server 2016 was, and remains, explicitly excluded -- the per-SKU April-2023 cumulative-update KB numbers are catalogued in the Tenable retrospective on the Windows LAPS GA wave ^[3] and the official Microsoft LAPS overview page ^[11]. The MSI was gone. The admpwd.dll Client-Side Extension was gone. In its place: exactly three OS binaries -- laps.dll for core LAPS logic, lapscsp.dll for the Microsoft Intune Configuration Service Provider, and lapspsh.dll for the LAPS PowerShell module -- all shipped together, all part of the OS, all available without installing anything [@ms-laps-concepts-overview; @tc-windows-laps-ga-2023]. The Microsoft Learn laps-concepts-overview page enumerates the three binaries verbatim and lists no fourth.

The most consequential architectural change is the one most often missed.

The new schema added six attributes to the Computer object: msLAPS-Password (the plaintext-fallback location), msLAPS-EncryptedPassword (the CNG-DPAPI-wrapped ciphertext blob), msLAPS-EncryptedPasswordHistory (rotation history), msLAPS-PasswordExpirationTime, msLAPS-EncryptedDSRMPassword (Directory Services Restore Mode account on a DC), and msLAPS-EncryptedDSRMPasswordHistory ^[29]. The DSRM pair is a Windows-LAPS-only capability; legacy LAPS never covered Domain Controller DSRM accounts. The schema extension is performed once per forest by Update-LapsADSchema, which is idempotent and coexists with the legacy ms-Mcs-AdmPwd attribute ^[30].

Encryption-at-rest with CNG DPAPI#

The load-bearing addition is encryption of the password before it leaves the client. The mechanism is the CNG DPAPI group key-protector (still commonly called DPAPI-NG in Microsoft's older documentation) ^[31]. The client generates the new local-Administrator password, then wraps the plaintext against a security principal SID using the Active Directory Key Distribution Service (KDS) root key infrastructure. The wrapped blob is the only thing the LDAP write places into msLAPS-EncryptedPassword. To decrypt, a reader Kerberos-authenticates to the KDC; only members of the configured principal group at decryption time can derive the protector. The directory itself never sees plaintext, and a stolen NTDS.dit yields ciphertext only ^[29].

There are two policy settings that gate the encryption path, and the failure modes are operationally important.

The backup-directory choice#

The Entra-backup path went generally available on October 23, 2023 ^[12]. With BackupDirectory = 1, the local LAPS component posts the rotated password to the deviceLocalCredentials resource on the device object in Microsoft Entra ID via the Microsoft Graph API ^[32]. Retrieval is via Get-LapsAADPassword (a thin wrapper over the Graph endpoint), the Entra portal Devices blade, or a direct GET /directory/deviceLocalCredentials/{deviceId} call ^[33].

Policy surface and the FQ-anchored corrections#

Windows LAPS is configurable via Group Policy (for AD-joined hosts), the LAPS Configuration Service Provider at ./Device/Vendor/MSFT/LAPS/Policies/* for Intune-managed hosts ^[34], local policy, or the legacy LAPS GPO if PolicySourceMode selects emulation mode. The settings include BackupDirectory, PasswordComplexity (values 1 through 8), PasswordLength, PasswordAgeDays, PostAuthenticationActions, PostAuthenticationResetDelay, AdministratorAccountName, PassphraseLength, ADPasswordEncryptionEnabled, ADPasswordEncryptionPrincipal, and ADBackupDSRMPassword. On Windows 11 24H2 and Windows Server 2025 and later, the policy surface adds Automatic Account Management settings: AutomaticAccountManagementEnabled, AutomaticAccountManagementNameOrPrefix, AutomaticAccountManagementRandomizeName, AutomaticAccountManagementTarget, and AutomaticAccountManagementEnableAccount [@ms-laps-policy-settings; @ms-laps-account-modes].

PostAuthenticationResetDelay defaults to 24 hours. The range is 0 to 24 hours; a value of 0 disables the post-authentication action entirely ^[13]. A tier-0 fleet aiming to close the screenshotted-password OPSEC tail aggressively will configure this down to 1 hour; tier-2 deployments typically leave it at 8 or 24.

PasswordComplexity values 5 through 8 (Windows 11 24H2+ / Windows Server 2025+)#

PasswordComplexity values 1 through 4 are character-class modes (uppercase only; uppercase plus lowercase; uppercase plus lowercase plus numbers; and -- value 4, the default -- all four character classes). Value 5 is not a "no vowels or numbers" mode, despite a common folk attribution; it is the "improved readability" four-class variant of value 4, equivalent to value 4 with the visually ambiguous glyphs I, O, Q, l, o, 0, 1 removed and the symbols :, =, ?, * added ^[35]. Microsoft's own documented example password for value 5 is vnJ!!?MTb5=U7Y -- which retains vowels and digits 2 through 9. Values 6, 7, and 8 are passphrase modes drawn from a Microsoft-curated wordlist derived from the EFF Diceware wordlists [@eff-dice; @eff-wordlists-2016] with internal modifications. The published word counts after Microsoft's curation are 7776 / 1276 / 1276 for modes 6 / 7 / 8 respectively; the EFF originals (the EFF Long Wordlist, EFF Short Wordlist #1, and EFF Short Wordlist #2 published July 2016) are 7776 / 1296 / 1296 [@eff-dice; @eff-wordlists-2016]. Values 5 through 8 are all gated on Windows 11 24H2 / Windows Server 2025 and later -- not only values 6-8. The cited Microsoft Learn page reads verbatim for value 5: "The PasswordComplexity setting of '5' is only supported in Windows 11 24H2, Windows Server 2025, and later releases." ^[35]. Passphrase modes exist for DSRM-account scenarios where the password must be typed by a human under duress; the article's section 7 baseline recommends them for tier-0 break-glass accounts.

PowerShell surface and one important cmdlet name#

The native LAPS PowerShell module ships eight cmdlets the article calls out by name: Get-LapsADPassword, Reset-LapsPassword, Update-LapsADSchema, Set-LapsADAuditing, Set-LapsADComputerSelfPermission, Set-LapsADReadPasswordPermission, Set-LapsADResetPasswordPermission, and Find-LapsADExtendedRights [@ms-laps-ps-overview; @ms-laps-get-adpassword]. The auditing cmdlet is Set-LapsADAuditing -- not Set-LapsADAuditingSettings, which does not exist as a cmdlet name ^[36]. The Entra-backup retrieval cmdlet is Get-LapsAADPassword, a wrapper around Microsoft Graph.

Migration coexistence#

Legacy LAPS and Windows LAPS can coexist on the same host only if they target different local accounts. The documented coexistence pattern is to run legacy LAPS against the built-in RID 500 Administrator while introducing Windows LAPS against a named secondary local-admin account, then retire the legacy MSI once Windows LAPS coverage is verified ^[30]. The cross-pointer in section 11 details the seven-step migration sequence.

flowchart TD
Tick["laps.dll background timer (~1 hr)"]
ReadPolicy["Read effective policy
CSP > GPO > local > legacy emulation"]
BackupDir{"BackupDirectory
1 (Entra) / 2 (AD) / 0?"}
EntraPath["Write to Graph deviceLocalCredentials
(min PasswordAgeDays = 7)"]
ADPath["Write to msLAPS-* attribute set
(min PasswordAgeDays = 1)"]
EncryptionGate{"ADPasswordEncryptionEnabled = True
AND DFL ≥ Server 2016?"}
Encrypted["msLAPS-EncryptedPassword
(DPAPI-NG, principal = ADPasswordEncryptionPrincipal)"]
Plaintext["msLAPS-Password (plaintext fallback)"]
SetSAM["Set SAM password on
AdministratorAccountName (empty = RID 500)"]
Auth["Managed account authenticates"]
PAA{"PostAuthenticationActions
0 / 1 / 3 / 5 / 11?"}
Wait["Wait PostAuthenticationResetDelay (default 24 h)"]
Action1["1: reset password"]
Action3["3: reset + sign out, 2-min warning, DEFAULT"]
Action5["5: reset + reboot, 1-min delay"]
Action11["11: reset + sign out + terminate procs (24H2 / WS2025+)"]
Tick --> ReadPolicy
ReadPolicy --> BackupDir
BackupDir -- 1 --> EntraPath
BackupDir -- 2 --> EncryptionGate
BackupDir -- 0 --> SetSAM
EncryptionGate -- yes --> Encrypted
EncryptionGate -- no --> Plaintext
EntraPath --> SetSAM
Encrypted --> SetSAM
Plaintext --> SetSAM
SetSAM --> Auth
Auth --> Wait
Wait --> PAA
PAA -- 1 --> Action1
PAA -- 3 --> Action3
PAA -- 5 --> Action5
PAA -- 11 --> Action11

With the in-box era settled, what does a 2026 deployment actually look like? A short list of policy settings, and a slightly longer list of footguns.

7. The 2026 Baseline as a Settings Table#

Architecture is interesting. Audits are not. Here is the 2026 settings table that, in production, separates a deployment that meets its goal from one that quietly does not. Every row carries the policy node, the documented default, the recommended tier-2 value (a typical end-user fleet), the recommended tier-0 value (Domain Controllers and break-glass), and the citation. Cross-check the row against the Microsoft Learn policy-settings page before you ship it.

The audit-primitives sub-table#

The decision of which tool answers which question is, in practice, the difference between a LAPS deployment that meets its goal and one that quietly does not. The five (and a half) primitives:

No Microsoft Defender for Identity alert in the current public taxonomy names LAPS specifically ^[38]; instead, lean on the event 4662 SACL primitive plus advanced hunting in the IdentityDirectoryEvents table for principal-pattern anomalies. Microsoft's Compromised Credentials and Lateral Movement categories surface the downstream behaviour when a stolen LAPS password gets used.

// In production, run: Get-LapsADPassword -Identity * | Where-Object {
//   $_.ExpirationTimestamp -lt (Get-Date) -or $_.Source -eq 'Plaintext'
// }
// This in-browser demo mirrors the same logic against an array of mock computer objects.

const ONE_DAY_MS = 86400000;
const computers = [
{ name: "WS-001", msLapsExpiry: Date.now() + 5 * ONE_DAY_MS, encrypted: true  },
{ name: "WS-002", msLapsExpiry: Date.now() - 2 * ONE_DAY_MS, encrypted: true  },
{ name: "WS-003", msLapsExpiry: null,                        encrypted: false },
{ name: "WS-004", msLapsExpiry: Date.now() + 1 * ONE_DAY_MS, encrypted: false },
];

const gaps = computers.flatMap(c => {
const issues = [];
if (c.msLapsExpiry === null)           issues.push("no password stored");
else if (c.msLapsExpiry < Date.now())  issues.push("expired (overdue rotation)");
if (!c.encrypted)                      issues.push("plaintext (msLAPS-Password)");
return issues.length ? [`${c.name}: ${issues.join(", ")}`] : [];
});

console.log(gaps.length === 0
? "All computers have current, encrypted LAPS passwords"
: "Coverage gaps:\n  " + gaps.join("\n  "));

The AdministratorAccountName decision deserves one paragraph of its own. On Server SKUs, the built-in Administrator (RID 500) is enabled by default, and leaving the policy empty manages it -- this is what most deployments want. On Client SKUs the built-in is disabled by default; many shops create a named admin account (a common convention is lapsadmin) and set AdministratorAccountName to that name. On Windows 11 24H2 and Windows Server 2025 and later, the better answer is Automatic Account Management: set AutomaticAccountManagementEnabled = 1, AutomaticAccountManagementRandomizeName = 1, and AutomaticAccountManagementEnableAccount = 0, and the host will auto-create a randomised-name disabled-by-default local-admin account that Windows LAPS owns end to end ^[39]. The result is that an attacker enumerating local accounts cannot guess the LAPS-managed account name from RID 500, RID 1000, or any other predictable identifier.

This is the baseline. But LAPS is not the only answer to "who knows the local admin password." For three classes of fleet, the right answer is something else.

8. When LAPS Is Not the Right Tool#

Three classes of fleet should not -- or should not only -- run Windows LAPS. The first wants a workflow LAPS does not offer. The second wants no standing local admin at all. The third is orthogonal: it changes the in-session elevation surface without changing the recoverable break-glass.

Third-party Privileged Access Management (PAM) vaults. Delinea Secret Server ^[40], CyberArk Endpoint Privilege Manager ^[41], and BeyondTrust Password Safe are the dominant 2026 commercial offerings in the category. The case for running a PAM vault alongside (or instead of) Windows LAPS is rarely about cryptography and almost always about workflow. PAM vaults bring multi-factor authentication on checkout, full session recording, dual-approval gates for high-risk accounts, and cross-OS scope (Windows, macOS, Linux, network gear, hypervisors) under one ACL model. The total cost of ownership is higher than LAPS; the security model, properly deployed, is comparable. Many shops run both: Windows LAPS for the workstation floor, PAM for tier-0 break-glass with session recording. The split is a workflow trade-off, not an architectural one.

Zero standing local admin plus Entra PIM JIT elevation. Tier-0 fleets that have reached the "no routine local admin" architectural state disable the built-in RID 500 entirely and gate every admin operation through just-in-time elevation. Microsoft Entra Privileged Identity Management ^[37] supports the eligibility / activation / approval workflow at scale: an operator is eligible for an admin role, activates it for a bounded duration with optional MFA and ticket reference, and an approver signs off on the activation if policy requires. Windows LAPS coexists in this model as the absolute-last-resort break-glass mechanism -- for the case where Entra itself is down, the network is partitioned, and a human has to walk to a console and type a password. The architectural alignment is with MITRE T1078.001 (Default Accounts) ^[15]: if the default account is permanently disabled and only re-enabled under PIM workflow, the entire technique class is bounded by the PIM activation log.

Windows 11 25H2 Administrator Protection. Per-elevation transient admin sessions arrived as a Tech Community preview in late 2025 ^[42]. The feature creates a temporary, isolated "shadow admin" identity for the duration of each elevation prompt, brokering UAC-class elevation through a per-elevation token that is destroyed when the elevated process exits. This is orthogonal to LAPS, not a replacement. Administrator Protection addresses in-session UAC elevation; Windows LAPS addresses the recoverable break-glass password for off-network and non-bootable recovery. The two systems answer different questions. Conflating them produces designs that drop LAPS in favour of Administrator Protection and then discover, six months later, that there is no recovery primitive for a laptop the user has dropped off the corporate network for a year.

flowchart TD
Start["Local-admin password problem for a fleet"]
BYOD{"BYOD or unmanaged?"}
EnrollFirst["Enrollment is the answer, not LAPS"]
Join{"AD-joined / hybrid / Entra-joined?"}
WS2016{"Stuck on WS2016 or in migration?"}
Tier0{"Tier 0 with zero-standing-credential goal?"}
CrossOS{"Non-Windows scope or checkout workflow needed?"}
WinElev{"Win 11 25H2 in-session elevation hardening?"}
MA["Method A: Windows LAPS, AD backup"]
MB["Method B: Windows LAPS, Entra backup"]
MC["Method C: legacy MSI LAPS"]
MD["Method D: PAM vault, alongside A/B"]
ME["Method E: PIM-gated JIT, layered on A/B"]
MF["Method F: Administrator Protection (orthogonal)"]
Start --> BYOD
BYOD -- yes --> EnrollFirst
BYOD -- no --> Join
Join -- AD or hybrid --> MA
Join -- pure Entra --> MB
MA --> WS2016
MB --> WS2016
WS2016 -- yes --> MC
WS2016 -- no --> Tier0
Tier0 -- yes --> ME
Tier0 -- no --> CrossOS
CrossOS -- yes --> MD
CrossOS -- no --> WinElev
WinElev -- yes --> MF

All five answers above -- methods A through F -- have a structural ceiling. There is one bound none of them can break.

9. What LAPS Structurally Cannot Solve#

Every recoverable-secret system has a privileged reader. Whether you call it ADPasswordEncryptionPrincipal, a "CyberArk vault admin," or a "PIM eligible approver," somebody can break the glass -- which means somebody can compromise the glass. This is a lower bound, not an implementation defect.

The eleven-year arc converged on a tight bound. It did not abolish the underlying problem. Four structural limits are worth naming, because each maps onto a real residual attack surface in 2026 deployments.

Bound 1: at least one reader exists, by construction. Symbolically, $|\text{readers}| \geq 1$. CNG DPAPI's group-key-protector substitution does not eliminate the privileged class; it relocates the trust boundary. The boundary moves from "every principal with LDAP read on the attribute" (legacy LAPS) to "every principal in the configured ADPasswordEncryptionPrincipal group at decryption time" (Windows LAPS). The relocation tightens the bound by orders of magnitude in typical fleets -- a LAPS-DPAPI-Decryptors group with five members beats an "All Extended Rights on the helpdesk OU" delegation with five hundred -- but it does not move the bound to zero. The directory that stores the LAPS secret remains a tier-0 asset, and the decryptor group remains a tier-0 principal class.

Every recoverable secret has a privileged reader. The architectural game is to make the reader class small, audited, time-bounded, and reachable from the directory only through Kerberos. The game is not to make the reader class empty. That game has no winning move.

Bound 2: the out-of-protocol OPSEC tail. Once a plaintext password leaves the directory -- pasted into a helpdesk ticket, screenshotted into a Slack DM, stored in a shared KeePass database that the team forgot to rotate -- the protocol's rotation knob is the only remaining mitigation. PostAuthenticationActions only fires after the next managed-account interactive logon ^[13]; pre-logon exposure is bounded only by PasswordAgeDays. A password screenshotted into a chat log at 10:14 AM and never used is the password on that endpoint for the remainder of the configured rotation window, regardless of whether anyone has noticed the leak. The protocol does not, and cannot, solve "the password is now in a chat log."

Bound 3: unmanaged and BYOD endpoints. A machine that is neither AD-joined nor Microsoft Intune-managed has no LAPS policy applied to it. Personal-device BYO MAM scope is outside the LAPS protection model entirely. The fix for these endpoints is enrollment, not LAPS. A non-trivial portion of the residual local-admin-password risk in 2026 is concentrated on the long tail of unmanaged endpoints that exist precisely because management was politically or contractually infeasible. The protocol does not solve this; governance solves this.

Bound 4: verification asymmetry. The directory's audit log says what it chose to log. An unprivileged observer cannot verify enforcement from outside the directory. This is the structural ceiling that motivates external audit primitives -- PingCastle ^[7], BloodHound ^[28], Defender for Identity ^[38] -- because they sit outside the directory's own self-report. The bound cannot be closed inside the protocol; only an out-of-band attestation primitive can certify enforcement to a party that does not trust the directory.

Somebody has to break the glass. The decryptor group is the new tier-0 asset; LAPS bounds the problem, it does not abolish it. The eleven-year arc was a convergence on a tighter bound, not an arrival at a clean answer. The right framing for the 2026 baseline is "the residual attack surface is now the actual attack surface, rather than an artefact of incomplete shipping." That is real progress -- it just is not closure.

Some of those structural bounds map onto open problems with no clean 2026 answer. We close on six of them.

10. Open Problems in 2026#

Six open problems in local-admin password management for which no first-party Microsoft answer ships in 2026. Each is one paragraph, framed as "what is the question," "what has been tried," and "what is the current best partial result."

1. Legacy SYSVOL cpassword cleanup at scale. MS14-025 disabled new authoring twelve years ago; it never deleted what it patched ^[6]. No first-party Find-GPPPassword or Remove-GPPPassword cmdlet ships in the OS in 2026. PingCastle's A-PwdGPO rule and Semperis Purple Knight's equivalent scanner fill the gap ^[7]. The 2026 answer is: scan with a third-party tool, rotate the discovered credentials in whatever account-management primitive owns them, then delete the XML. The open question is why Microsoft has not shipped this in the twelve years since the bulletin. The blast-radius argument from 2014 -- "we cannot risk auto-deleting policy XMLs from SYSVOL" -- is now strictly weaker than the cleanup-tail argument that the residual artefacts keep showing up on internal pentest reports a decade later.

2. Cross-tenant and cross-directory LAPS coverage view. No portal-level "every Entra-joined and every AD-joined device that does not have a current LAPS password" report exists. Microsoft Intune compliance reports help on the Intune-managed side; Get-LapsADPassword -Identity * covers the AD side; Get-LapsAADPassword covers the Entra side. There is no single pane that unifies them. The 2026 answer is custom KQL or PowerShell that joins the three result sets on a normalised device identifier. The bottleneck is identity: Intune device IDs, AD objectGuid values, and Entra deviceId values are three different surrogate keys, and a fleet's mapping table is its own engineering investment.

3. Hybrid-joined BackupDirectory ambiguity. Microsoft Learn's current guidance is that hybrid-joined devices should typically use BackupDirectory = 2 (AD) when on-premises AD is the canonical identity store, and may use BackupDirectory = 1 (Entra) when Intune is the primary policy-delivery mechanism ^[33]. In practice, the documentation hedges, and many shops configure both directions (one via GPO, one via Intune CSP) and rely on the per-device evaluation order to pick one. The result is a coverage-verification problem: a device that is "configured for AD backup" by GPO and "configured for Entra backup" by CSP can end up with the password in either backend, and the source of truth depends on policy precedence rules most operators do not memorise.

4. Windows 11 25H2 Administrator Protection and LAPS interaction. Administrator Protection's per-elevation transient admin tokens and Windows LAPS's recoverable break-glass password are operationally adjacent but architecturally disjoint ^[42]. The documentation covers each feature on its own; the interaction matrix -- "what does a LAPS-managed RID 500 look like under Administrator Protection on a Win 11 25H2 host" -- is not laid out in one place. Tier-0 architects who want both behaviours have to assemble the answer from two product pages.

5. LDAP channel binding and signing enforcement migration. Microsoft has been hardening LDAP channel binding through a multi-year 2020-2024 enforcement push tracked under KB4520412 ^[45]. The original March 10, 2020 update introduced Channel Binding Token (CBT) signing events 3039, 3040, and 3041; the manual enablement step was removed on November 14, 2023 for Windows Server 2022 and on January 9, 2024 for Windows Server 2019, after which the hardening became the default posture; starting with Windows Server 2022 23H2, all new versions ship with the full set of changes in the KB applied ^[45]. Tooling that does not speak LDAPS-with-channel-binding will break when enforcement reaches its terminal state. Modern attack-graph tooling -- bloodyAD ^[46] and the lapsv2decrypt reference implementation ^[47] -- has tracked the changes. Not every Linux pentest stack has. Practitioners building Linux-based LAPS retrieval pipelines should validate their stack against the channel-binding-required posture before the enforcement wave reaches them.

6. The retrieval-event audit gap (cross-directory). Active Directory does not natively log every read of msLAPS-EncryptedPassword; Set-LapsADAuditing installs a SACL that emits Directory Service event 4662 for configured attribute reads ^[36]. Microsoft Entra ID logs LAPS retrieval through its own audit log, surfaced via the Graph endpoint ^[32]. The two log streams have different schemas, different timestamp normalisations, and different principal identifiers. Cross-pane unification of "who read which LAPS password when" across both backends is a DIY engineering problem in 2026. Microsoft Defender for Identity surfaces some of the AD-side reads under the Compromised Credentials and Lateral Movement categories ^[38] but does not name LAPS specifically in the public alert taxonomy.

None of those six dissolves the architectural lesson the eleven-year arc taught: the right defaults take a decade to ship. Here is the practitioner field manual for the meantime.

11. Practitioner Field Manual and FAQ#

What follows is a seven-step deployment list, three named sidebars that surface the most common misconceptions, and a seven-question FAQ. Lift the step list verbatim into your deployment runbook; the sidebars exist because the article would not be defensible without them.

The audit-and-migrate seven-step list#

1. Audit SYSVOL for cpassword first. Run PingCastle's A-PwdGPO (MITRE T1552.006) [@pingcastle-rules; @mitre-t1552-006] before touching anything else. A Windows triage one-liner -- findstr /s /i cpassword \\domain\SYSVOL\*.xml -- will land on most environments in under a minute. Remediate the discovered XML files (rotate the underlying account passwords, then delete the XMLs) before deploying Windows LAPS so the attack surface and the defence are not co-evolving in the same window.
2. Extend the AD schema for Windows LAPS. Run Update-LapsADSchema once per forest from a Domain Admin context. The cmdlet is idempotent and coexists with the legacy ms-Mcs-AdmPwd attribute on the same Computer object ^[30].
3. Delegate. Run Set-LapsADComputerSelfPermission on each target OU so that computer accounts can write their own msLAPS-* attributes. Audit existing "All Extended Rights" delegations with Find-LapsADExtendedRights and remove any that do not have an explicit operational justification ^[48]. This is the legacy-LAPS lesson applied to the new attribute set.
4. Configure encryption-at-rest. Verify that the forest's Domain Functional Level is Windows Server 2016 or higher. Configure ADPasswordEncryptionEnabled = 1 explicitly even though the default is True -- the explicit configuration makes the choice visible in policy audits and forces the operator to verify the DFL prerequisite ^[13]. Assign ADPasswordEncryptionPrincipal to a dedicated LAPS-DPAPI-Decryptors group, not Domain Admins ^[29].
5. Deploy policy. GPO for AD-joined, Intune CSP for Entra-joined and hybrid-joined ^[34]. Settings as per section 7's baseline table. Validate via Get-LapsADPassword -Identity <computer> against a representative sample of hosts after the first one-hour rotation timer has fired ^[49].
6. Migrate from legacy LAPS. Use the documented coexistence pattern: the legacy MSI's CSE keeps running against the built-in RID 500, the new in-box LAPS takes over against a named secondary local-admin account, then retire the legacy ms-Mcs-AdmPwd schema readers and uninstall the MSI once Windows LAPS coverage is verified ^[30]. The legacy MSI's installation is blocked on Windows 11 23H2 and later ^[26].
7. Continuous audit. PingCastle for coverage rules (A-LAPS-Not-Installed, A-LAPS-Joined-Computers, and the GPP A-PwdGPO) ^[7]; BloodHound for the ReadLAPSPassword edge across the graph ^[28]; Defender for Identity for downstream behaviour under Compromised Credentials and Lateral Movement ^[38]; and a custom KQL on the Entra audit log for LapsPasswordRetrieved events. None of these is optional in a deployment that intends to detect compromise.

Sidebar A: MS16-072 is NOT the LAPS attribute-readability bulletin#

A recurring misattribution credits MS16-072 / KB3163622 / CVE-2016-3223 (June 14, 2016) [@ms16-072-bulletin; @ms16-072-kb; @cve-2016-3223] with closing the legacy LAPS attribute-readability issue. It does not. MS16-072 is a Group Policy retrieval-context fix: it moved user-side GPO fetch into the computer's security context to defeat a man-in-the-middle class on policy traffic. The actual LAPS attribute-readability issue -- "All Extended Rights" delegations silently including CONTROL_ACCESS on the CONFIDENTIAL ms-Mcs-AdmPwd attribute -- has no Microsoft-assigned CVE or bulletin. The canonical write-up is Sean Metcalf's August 2016 ADSecurity piece ^[9], and the operational primitive is SpecterOps's ReadLAPSPassword BloodHound edge ^[28].

Sidebar B: "Hybrid joined" is not "Hybrid Worker"#

Microsoft Entra hybrid joined devices are workstations joined to both an on-premises AD domain and Microsoft Entra ID. The LAPS conversation about hybrid joined is a BackupDirectory choice. Microsoft Entra hybrid runbook workers, on the other hand, are an Azure Automation primitive -- worker processes that execute Automation runbooks against on-premises resources. They share a word and nothing else. A LAPS policy targeted at "hybrid devices" means hybrid joined; it has nothing to do with hybrid runbook workers. The article's section 8 includes the same disambiguation because operators conflate them with surprising frequency.

Sidebar C: How GPP cpassword still gets found in 2026#

MS14-025 disabled new authoring but did not delete the artefacts ^[6]. The artefacts persist because SYSVOL replication is conservative -- nothing in the forest's design deletes anything from SYSVOL just because the editor UI was hot-patched on the administrative workstation. A fresh PingCastle scan against a long-lived forest will routinely surface 2010-era Groups.xml files ^[7], and the third-party scanner cohort is the only practical defence. The one-shot remediation pattern is: find with A-PwdGPO, rotate the underlying password via the replacement tool (Windows LAPS for built-in local admin; a PAM vault for service accounts that were stored in GPP), then delete the Groups.xml and let SYSVOL replication propagate the deletion.

Twenty years. Eleven years of which separated Microsoft's December 2012 articulation of the architecture from the April 11, 2023 in-box default [@ms-pth-whitepaper; @tc-windows-laps-ga-2023]. Four residual attack surfaces -- delegated-decryptor compromise, the pre-rotation OPSEC tail, BYOD endpoints, and the multi-decade MS14-025 cleanup tail ^[6] -- still resist the architecture rather than fall to it. One through-line: this is what shipping the right default a decade late looks like. The right defaults are now in the box. The directory is still tier 0. Somebody still has to break the glass. The architectural game from here is not to invent a new generation; it is to make sure the one we finally have is actually deployed, audited, and clean.