Local administrator accounts are one of the easiest targets in a Windows domain. If every workstation shares the same local admin password (or if passwords are rarely rotated), a single compromised machine can quickly turn into lateral movement across the network. Microsoft’s solution is Windows LAPS (Local Administrator Password Solution), which automatically generates unique, random local admin passwords per device and stores them securely in Active Directory (or Azure AD/Entra in cloud scenarios). This guide focuses on deploying modern Windows LAPS in an on-prem Active Directory environment using Group Policy and PowerShell.
What You Need Before You Start
To follow this tutorial, you should have a domain-joined environment and permissions to modify Active Directory and Group Policy. Your clients should be on supported Windows versions (Windows 10/11 and modern Windows Server builds). You also need at least one management workstation or server where you can run PowerShell with the Active Directory module installed. If you previously used the legacy “Microsoft LAPS” MSI, note that Windows LAPS is built-in to newer Windows versions and uses different policies and cmdlets.
Step 1: Confirm Windows LAPS Is Available on Clients
On a target workstation, open PowerShell and verify you have access to LAPS cmdlets (exact availability depends on OS build). You can quickly check with:
Get-Command -Module Laps
If the module is not present on older builds, install the relevant Windows update or confirm the device is on a supported version. In most current enterprise builds, Windows LAPS is included and managed through Group Policy/MDM without installing extra software.
Step 2: Extend the Active Directory Schema for Windows LAPS
Windows LAPS stores password data in AD attributes. To add those attributes, extend the schema once per forest. On a management machine with appropriate rights (typically Schema Admins), run PowerShell as Administrator:
Update-LapsADSchema
After this completes, Active Directory will have the attributes needed to store the managed local admin password and its expiration time.
Step 3: Set Permissions for Who Can Read Passwords
By default, you should restrict password read access to a small set of helpdesk or server-admin groups. A practical approach is to grant read access to a dedicated security group (for example, “LAPS Password Readers”) on the OU that contains your computers.
Run the following from a machine with the AD module installed, adjusting the OU distinguished name and group name to match your environment:
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=example,DC=com" -AllowedPrincipals "EXAMPLE\\LAPS Password Readers"
You should also allow computers to write their own password to AD (often already covered, but it’s good to be explicit):
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=example,DC=com"
If you want to confirm permissions, use:
Find-LapsADExtendedRights -Identity "OU=Workstations,DC=example,DC=com"
Step 4: Create and Link a Group Policy for Windows LAPS
Open Group Policy Management, create a new GPO (for example, “Windows LAPS – Workstations”), and link it to the OU that contains the computers you want to manage. Then edit the GPO and configure Windows LAPS settings under:
Computer Configuration > Policies > Administrative Templates > System > LAPS
Recommended baseline settings for many organizations include:
Enable password backup: Set to Back up the password to Active Directory.
Password settings: Use a strong length (for example, 16–24) and enable complexity. Longer is better because users never have to type these passwords routinely; they retrieve them only when needed.
Password age (days): Choose a rotation period that fits your risk tolerance, such as 7–30 days for workstations and 1–7 days for privileged servers.
Managed account name: Decide whether you will manage the built-in local Administrator or a custom local admin account. Many teams prefer a custom local admin name to reduce guessability, but either approach can work when LAPS is properly enforced.
After configuring the GPO, run gpupdate /force on a test machine or wait for policy refresh.
Step 5: Validate That Passwords Are Being Stored in AD
Once the policy applies, the client should generate a new password and write it to AD. From your admin workstation, retrieve the password for a computer (example computer name: PC-041):
Get-LapsADPassword -Identity "PC-041"
If you only want to see basic fields (and avoid copying sensitive output), you can pipe to a format view. Also confirm the expiration time is present, which indicates rotation is scheduled.
Step 6: Force an Immediate Password Rotation (When Needed)
When a technician uses a local admin password for troubleshooting, a good practice is to rotate it immediately after the session. You can trigger a rotation by shortening the expiration time in AD. One way is to set the password to expire now and let the client rotate at next policy processing:
Reset-LapsPassword -Identity "PC-041"
Depending on your configuration and client behavior, you may also combine this with a policy refresh on the endpoint.
Common Troubleshooting Tips
Passwords are not appearing in AD: Verify the GPO is linked to the correct OU, the computer account is in that OU, and the device is actually receiving the LAPS policy (check Resultant Set of Policy). Also confirm the computer has permission to write its own LAPS attributes by rechecking Set-LapsADComputerSelfPermission.
Helpdesk can’t read passwords: Confirm the user is in the correct group and that group has read permission on the OU where the computer object lives. Remember that OU-level permissions won’t help if the computer is located somewhere else.
Rotation doesn’t happen on schedule: Ensure the device is online regularly, time is synchronized, and Group Policy refresh is working. Rotation depends on the endpoint being able to update AD.
Final Thoughts
Windows LAPS is one of those rare security improvements that is both powerful and practical: it reduces password reuse risk without adding daily friction for users. Start with a pilot OU, lock down who can read passwords, and document a simple helpdesk workflow for retrieving and rotating passwords. Once it’s stable, expand the policy to all workstations and then to servers with stricter rotation rules.
Comments
Post a Comment