In this post, I will show you how to setup Windows LAPS in Active Directory. Windows Local Administrator Password Solution (Windows LAPS) is a built-in Windows feature that automatically manages and backs up the password of a local administrator account on your domain-joined Windows devices. The password is randomly generated per device, rotated regularly, and stored securely in Active Directory (or Microsoft Entra ID, if you use the cloud scenario).
For Active Directory, Windows LAPS writes the password (and optionally password history and DSRM passwords) to new LAPS attributes on the computer object. Windows LAPS is built into modern Windows and gets updated via the standard Windows patching.
There is also a laps solution called as Microsoft LAPS which required a separate MSI package, and it was a bit limited in capability when compared with the modern LAPS solution. It didn’t support Password encryption or password history. Microsoft LAPS or the legacy laps solution is now deprecated.
If you are still using Microsoft LAPS solution, consider moving to Windows LAPS because Microsoft is no longer supporting the legacy LAPS and also not providing any new updates to it.
Domain functional level should be Windows Server 2016 or later (To support password encryption and DSRM password backup).
Schema Admins membership to extend the schema.
Domain Admin (or equivalent delegated rights) to configure OU permissions and GPOs.
Windows LAPS Operating System Support
It’s best to use the latest Windows 11 operating system for client devices and latest version of Windows server. Both the clients and servers should be fully updated with latest security updates. Windows LAPS also supports older operating systems as well. Below are the OS details for Windows LAPS support:
All domain controllers are fully patched with the Windows updates.
Devices you want to manage are domain-joined to the same Active directory.
Steps to Configure Windows LAPS
Now that you have confirmed your client and server operating systems are supported for implementing Windows LAPS, ensure that all domain controllers are also updated with the latest Windows security patches.
Step 1: Extend Active Directory Schema
For using Windows LAPS, you must update Windows Server Active Directory schema. Extending the AD schema applies the required changes to support Windows LAPS and adds the LAPS-related attributes to the device object. These attributes store values such as the LAPS password, password expiration date, encrypted password history, and more. I will show you all of these attributes after we extend the AD schema for LAPS.
To update the AD schema, you need to run Update-LapsADSchema on a domain controller by opening PowerShell in elevated mode (Run as administrator).
Open PowerShell console as an administrator on a domain controller.
Run get-command -module LAPS to check if the LAPS module is installed.
Get-Command -Module LAPS
PS C:\Users\Administrator.TP-DC-25-01> Get-Command -Module LAPS
CommandType Name Version Source ----------- ---- ------- ------ Function Get-LapsAADPassword 1.0.0.0 laps Function Get-LapsDiagnostics 1.0.0.0 laps Cmdlet Find-LapsADExtendedRights 1.0.0.0 laps Cmdlet Get-LapsADPassword 1.0.0.0 laps Cmdlet Invoke-LapsPolicyProcessing 1.0.0.0 laps Cmdlet Reset-LapsPassword 1.0.0.0 laps Cmdlet Set-LapsADAuditing 1.0.0.0 laps Cmdlet Set-LapsADComputerSelfPermission 1.0.0.0 laps Cmdlet Set-LapsADPasswordExpirationTime 1.0.0.0 laps Cmdlet Set-LapsADReadPasswordPermission 1.0.0.0 laps Cmdlet Set-LapsADResetPasswordPermission 1.0.0.0 laps Cmdlet Update-LapsADSchema 1.0.0.0 laps
Now, run Update-LapsADSchema command to update the AD schema. After you run this command, press A (Yes to All) to proceed. If the command is successful, there will be no output generated on the screen. If you get an error, it will be shown on the console.
Update-LapsADSchema
If you want to see the output of the Update-LapsADSchema command, use the -Verbose switch for detailed information. You can safely run this command again after extending the schema. It will not affect existing objects in the AD schema or attempt to update the schema again.
Update-LapsADSchema -verbose
VERBOSE: The 'CN=computer,CN=Schema,CN=Configuration,DC=corp,DC=techpress,DC=net' classSchema has the following mayContains: VERBOSE: msLAPS-CurrentPasswordVersion VERBOSE: msLAPS-EncryptedDSRMPasswordHistory VERBOSE: msLAPS-EncryptedDSRMPassword VERBOSE: msLAPS-EncryptedPasswordHistory VERBOSE: msLAPS-EncryptedPassword VERBOSE: msLAPS-Password VERBOSE: msLAPS-PasswordExpirationTime VERBOSE: msSFU30Name VERBOSE: nisMapName VERBOSE: msSFU30NisDomain VERBOSE: msSFU30Aliases VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-PasswordExpirationTime VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-Password VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-EncryptedPassword VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-EncryptedPasswordHistory VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-EncryptedDSRMPassword VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-EncryptedDSRMPasswordHistory VERBOSE: The 'computer' classSchema already has a required mayContain: msLAPS-CurrentPasswordVersion VERBOSE: The 'computer' classSchema already has all expected LAPS-related mayContains VERBOSE: VERBOSE: ProcessRecord completed VERBOSE: VERBOSE: EndProcessing started VERBOSE: EndProcessing completed
Step 2: Verify LAPS attributes in AD
After extending the AD schema, a few LAPS-related attributes are added to Active Directory (as seen in the verbose output of the Update-LapsADSchema command). Below is the list of attributes that are added to the AD schema when it is updated to support Windows LAPS.
ms-LAPS-PasswordExpirationTime
ms-LAPS-Password
ms-LAPS-EncryptedPassword
ms-LAPS-EncryptedPasswordHistory
ms-LAPS-EncryptedDSRMPassword
ms-LAPS-EncryptedDSRMPasswordHistory
ms-LAPS-CurrentPasswordVersion
To check and confirm these attributes, follow the steps below:
Right-click a device object in Active Directory and select Properties.
Go to the Attribute Editor tab and scroll down to find the LAPS attributes.
You will also see a LAPS tab, which an administrator can use to view the LAPS password, set the password expiration, check the LAPS password account name, and review the password expiration details. These values will be populated once Windows LAPS is fully configured.
If you do not see the Attribute Editor tab, open Active Directory Users and Computers, go to View, and select Advanced Features. Then reopen the device object’s Properties, and the Attribute Editor tab should appear.
Step 3: Grant Permissions to Computers
A managed device must have permission to update its own LAPS attributes in AD, including password information. We grant these permissions to an OU containing the computer objects by using the Set-LapsADComputerSelfPermission cmdlet. The permissions are inheritable, so any sub-OUs will automatically receive them.
In my Active Directory forest, I have an OU named Workstations that contains all of my client devices. I will use below command to grant the required permissions to the devices through this OU.
If the name of the OU is not unique, you must use the distinguishedName of the OU when applying the permissions. To get the distinguishedName, right-click the OU, open the Attribute Editor tab, and check the distinguishedName attribute.
Before creating a Group Policy to configure Windows LAPS, ensure that the required ADMX template files are available in C:\Windows\PolicyDefinitions or in the Central Store. My Central Store location is: \\corp.techpress.net\SYSVOL\corp.techpress.net\Policies\PolicyDefinitions. Replace the domain name with your domain to go to your organization’s central store.
If the ADMX file is present, LAPS settings will appear in Group Policy Management under: Computer Configuration > Policies > Administrative Templates > System > LAPS. Below screenshot shows LAPS.admx file under the PolicyDefinitions folder in my Central store.
To create a GPO, right-click the OU that contains your computers and select Create a GPO in this domain, and Link it here. Provide a name for the GPO. I have used CP_Windows LAPS. Since the configuration will be done under the Computer Configuration node, I have named the GPO with the prefix CP (Computer Policy).
Right-click on the newly created GPO and select Edit.
Go to Computer Configuration > Policies > Administrative Templates > System > LAPS, where you will find all the LAPS-related settings you can configure.
Below is the list of settings available to configure in the GPO:
Configure password backup directory
Password settings
Name of administrator account to manage
Do not allow password expiration time longer than required by policy
Enable password encryption
Configure size of encrypted password history
Configure password backup for DSRM accounts
Post-authentication actions
Configure authorized password decryptors
Configure automatic account management
I will configure the most essential and recommended LAPS settings. Let’s start with the policy Configure password backup directory, which specifies where the local administrator password will be stored. You can choose either Active Directory or Azure Active Directory (Entra ID). I will select Active Directory because I want the local administrator password to be stored in my on-premises Active Directory rather than in Entra ID.
Another policy I will configure is Password settings, which defines the password complexity for the local administrator account. When LAPS sets the password, it will use the complexity values you configure to generate the password.
The default password complexity settings are shown below, and you can adjust them based on your requirements. If you choose a very complex and extremely long password, it may become difficult for your admin or helpdesk teams to use during troubleshooting. Create a balanced password that offers strong security while remaining practical for support teams to use.
Another important setting I will configure is Configure automatic account management, which works with Windows 11 24H2 or later devices. This setting allows the automatic creation of a custom local administrator account on the target devices.
You can also use the drop-down under Specify the target account to manage and select Manage the built-in admin account. If you choose this option, it will not create a local admin account, because LAPS will automatically manage the built-in Administrator account.
In the screenshot below, I have specified tpadmin as the local administrator account that LAPS will manage. The tpadmin account will be created automatically on the target devices, so there is no need to create it manually or deploy it through a script.
Below screenshot shows the policies I have configured to enable LAPS in my environment. You can review the other available policies and configure them based on your requirements.
Confirm LAPS Policies
By default, Group Policy refreshes every 90 minutes, with a random offset of up to 30 minutes. This interval applies to both computer and user configuration settings. To speed this up, open Command Prompt or PowerShell as an administrator and run gpupdate /force. This forces the device to retrieve and apply any new or updated GPOs immediately.
You can easily modify group policy default refresh interval by using a setting called Set Group Policy refresh interval for computers. Similarly, for user configuration settings, utilize the Set Group Policy refresh interval for users setting. For more Information on modifying GPO refresh interval, refer to the link: How to Modify Group Policy Refresh Interval.
If you enable Configure automatic account management setting and specify a local admin account name that does not already exist, Windows LAPS will:
Automatically create that local account on the target machine.
Add it to the Administrators group.
Then manage its password according to your LAPS policy (password length, rotation interval, etc.)
If the account already exists, LAPS will simply take over password management for that account rather than creating a new one. In our example, I specified a custom local admin account named tpadmin. The LAPS automatic account management policy will check whether this account exists on the target computer. If it does not, LAPS will create it using the name you specified and add it to the Local Administrators group.
Previously, you had to pre-create a custom local admin account and then use the Name of administrator account to manage GPO setting. If the account did not already exist, the LAPS policies would fail to apply. Microsoft has now introduced Configure automatic account management, which allows the automatic creation of a local admin account on the target device. There is no need to create a local administrator account manually, through PowerShell scripts, or via GPO. Simply enable Configure automatic account management, specify the custom admin account name, and LAPS will provision it automatically.
Confirm LAPS Policies Windows 11 Client
First, let’s check whether the LAPS GPO has been applied to the target Windows 11 client devices, and then we will review the changes in Active Directory. Since we enabled Configure automatic account management and specified tpadmin as the custom local admin account name, we expect this account to be created on the target Windows 11 devices.
Sign in to one of the target Windows 11 device.
Open Computer management > System tools > Local Users and Groups > Users.
Check and confirm if the account you specified has been created.
Go to Computer management > System tools > Local Users and Groups > Groups.
Open the Administrators group to check and confirm whether the account has been added to the group.
Open Event Viewer > Applications and Services Logs > Microsoft > Windows > LAPS > Operational and review the event logs to locate your admin account and confirm whether LAPS has successfully updated the local administrator password. If there are any issues, this is the best place to start your investigation, as the event logs will include detailed information and error messages if something goes wrong.
I was able to fix one of the issues by reviewing the Event Viewer logs. The problem was that the LAPS local admin account was not being created. I will show you the log and explain how I resolved the issue in the Troubleshooting section of this post.
Confirm LAPS policies from Domain Controller
Another place to check whether the LAPS policies have been applied successfully is on the domain controller by reviewing the device object properties. Since we configured the LAPS GPO to store the local administrator password in Active Directory, the password should be synced from the Windows client and stored with the device object once the local admin account is created.
Sign in to the domain controller and Open Active directory users and computers.
Go the the OU containing computers and right-click on one of the Computer object > Properties > LAPS.
Under the LAPS tab, you will find various properties of the local administrator account that is being managed by the LAPS solution. Compare that to the screenshot of the LAPS tab we saw earlier, which did not contain any information.
Current LAPS password expiration: Shows the expiration date of the current LAPS password. After this date, the password will be rotated automatically and synced to the device.
Set new LAPS password expiration: Allows you to manually set a new expiration date or immediately expire the password if you believe it has been compromised.
LAPS local admin account name: Displays the name of the local admin account created and managed by LAPS.
LAPS local admin account password: Shows the password for the local administrator account. You can reveal it by selecting Show password, or use Copy password to copy it without displaying it, which can be useful from a security standpoint..
In the screenshot on the right, you can see the Attribute Editor tab. This tab displays the LAPS attributes where the actual LAPS configuration details are stored. The LAPS tab provides a simplified view by pulling this information from the underlying Active Directory schema attributes. You can use either location to review and manage LAPS-related information.
Manage LAPS with PowerShell
LAPS PowerShell module is built into modern Windows operating systems and provides a complete management toolkit. In this section, I will show some useful LAPS commands. For the full list of available commands, refer to: Windows LAPS PowerShell Cmdlets Overview | Microsoft Learn.
View the password of the LAPS managed local admin account
By default, when you run Get-LapsADPassword as a domain administrator, you will be able to view the password. However, other admins or helpdesk users will not be able to read or reset the password unless you grant them the required permissions.
Run below commands on a domain controller to provide read access or password reset permissions to AD security groups. Replace the group names with the ones you are using.
Grants the Helpdesk-LAPS-Readers group permission to read LAPS passwords for computers in the Workstations OU
Once you have configured the required LAPS permissions for the Helpdesk-LAPS-Readers and LAPS-Password-Resetters groups, you can view these permission assignments later by using the Find-LapsADExtendedRights cmdlet. Below command will list the users or groups that have been granted extended rights to manage LAPS.
Below command will enable auditing on the Workstations OU so that reads or resets of Windows LAPS password attributes on its computers are logged in the Security and Directory Service audit logs.
During the implementation of Windows LAPS, I encountered an issue where the local admin account was not being created automatically, even though the Configure automatic account management GPO setting was correctly configured and a custom local admin account name had been specified.
To investigate the issue, I checked the Event Viewer logs on the target device by navigating to Applications and Services Logs > Microsoft > Windows > LAPS > Operational. The error clearly showed that LAPS was unable to update the password because the computer could not write the password to its device object in Active Directory. The log also provided a command to resolve the issue.
If you recall from the earlier steps where we granted permissions to computers, I had missed running the Set-LapsADComputerSelfPermission command. Because of this, the computers did not have permission to update their LAPS password in AD. To fix the issue, I signed in to the domain controller and ran the command.
After assigning the correct permissions, the LAPS local admin account was created successfully on the Windows client, and the password was synced to Active Directory as expected.
LAPS received an LDAP_INSUFFICIENT_RIGHTS error trying to update the password using the LAPS password attribute. You should update the permissions on this computer's container using the Set-LapsADComputerSelfPermission cmdlet, for example:
Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=techpress,DC=net' See https://go.microsoft.com/fwlink/?linkid=2220550 for more information.
When reviewing the logs in Event Viewer, you will come across various LAPS-related event IDs. Below is a summary of these event IDs to help you quickly understand their purpose:
10003 – LAPS policy processing started
10004 – LAPS policy processing succeeded
10005 – LAPS policy processing failed
10006, 10012, 10017, etc. provide detailed root causes (for example schema not extended, DFL too low, or lack of permissions).
Event 10012 – schema not updated: Confirm Update-LapsADSchema was run and succeeded.
Event 10006 – password encryption required but DFL too low: Either raise DFL to 2016 or disable password encryption in policy.
No LAPS attributes visible in ADUC: Check schema extension, check you are using a DC or management server with updated LAPS DLLs and ADUC.
No password is stored: Check and confirm:
The device is in the OU that has the LAPS GPO linked.
Set-LapsADComputerSelfPermission was run on that OU.
The client can contact the DC and process Group Policy (gpresult /r)?
FAQs
Do I still need the old Microsoft LAPS MSI? No. For supported OS versions, Windows LAPS is native and you should not install the legacy MSI on new systems. Legacy LAPS is deprecated on newer OS versions such as Windows 11 25H2.
Can I back up passwords to both AD and Entra ID at the same time? No. A device can back up its password either to AD or to Entra ID, not both. Hybrid-joined devices can be configured to use either repository.
Does Windows LAPS require extra licensing for AD? No. Backing up to on-prem AD has no extra license cost. Entra-backed passwords require at least a Microsoft Entra ID Free license.
Can Windows LAPS manage more than one local account per device? The policy targets a single managed account name per device. If you need more accounts, you typically standardize on one LAPS-managed admin account and remove other local admins.
Is password encryption in AD mandatory? By default Windows LAPS assumes encryption for AD storage, and that requires a domain functional level of 2016 or higher. You can configure the policy to store passwords unencrypted if you are forced to run a lower DFL, but this is not recommended.
Is there any other way to configure Windows LAPS? Yes, you can configure Windows LAPS using Intune as well. Refer to this step-by-step guide for implementation steps: Setup Windows LAPS with Intune: A Comprehensive Guide.
