Windows LAPS and Local Administrator Membership Audit Lab

Expected Outcome

A lab Windows device receives a Windows LAPS-managed local administrator password through the supported directory policy path, an authorized operator can retrieve it, and a separate audit reports unexpected local Administrators-group membership without changing access automatically.

Assumptions

• A Windows LAPS-capable Windows client/server and supported AD DS or Entra-backed lab design

• Permission to configure the lab LAPS policy and delegated password retrieval

• A dedicated test device/OU or policy scope

• PowerShell access to query local group membership

• A documented emergency recovery path before changing local administrator policy

Bill of Materials

• Windows operating system

• PowerShell ISE or any text editor for scripting

• Access to a domain controller (if applicable)

Build Steps

1. Define the supported password-management architecture

   Use Windows LAPS as the authority for password generation, storage, rotation, access control, and retrieval. Do not create a scheduled script that changes a password without a secure durable retrieval system.

2. Configure LAPS only in the lab scope

   Apply the supported Windows LAPS policy to the test device/OU, define the managed account and rotation settings, and delegate password-read rights only to the test admin group.

3. Prove rotation and authorized recovery

   Trigger or wait for policy processing, verify LAPS status/event evidence, retrieve the password as an authorized operator, and prove an unauthorized test identity cannot retrieve it. Use the password once through an approved local recovery/login test.

4. Collect local Administrators membership read-only

   Use Get-LocalGroupMember or an approved remote method to collect local Administrators membership into structured objects with computer, member, SID/source, and timestamp. Do not remove members automatically.

5. Compare membership with an approved baseline

   Use an explicit expected group/account list for the lab and report Added/Expected/Missing states. Resolve domain groups separately when effective nested membership is relevant instead of treating display-name strings as complete authorization evidence.

6. Exercise drift and recovery

   Add a disposable test account/group to local Administrators, confirm the audit flags it, remove it through the approved admin path, and confirm the report returns to baseline. Separately verify the LAPS password remains retrievable after rotation.

Validation

• Windows LAPS—not a homemade script—owns local password generation/storage/rotation

• Authorized password retrieval works and unauthorized retrieval is denied

• The recovery login path works with the currently managed credential

• Local Administrators membership audit reports a seeded unexpected member

• The audit does not remediate membership automatically

• Password-management evidence and privilege-membership evidence remain separate in the report

Troubleshooting

• LAPS failure: inspect policy application, directory schema/permissions, device events, and managed-account configuration before forcing repeated rotations

• Membership query failure: report Unknown with the target error rather than assuming no administrators

• Never log or export the managed local administrator password in the drift report

Cleanup or Rollback

• Remove the seeded drift account/group

• Remove lab-only LAPS policy/delegation if dismantling the exercise

• Do not copy retrieved LAPS credentials into notes or source control

Next Improvements

• Implement logging for both scripts to track changes and actions taken.

• Consider integrating with a centralized logging solution for better monitoring.

• Explore additional features such as email notifications on password changes or audit results.