Windows LAPS and gMSA Review for Credential Exposure
Windows LAPS and group Managed Service Accounts (gMSA) solve different credential problems. Windows LAPS manages a local administrator password on each device and stores its current value and expiry in Active Directory or Entra ID. A gMSA provides a service identity whose password is managed by Active Directory and used by approved computers. Neither feature makes access safe by itself. Review must prove who can retrieve a LAPS password, which hosts can use a gMSA, and whether rotation occurred.
Start with identity purpose
Build one credential register. Include managed account name, business service, owner, directory location, target devices or hosts, recovery procedure, last rotation, next expected rotation, and retrieval authority. Separate human emergency access from service execution. A server administrator may restart a service without needing permission to read every local administrator password. Password retrieval remains a narrower, logged privilege.
For Windows LAPS backed up to Active Directory, Microsoft documents ACLs on computer objects as the frontline control. Review inherited and explicit permissions on each managed OU. Set-LapsADReadPasswordPermission grants password-read permission; Set-LapsADResetPasswordPermission grants expiry-reset permission. Both deserve separate groups. Where supported, encryption adds another layer, but it does not remove need to review membership and audit reads.
Test LAPS retrieval and rotation
Use an approved help-desk test identity and an unapproved ordinary identity. Record the managed computer, directory attribute query, timestamp, actor, result, and corresponding audit event. Pass means approved group retrieves only approved device passwords and unapproved identity is denied. A broad inherited reader, delegated full control on the OU, or password data in ticket text is fail.
Rotation evidence needs more than a policy screenshot. Capture current password expiry, force a scoped processing cycle in a controlled test where approved, then show a new expiry and successful authorised retrieval without recording plaintext in the report. Windows LAPS processes active policy in a background cycle and supports reset before scheduled expiry. A failed rotation becomes remediation with device owner, cause, temporary access process, and retest date.
Review gMSA host access
gMSA password material is retrieved by computers authorised to use the account. For each gMSA, inspect PrincipalsAllowedToRetrieveManagedPassword, service bindings, scheduled tasks, IIS pools, and installed service configuration. Compare allowed hosts with actual hosts. A retired server that remains authorised is a credential boundary failure even if it is powered off today.
Test from one approved host by starting the documented service and checking its expected non-secret operational output. Test from an unapproved joined host without attempting to extract or display password material; failure to establish the service identity is expected. Preserve configuration export and event evidence. Never use a gMSA for interactive administration or assign it broad directory privileges because its password is rotated.
Completed review example
| Item | Evidence | Result | Remediation or exception |
|---|---|---|---|
| Workstation LAPS OU | named readers; unapproved query denied | Pass | Review membership monthly |
| Server LAPS OU | inherited Helpdesk-All read permission | Fail | Replace with server support group; retest |
gmsa-web$ | two current web hosts match service inventory | Pass | Owner confirms after deployment |
gmsa-batch$ | retired BATCH-OLD still allowed | Fail | Remove host; verify batch task |
An exception is not “business need.” It names affected account, approval owner, compensating control, date, and expiry. On expiry, access is removed or reviewed again. Keep access-review output separate from password values and limit report distribution.
Ongoing evidence
Repeat review when an OU is reorganised, a support group changes, a server is retired, or an application moves hosts. Reconcile Active Directory permissions with the service inventory rather than relying on either source alone. Record who reviewed each access list and when. For incidents, use approved emergency retrieval under the same logging rules, then rotate access if policy requires it and preserve audit references. Treat unknown account ownership, missing inventory linkage, or an unreadable rotation record as a failed control until an owner resolves it. This prevents managed credentials from becoming unmanaged access paths.
Review boundaries
Do not treat successful password rotation as proof every retrieval path is appropriate. Review local administrators, nested groups, delegated OU rights, backup operators, and incident-response accounts for indirect access. Reconcile emergency procedures with current support coverage so an outage does not lead to a broad temporary group membership. When a managed device is moved to another OU, re-evaluate inherited policy and readers before move is complete. This checks both identity design and operational reality without exposing password values.
Prove nested-principal boundaries
Test the permission model against nested groups, not only named LAPS reader groups. For a controlled test OU, place Helpdesk-Regional inside LAPS-Readers-Workstations; grant the latter read access with Set-LapsADReadPasswordPermission -Identity 'OU=Workstations,DC=example,DC=com' -AllowedPrincipals 'LAPS-Readers-Workstations'. Query access using a member of the nested group, then remove that nesting and confirm retrieval is denied. Separately test an account granted reset permission but no read permission. Capture ACL export, group expansion, Windows LAPS event reference, expiry before and after rotation, and the ticket reference; never capture password output. This exposes indirect retrieval paths that a flat group listing misses.