LAPS Deployed Broken Coverage Gaps: Audit and Remediation

Summary: What Are LAPS Deployed Broken Coverage Gaps?

LAPS deployed broken coverage gaps describe an Active Directory environment where local administrator password management exists, but its protection stops short of the machines or identities that matter. Some computers never receive the intended policy. Others still use legacy clear-text storage, grant recovery rights too broadly, or leave an exposed password usable until rotation succeeds.

Windows Local Administrator Password Solution manages and backs up a local administrator account's password. Its purpose includes reducing lateral movement through reused local credentials. Microsoft's Windows LAPS overview describes both Active Directory backup and the newer native implementation. A policy object, installed feature, or populated attribute is evidence to investigate; each answers a different question from whether every intended device is protected.

This article assumes AD-backed LAPS is already present. Our Windows LAPS not deployed guide explains the missing credential lifecycle: unmanaged, static, or shared local administrator passwords and how to establish rotation. Our computer object hygiene and LAPS schema article covers the more fundamental prerequisite of an unextended schema, alongside computer and domain controller hygiene. Here the schema exists and deployment has begun; the task is to find where that deployment fails.

How It Works: Four Ways Deployed LAPS Loses Protection

1. Partial domain coverage

A rollout can succeed in a pilot OU while missing member servers, newly provisioned workstations, or devices moved to another OU. That leaves two populations behind the same reassuring statement: “we use LAPS.” Review the intended inventory and actual device state separately for workstations and member servers, rather than letting a large workstation population conceal an unmanaged server estate.

Coverage is also different from health. An expiration attribute can remain populated while a device is offline or policy processing fails. Record whether a computer has native Windows LAPS evidence, legacy evidence, or neither, then validate recent activity against the configured rotation policy. Keep disabled computer objects and domain controllers explicit in the scope; DSRM password management is a separate DC use case.

2. The legacy attribute is still the recovery path

The generations use different attributes. Microsoft's schema reference maps ms-Mcs-AdmPwdExpirationTime to msLAPS-PasswordExpirationTime and ms-Mcs-AdmPwd to msLAPS-Password. The native msLAPS-Password value is clear-text password data in JSON; msLAPS-EncryptedPassword holds encrypted data. The msLAPS- prefix alone therefore does not prove encryption.

Windows LAPS can honor old policy through legacy Microsoft LAPS emulation mode. Emulation continues clear-text AD storage and cannot supply native password encryption. Finding a legacy attribute should trigger a review of the active policy and migration state, rather than an assumption that the old client extension is necessarily running. Native Windows LAPS policy takes precedence over legacy policy. Emulation also requires the legacy Microsoft LAPS client-side extension to be absent from the managed device.

3. Password retrieval is delegated too broadly

Rotation cannot compensate for an unauthorized principal recovering the current password. Check both the permission to retrieve the stored material and, when encryption is used, the authorized decryptor. These are separate controls. A helpdesk group with an approved recovery responsibility deserves a membership review; it does not become safe merely because its name contains “LAPS.”

Broad OU delegation can affect many computers. Explicit computer permissions can also differ from the OU baseline. Review inherited grants, exceptions, group membership, and the approved recovery population together. A grant to a group is not the same thing as a count of the individual people who can exercise it.

4. Password exposure outlives the access review

An ACL change restricts future directory reads. It cannot withdraw a password already copied into a ticket, transcript, script output, or another person's session. Those are incident investigation possibilities, not evidence that a particular environment has suffered a leak.

The Attack Chain: From Recovery Rights to Local Access

A plausible failure sequence starts with compromise of an identity that has unintended recovery rights. If that principal can obtain a usable local administrator password, the attacker gains a credential for the affected computer. The resulting reach depends on account state, network access, and local authentication controls; a readable attribute is not an automatic domain takeover.

An uncovered device presents a different route: its local password remains outside the intended LAPS lifecycle. A legacy-only device may rotate correctly yet still expose clear-text recovery material to an overbroad reader population. These conditions can coexist, but they require different fixes. Expanding policy scope does not remove excessive readers, and enabling encryption does not bring an excluded device into scope.

For incident triage, identify the computer, stored password generation, authorized recovery population, and successful rotation after containment. Avoid exporting real passwords merely to demonstrate the weakness. Metadata, ACL evidence, and endpoint logs usually provide a safer first assessment.

Measure Coverage and Reader Permissions

Find computers with native expiration evidence

Microsoft's migration guidance identifies a new or updated msLAPS-PasswordExpirationTime as one way to monitor transition to native Windows LAPS. The command below is an audit adaptation of the documented Get-ADComputer LDAP filter and property parameters, using the documented attribute. Replace the example OU with your approved audit scope. This command is provided for the reader; it was not executed against a production domain for this article.

Get-ADComputer -SearchBase 'OU=Workstations,DC=corp,DC=example' -LDAPFilter '(msLAPS-PasswordExpirationTime=*)' -Properties 'msLAPS-PasswordExpirationTime',OperatingSystem,Enabled

The result is a list of computers with native expiration evidence, not a percentage and not proof that every result is healthy. Compare it with the expected device inventory to identify missing computers. A legacy expiration value on a missing computer may show an older deployment. Check disabled state, intended backup directory, and actual endpoint configuration before assigning a coverage gap. An Entra-backed device should not be judged by the absence of an AD backup attribute.

For a defensible coverage calculation, reconcile the same enabled, in-scope workstation and member-server inventory against native or legacy deployment evidence. State which generations count as covered. Keep the migration-to-native view separate from the any-generation deployment view. Then review expiration freshness and successful rotation; attribute presence alone cannot establish either.

Enumerate recovery principals

The Find-LapsADExtendedRights reference documents the OU query and -IncludeComputers option. This example substitutes an audit OU and includes computer-level permissions:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=example' -IncludeComputers

Compare the returned principals with an approved recovery list and inspect the relevant memberships and inherited or explicit permissions. Treat this as permission enumeration, rather than proof of a completed password read or an exhaustive reconstruction of effective access. Preserve object identifiers and trustee identifiers in the audit evidence without storing password values.

For an authorized recovery check on one computer, Microsoft's Get-LapsADPassword reference documents the following pattern, with an example computer name substituted. This retrieves credential material; it is not a metadata-only query and was not run against a production domain for this article.

Get-LapsADPassword -Identity 'WS-001'

Without -AsPlainText, returned passwords are wrapped in SecureString. Inspect Source, DecryptionStatus, and AuthorizedDecryptor to distinguish storage and decryption outcomes. The cmdlet also retrieves legacy ms-Mcs-AdmPwd passwords, but legacy results lack Account and PasswordUpdateTime; a blank update time there is not evidence of a failed rotation.

Detection: Read the Client's LAPS Operational Log

Microsoft documents these signals in the Windows LAPS event log reference:

Collect these events from Microsoft-Windows-LAPS/Operational on the managed clients. The corresponding channel on a domain controller concerns its own DSRM management, not the activity of domain-joined clients. A successful processing cycle need not include rotation if no password update was due.

Correlate events per device and processing cycle. Use the configured policy to decide when an update should have occurred. These operational events establish processing and update outcomes; they do not establish who retrieved the stored password. Missing events also require a check of collection health before being treated as missing LAPS activity.

Remediation: Close Each Failure Separately

1. Repair policy scope and write permissions

Assign an owner to each uncovered computer. Verify its intended backup directory and policy targeting, then repair the actual cause: OU placement, filtering, policy precedence, or write delegation. Microsoft's AD deployment procedure documents the following command, with an example OU substituted:

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example'

This grants self-update permissions for native Windows LAPS attributes; it does not configure policy or prove successful backup. For legacy or emulation deployments, use the legacy ACL tooling described in Microsoft's emulation guidance, rather than assuming this native cmdlet repairs legacy permissions. Recheck the candidate list and endpoint update evidence after the fix.

2. Restrict retrieval and decryption

Remove unintended grants at their actual source, including inherited permissions, then delegate recovery to the approved population. Adding a narrow grant does not revoke a broad existing grant. Repeat the rights query after the ACL review and test approved recovery without placing credentials in general audit output.

For native AD encryption, Microsoft's policy settings reference requires Domain Functional Level 2016 or later. Review ADPasswordEncryptionEnabled and ADPasswordEncryptionPrincipal; the latter identifies the authorized decryptor and must resolve on the device. Do not treat directory retrieval rights as equivalent to decryption authority.

3. Complete the legacy migration

Follow Microsoft's migration procedure for immediate transition or temporary coexistence. During coexistence, the two implementations must manage different local accounts. Verify native policy, updated native attributes, and successful endpoint activity before removing legacy software. Also review access to residual legacy password material; a successful native rollout does not establish that every old recovery path has been cleaned up.

4. Rotate after credible exposure

After containing unauthorized access, coordinate rotation on the affected endpoint. Microsoft documents Reset-LapsPassword for exceptional situations requiring an immediate change, including a machine security breach:

Reset-LapsPassword

Run it locally on the affected managed device with the required privileges. The cmdlet does not return detailed outcome information; verify the resulting events. A submitted reset request is not sufficient evidence that the exposed credential has stopped working. Review the incident's affected identities and endpoints alongside rotation, rather than closing it solely because the reader ACL changed.

How EtcSec Detects This

The catalogue accepts these four identifiers. The following descriptions reflect the Detect() implementations reviewed for this article, not a claim that an audit was run against your domain:

• LAPS_DOMAIN_COVERAGE_LOW evaluates coverage across enabled non-DC computers, counting legacy or native LAPS presence. It separates workstation and server figures and reports a domain-level metric. In the reviewed Detect(), coverage below 95% produces a finding: High below 80%, otherwise Medium below 95%. These are EtcSec control thresholds, not Microsoft recommendations. Source: etc-collector public/internal/audit/detectors/ad/advanced/laps/laps-domain-coverage.go, lines 78–86, commit f51fad0b69c0c7fbda2fcc3c43bd6f6b4da4bee4, reviewed October 3, 2026. The control measures deployment evidence, not rotation freshness or encryption quality.
• LAPS_LEGACY_ATTRIBUTE identifies computers with legacy LAPS evidence and no native Windows LAPS evidence. It does not identify the executing client implementation or demonstrate an unauthorized read.
• LAPS_PASSWORD_READABLE examines grant ACEs with CONTROL_ACCESS targeting the live forest's resolved ms-Mcs-AdmPwd schema GUID. It excludes recognized built-in administrator trustees and the computer's own SID. Its scope is this legacy permission signal, not a general assessment of native encrypted-password decryption rights.
• LAPS_PASSWORD_LEAKED uses the same legacy CONTROL_ACCESS grant-ACE signal and flags more than one distinct reader trustee on a computer after the same built-in-admin and self-SID exclusions. Here, "non-admin" means not recognized by that filter; the detector does not establish every trustee's effective administrative role. It flags potential excessive permission exposure, not observed exfiltration, and does not expand groups into a headcount of people. Validate effective access separately: this predicate counts matching grants rather than resolving deny ACEs against them.

Use etc-collector findings to prioritize investigation, then validate coverage, effective rights, policy generation, and endpoint rotation separately. A deployment finding can be resolved while a permission problem remains. Close the review only when the intended inventory and approved recovery path both match the evidence.