Windows LAPS in Active Directory: A Step-by-Step Setup Guide

Windows LAPS is the Microsoft solution for managing the local administrator password on domain-joined Windows devices: it gives every device its own password, rotates it regularly and stores it securely in Active Directory for authorized administrators. This guide covers an on-premises Active Directory deployment: schema preparation, OU permissions, Group Policy configuration, PowerShell validation and basic troubleshooting.

Goal and scope

The goal is to stop the same local administrator password from being used on many devices and to restrict who can read those passwords. The guide focuses on deploying Windows LAPS with Windows Server Active Directory.

Prerequisites

• Current Windows client or Windows Server versions that support Windows LAPS
• An Active Directory Domain Services environment
• Access to Group Policy Management
• Permissions to update the schema and configure OU permissions
• A management system where the Windows LAPS PowerShell module is available

Note: In production, validate on a limited pilot OU first instead of rolling out to all devices at once.

Windows LAPS vs. legacy LAPS

Windows LAPS is Microsoft’s current LAPS implementation and is built into modern Windows versions. The older Microsoft LAPS product uses a separate MSI installation and legacy schema attributes. For new deployments, prefer Windows LAPS wherever possible.

1. Prepare the Active Directory schema

Before using Windows LAPS with Active Directory, add the required LAPS schema attributes. This is done once per forest.

Update-LapsADSchema -Verbose

When the command completes, the schema attributes Windows LAPS needs are added to Active Directory.

2. Let managed devices write to the OU

Computer accounts must be able to update their own LAPS data in the OU where they are located. Example:

Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=contoso,DC=com"

The distinguished name is an example; replace it with your own OU.

3. Restrict who can read passwords

Keep the users and groups that can read LAPS passwords as narrow as possible. A dedicated permission group reduces dependence on broad privileged groups.

Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=contoso,DC=com" -AllowedPrincipals "CONTOSO\LAPS-Password-Readers"

After granting the permission, it is good practice to check separately which principals hold extended rights on the OU.

4. Configure Windows LAPS with Group Policy

In a new or existing GPO, open:

Computer Configuration > Administrative Templates > System > LAPS

For a basic configuration, review at least these settings:

• Configure password backup directory: Active Directory
• Password Settings: password length, complexity and age
• Name of administrator account to manage: set this if you manage a custom local administrator account instead of the built-in one
• Enable password encryption: enable it if your Active Directory environment supports it (it requires the Windows Server 2016 domain functional level)
• Configure authorized password decryptors: explicitly define the principal that can decrypt encrypted passwords

Link the GPO to the pilot OU first. Widen the scope after you have confirmed that the policy is applied correctly.

5. Apply the policy on the client

On a test device, refresh Group Policy:

gpupdate /force

Instead of waiting for the next Windows LAPS processing cycle, you can trigger policy processing with PowerShell:

Invoke-LapsPolicyProcessing

6. Verify the password with PowerShell

From an authorized management session, query the LAPS data for a specific computer:

Get-LapsADPassword -Identity "PC01" -AsPlainText

PC01 is an example computer name. Use -AsPlainText only when you really need it, and only in authorized management sessions.

7. Rotate the password immediately

If the managed local account password on a device has to be changed urgently, use Reset-LapsPassword on that device:

Reset-LapsPassword

This makes Windows LAPS on the local device rotate the password immediately. Do not use it as part of normal operations; keep it for security incidents or controlled tests.

Validation

Do not judge the deployment only by whether the GPO arrived. Check these together:

• Confirm that the client received the target GPO.
• Check the Windows LAPS event log (Applications and Services Logs → Microsoft → Windows → LAPS → Operational).
• Confirm that LAPS data was created on the computer account.
• Test that the authorized group can read the password and an unauthorized account cannot.
• Confirm that the value changes after a password rotation.

Common problems and troubleshooting

The schema is updated but no password is created

First make sure the device is in the correct OU, the GPO is actually applied, and the computer account has the required self-permission on the OU.

Get-LapsADPassword returns an access error

Check that the querying account has read permission on the OU. If passwords are encrypted, read permission alone may not be enough; the account must also be an authorized password decryptor.

The policy arrives but changes do not show up

After gpupdate /force, run Invoke-LapsPolicyProcessing and review the Windows LAPS event log.

Confusion with legacy LAPS

Legacy Microsoft LAPS and Windows LAPS use different schema attributes and management components. In a migration, do not deploy old and new policies together before you know which clients use which LAPS model.

Security and best practices

• Grant LAPS password read permission to a separate, limited security group.
• Follow least privilege instead of giving the permission to broad administrator groups.
• Use password encryption where your AD environment supports it.
• Make LAPS events and password read operations auditable.
• Do the first deployment on a pilot OU.
• Standardize which local administrator account is actually managed.
• Document schema and OU permission changes as part of change management.
• Do not save Get-LapsADPassword -AsPlainText output to logs, screenshots or shared files.

The schema update affects the whole forest and needs authorization and a change plan. Adapt the example OU and group names to your own environment, and do not roll out to production OUs until client support and the LAPS event logs have been verified.

Conclusion

Windows LAPS is one of the basic security controls in Active Directory environments: it makes local administrator passwords unique per device and manages them centrally. Creating a GPO alone is not enough; schema preparation, OU permissions, password read permissions, validation and the event logs have to be handled together.

Related guides

• Group Policy Not Applying? A Step-by-Step GPO Troubleshooting Guide
• Active Directory DNS and DC Locator Troubleshooting: Checking SRV Records
• Active Directory Replication Errors: Troubleshooting with Repadmin and DCDiag
• Windows LAPS with Intune, GPO and Entra ID (Turkish)
• Microsoft Learn: Windows LAPS overview
• Microsoft Learn: Windows LAPS with Windows Server Active Directory