ReadLAPSPassword (Active Directory Permission Abuse)

How ReadLAPSPassword Works in Active Directory

ReadLAPSPassword is not a password itself, but a delegated permission. It grants a principal the ability to retrieve the local administrator secret managed by Microsoft LAPS for a specific device or set of devices, so the holder can authenticate as a local admin if needed.

That design is useful when tightly controlled, because it reduces shared password sprawl and gives operators a way to recover access without baking the same local admin password into every endpoint. The control becomes dangerous when the right is assigned too broadly, because the permission exposes a live local admin credential rather than a metadata-only view.

Why This Permission Is Sensitive

The sensitivity comes from what the permission reveals: a reusable privileged secret on the target machine. If an attacker or over-privileged insider can read it, the result is not just visibility into an account, but the ability to use that account for privilege escalation on the endpoint and, in many environments, lateral movement to adjacent systems.

This is why ReadLAPSPassword should be treated as a high-value delegation point rather than a routine read right. It sits at the boundary between administrative convenience and credential exposure, so the blast radius depends on how many devices the principal can query and how much trust is placed in that principal’s account or group membership.

Exposure Checks and Delegation Review

Organisations should verify who can read LAPS passwords, where that delegation was granted, and whether the permission is scoped to the smallest practical set of administrators, support teams, or break-glass workflows. A useful review starts with the directory object permissions themselves, then moves to device scope, group nesting, inheritance, and any delegated administration model that might unintentionally expand access.

It also helps to validate the broader password management path. If LAPS is used to back up secrets to active directory or Entra-backed storage, the operational question is not just whether passwords exist, but who can retrieve them, how that retrieval is audited, and whether the intended access model still matches the current admin structure.

Detection, Misuse Signals, and Recovery

Abuse can be subtle because password reads may look like normal administrative activity unless they are monitored and correlated with endpoint administration, unusual account use, or unexpected access to many hosts. Teams should watch for access patterns that do not match approved support processes, especially when a principal that rarely handles endpoint administration begins reading multiple local admin passwords.

When misuse is suspected, the priority is to revoke the delegation, review the affected devices for post-access activity, and rotate the local administrator secrets so any copied password becomes useless. If the password was used to gain foothold, treat the event as a credential compromise and review for service abuse, lateral movement, and persistence on the endpoints that were exposed.

Practitioner Guidance

Governance implication: ReadLAPSPassword should be managed like privileged access, not like ordinary directory read access. The practical question is whether the principals allowed to retrieve it are truly accountable for endpoint recovery and whether their scope matches the devices they are meant to support.

What to watch for: broad group membership, inherited permissions, and “temporary” delegation that becomes permanent are the usual failure modes. If password reads are hard to justify in plain operational terms, the permission is probably too broad.

Practitioner takeaway: If a team can recover endpoints without reading passwords, remove the right entirely; if it must exist, keep it narrowly scoped, monitored, and regularly recertified.

Related resources from NHI Mgmt Group

• Guide: Local Administrator Password Solution (LAPS) Guide
• ReadGMSAPassword (Active Directory Permission Abuse)
• Why do Active Directory misconfigurations increase privilege abuse risk?
• How should teams reduce Active Directory abuse if monitoring alone is not enough?
• Who should be accountable for dMSA abuse in Active Directory?