Windows LAPS and the migration from Microsoft LAPS

- Diesen Artikel auf Deutsch lesen. -
cec9300638ff469ea6e31be6bcec0707 Windows LAPS and the migration from Microsoft LAPS 3

In this era, the topic of IT security is becoming more and more important. A possible attack vector has always been the local admin passwords. In most cases, these were hard-wired into the installation image and had not been changed for years. Not only a risk from former employees. The lateral movement also poses a risk. In this case, the attacker jumps from one system to another and uses the captured account to move from computer to computer. Such an attack can be carried out via local administrator accounts, for which the same password is often used on several systems. Attackers who obtain such a password or token can then impersonate an administrator and access other systems. There they can spy on data, install malware and work their way further. This could also have been a possibility in the 2015 German parliamentary hack.

Read more: Windows LAPS and the migration from Microsoft LAPS

Many companies already used group policies to change local passwords regularly. Unfortunately, the new passwords were stored there in plain text, which forced Microsoft to take action and disable this option in May 2014. There is also an old KB article KB2962486 / MS14-025.

To solve this problem, Microsoft made LAPS available on 1 May 2015. The first version started with the version number (6.0 matching the operating system version). I wrote a first article on the topic of “Local Administrator Password Solution (LAPS)” in 2017.

Looking back, what is Microsoft Local Administrator Password Solution (LAPS)?

With the Local Administrator Password Solution (LAPS), the passwords of a local account are automatically changed and stored in the Active Directory. This is realized by a Client Side Extension (CSE) and an Active Directory Schema Extension. Only after a successful change in the Active Directory is the password changed on the computer. Through Active Directory permissions on the AD attributes being used, it was not only possible to ensure who could read the passwords, but it was also possible to log in with Active Directory who had access. I used this possibility in combination with WinRM (via HTTPs) to execute scripts remotely as a local admin and have the password changed directly afterwards. This way I didn’t have to log in with a domain user with admin rights. In addition, it is directly visible in the EventLog in which period I knew the password of the account. This ensures that it is traceable who worked with the non-personalized account (German IT Basic Protection OPS.1.1.2 Proper IT Administration).

But there were also downsides to LAPS:

  • No password history (especially when restoring old backups, it could be exciting if the computer’s password had changed and thus the login to the domain no longer worked).
  • Required a local Active Directory and a connection to it (VPN could also be a problem depending on GPO settings). No support for AzureAD.
  • Passwords are in plain text in the AD and are only protected by the Access Control List (ACL).
  • When deployed on a domain controller, the “Administrator” account is handled in the domain. Who thinks this is an advantage… “On which of the 20 DCs was the password last set?”

Windows LAPS – An Overview

Windows LAPS is a further development of LAPS. It was released with the following April updates:

  • Windows 10 (21H2 and 22H2) KB5025221
  • Windows 11 (22H1) KB5025224
  • Windows 11 (22H2) KB5025239
  • Windows Server 2019 KB5025229 (Also Windows 10 Enterprise LTSC 2019)
  • Windows Server 2022 KB 5025230

Other versions are not supported, these still rely on legacy Microsoft LAPS, more on this later.

Since Windows LAPS has been completely redesigned, there are some new functions. Among others, is the use of AzureAD as a target storage (currently still in a preview version). In the on-premise world, the Directory Services Restore Mode (DSRM) password can now also be managed and backed up by domain controllers. The later is needed in the event of an Active Directory restore or extreme problems with a domain controller. Like all local passwords, this one should be individual and changed regularly. Most of the time it is fixed in a script and remains the same since the script was created.

Other new features include the ability to encrypt the password and the ability to automatically change the password after use. What was also an issue for many, was the password history, which can now contain up to 12 passwords. But one of the most important changes is that it is now natively included in Windows. There is no longer a need to distribute a DLL or MSI file to install LAPS.

For administrators, there are also some changes, such as new group policies and new AD schema attributes for compatibility reasons.


Some functions also have their own requirements, so for encrypted passwords the domain function level must be raised to Windows Server 2016 (a.k.a. WinThreshold). For this purpose, Microsoft uses the “Data Protection API”.

And for the daily work as an administrator, there is a new PowerShell model and a new tab for LAPS in the “Active Directory Users and Computers” console. There is also a separate event log channel for the new Laps.

The Way from Microsoft (Legacy) LAPS to Windows LAPS

Microsoft recommends that all customers migrate to the new solution, but there are some obstacles.

Firstly, Microsoft has built in a legacy mode, then the new Windows LAPS client behaves like the old Microsoft LAPS client. This includes the way passwords are stored. This is intended for companies that need some time to make the transition. However, there are a few things to keep in mind:

  • Microsoft LAPS must not be installed, otherwise, Windows LAPS is automatically deactivated.
  • All the old functions and methods as well as the legacy client or the legacy PowerShell module and the new PowerShell module for reading passwords are available.
  • This is only intended for a transitional phase, i.e. until the old client has been removed everywhere.
  • After installing the update, the legacy Microsoft LAPS can no longer be installed correctly. The software distribution or deployment of LAPS must therefore be adapted accordingly.

For this article I assume the following scenario: the updates with Windows LAPS have not yet been rolled out. In principle, however, the article is also suitable for environments that have already rolled out the updates, only some steps are not needed and the order can be changed if needed. Windows Server 2022 is used as the operating system. The Functional Level and Forrest Functional Level areas are both on Windows Server 2016, which is the highest version currently available.


First the environment is prepared for Windows LAPS, then the devices are migrated and then the separate organisational units are migrated to Windows LAPS.

Here are the steps in the correct order:

  1. Check that legacy LAPS works as expected on all computers.
  2. Roll out update with Microsoft LAPS (already done inadvertently for some).
  3. Update Group Policy Templates (ADMX).
  4. Disable Legancy Microsoft LAPS distribution.
  5. check that Windows LAPS is correctly installed and disabled
  6. Uninstalling Legacy Microsoft LAPS
  7. Checking if Windows LAPS is running in Legacy mode
  8. Switch group policies from Legacy LAPS to Windows LAPS

Preparations for the migration to Windows LAPS

Customise the Active Directory Schema

To be able to switch to Windows LAPS later, the Microsoft Active Directory must first be modified. In order to have the necessary files and PowerShell modules, a server must be updated to the latest version.

Afterward, the corresponding Powershell module “LAPS” is available on the server.

The following steps must be carried out in PowerShell with administrative rights. In this case, I perform the steps directly on the domain controller that also holds the FSMO role of Schema Master.

Execute the command “Update-LapsADSchema”. This will make the necessary changes to the AD schema for Windows Laps.

Importing the group policy template into the Central Store

The update on the server also updates the local templates for the group policies. These are located in the folder “C:\Windows\PolicyDefinitions”.

20230809 WindowsLAPS 01 Windows LAPS and the migration from Microsoft LAPS 5

The easiest way to do this is with PowerShell:

Get-ChildItem -Path "C:\Windows\PolicyDefinitions" -Filter "Laps.adm*" -Recurse | ForEach-Object 
  $destination = $_.FullName.Replace("C:\Windows\PolicyDefinitions", "C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions")
  $destinationDir = Split-Path -Path $destination -Parent
  if (!(Test-Path -Path $destinationDir)) { New-Item -ItemType Directory -Path $destinationDir | Out-Null }
  Copy-Item -Path $_.FullName -Destination $destination

If the GPO templates are outdated, it is recommended to update them completely. For more information on the various group policy templates, read the article List of various group policy templates. There you will also find group policy templates from various other manufacturers such as Google, Adobe, Mozilla and many others.

Checking the Legacy LAPS before switching to Legacy Mode with Windows LAPS

Before starting the migration, it should be checked if the legacy LAPS is working correctly. This can be checked most easily with PowerShell. To do this, the Legacy LAPS PowerShell module must be installed on the computer and the user must have the appropriate rights to have the LAPS passwords displayed.

The command is:

Get-AdmPwdPassword -ComputerName * | ft -AutoSize
20230809 WindowsLAPS 02 Windows LAPS and the migration from Microsoft LAPS 7

Attention: If the domain controllers also have a password, then the password of the domain user “Administrator” has been changed, as there are no local user accounts on domain controllers.

After the installation of Microsoft LAPS

After the update with Microsoft LAPS, the behaviour of LAPS changes. After the update there is a new EventLog “Microsoft-Windows-LAPS”. This EventLog can be called up with the following PowerShell command:

get-winevent -ProviderName Microsoft-Windows-LAPS -MaxEvents 10 | ft -AutoSize

The EventLog of the Legacy LAPS can be called with the following PowerShell command:

get-winevent -ProviderName AdmPwd -MaxEvents 10 | ft -AutoSize

Control via Legacy LAPS GPO

If a password change is now initiated via the Legacy LAPS, the procedure depends on whether the Legacy LAPS is still installed. However, the end result is the same.

Events with Legacy LAPS installed

When the Legacy LAPS is installed, it is the leading system. The Windows LAPS sits back and watches. You can read about the exact background procedure for the Microsoft LAPS in my article “Local Administrator Password Solution (LAPS)“.

The AdmPwd log contains the usual entries, the Legacy LAPS works normally.

20230809 WindowsLAPS 03 Windows LAPS and the migration from Microsoft LAPS 9

In the new LAPS event log, there is an entry with the event ID 10033 and the message “The machine is configured with legacy LAPS policy settings but a legacy LAPS product appears to be installed. The configured account’s password will not be managed by Windows until the legacy product is uninstalled. Alternatively you may consider configuring the newer LAPS policy settings.”. Which is exactly what is expected.

20230809 WindowsLAPS 04 Windows LAPS and the migration from Microsoft LAPS 11

Events after uninstalling Legacy LAPS

After uninstalling, the old event log is no longer available.

20230809 WindowsLAPS 05 Windows LAPS and the migration from Microsoft LAPS 13

The new log shows how the new LAPS works in Leagcy mode.

20230809 WindowsLAPS 06 Windows LAPS and the migration from Microsoft LAPS 15

In both cases, the passwords are changed.

20230809 WindowsLAPS 07 Windows LAPS and the migration from Microsoft LAPS 17

With the new PowerShell module for Windows LAPS, the passwords of the legacy Microsoft LAPS can also be queried.

20230809 WindowsLAPS 08 Windows LAPS and the migration from Microsoft LAPS 19

EventIDs of Windows LAPS

For a better understanding of the event logs of Windows LAPS, here are the most important event IDs.

Here is the updated table:

10003Marks the start of a background policy processing cycle.
10004Marks the successful end of a background policy processing cycle.
10005Marks the failed end of a background policy processing cycle.
10018Logged when Windows LAPS has successfully updated the on-premise Active Directory with a new password.
10020Logged when Windows LAPS has successfully updated the managed local account.
10021Logged when the policy is configured to secure the password in the on-premise Active Directory.
10022Logged when the policy is configured to secure the password in Azure Active Directory.
10023Logged when Windows LAPS is configured to use a legacy Microsoft LAPS policy.
10029Logged when Windows LAPS has successfully updated the Azure Active Directory with a new password.
10031Logged when an attempt to change the password has been blocked.
10041Logged when successful authentication is detected for the specified managed account.
10042Logged when the time limit listed in event 10041 is reached.
10043Logged when password rotation fails.
10044Logged when password rotation is successful.

Uninstalling Legacy Microsoft LAPS

The legacy Microsoft LAPS is installed under “C:\Program Files\LAPS\CSE”. The installation depends on whether LAPS was installed as an MSI or whether the DLL was copied and registered elsewhere.

If it was installed as an MSI package, it can simply be uninstalled with the PowerShell command:

.\msiexec.exe /x (get-wmiobject Win32_Product | ? { $_.Name -like "Local Administrator Password Solution" -and $_.Vendor -like "Microsoft Corporation"}).IdentifyingNumber /Q

If the DLL was registered manually, the following PowerShell commands will help:

.\regsvr32.exe /s /u "C:\Program Files\LAPS\CSE\AdmPwd.dll"Remove-Item "C:\Program Files\LAPS" -Recurse -Force

Switching to Windows LAPS Policy

A few things must be prepared for the migration. In order for the LAPS PowerShell modules to be available, the update and thus Windows LAPS must be installed. In addition to updating the group policy templates, the Active Directory schema must also be updated.

Commands in the Windows LAPS PowerShell module

The PowerShell module is available as soon as Windows LAPS is installed with the update. A subsequent installation for older management platforms is not intended and is not supported.

Windows LAPS CmdletLegacy Microsoft LAPS CmdletDescription (Windows LAPS)
Find-LapsADExtendedRightsFind-AdmPwdExtendedRightsUsed to find out which identities have been granted permissions for an organisational unit (OU) in the on-premise Active Directory.
Get-LapsAADPasswordNot applicableUsed to search the Azure Active Directory for Windows LAPS passwords.
Get-LapsADPasswordGet-AdmPwdPasswordUsed to search the on-premise Active Directory for Windows LAPS passwords.
Get-LapsDiagnosticsNot applicableUsed to collect diagnostic information to investigate problems.
Invoke-LapsPolicyProcessingNot applicableUsed to start a policy editing cycle.
Reset-LapsPasswordNot applicableUsed to initiate immediate password rotation. Used only when the password is stored in either Azure Active Directory or On-Premise Active Directory.
Set-LapsADAuditingSet-AdmPwdAuditingUsed to configure Windows LAPS-related monitoring of OUs in the on-premise Active Directory.
Set-LapsADComputerSelfPermissionSet-AdmPwdComputerSelfPermissionUsed to configure an OU in the on-premise Active Directory to allow computer objects to update their Windows LAPS passwords.
Set-LapsADPasswordExpirationTimeReset-AdmPwdPasswordUsed to update the validity period of a computer’s Windows LAPS password in the on-premise Active Directory.
Set-LapsADReadPasswordPermissionSet-AdmPwdReadPasswordPermissionUsed to grant permission to read the Windows LAPS password information in the on-premise Active Directory.
Set-LapsADResetPasswordPermissionSet-AdmPwdResetPasswordPermissionUsed to grant permission to update the validity period of the Windows LAPS password in the on-premise Active Directory.
Update-LapsADSchemaUpdate-AdmPwdADSchemaUsed to extend the on-premise Active Directory schema with Windows LAPS schema attributes.

Updating the AD scheme

The PowerShell command “Update-LapsADSchema” must be executed. The user who executes the command must belong to the Schema Admins group.

20230809 WindowsLAPS 09 Windows LAPS and the migration from Microsoft LAPS 21

After updating the scheme, the group policy can also be configured.

20230809 WindowsLAPS 10 Windows LAPS and the migration from Microsoft LAPS 23

There are other ways to increase security, e.g. encrypting the passwords before saving them and protecting them with an AD group. This way, only this group can decrypt the passwords. To increase security even further, a restart can also be forced after the administrator account has been used, so that there are no more open sessions or active tokens.

Updating the permission for the computers

So that the computer accounts also have the necessary permissions, these must be set with the command “Set-LapsADComputerSelfPermission”. An individual organisational unit (OU) or the entire domain can be entered here.

20230809 WindowsLAPS 11 Windows LAPS and the migration from Microsoft LAPS 25

Setting the permission to read the passwords

In addition, the permission to read the passwords must be set at OU level. This is done with the command “Set-LapsADReadPasswordPermission”.

20230809 WindowsLAPS 12 Windows LAPS and the migration from Microsoft LAPS 27

This is not the password encryption mentioned in the previous chapter.

Reading out passwords after migration

After setting the group policy and after setting the computer permission, the Windows LAPS takes over, even if the Legacy LAPS is still installed.

20230809 WindowsLAPS 13 Windows LAPS and the migration from Microsoft LAPS 29

The device looks like this when the legacy LAPS is still installed.

20230809 WindowsLAPS 14 Windows LAPS and the migration from Microsoft LAPS 31

Nevertheless, the Legacy LAPS should be uninstalled, otherwise problems may occur. Also, if a new policy exists, the Windows LAPS will overwrite the Legacy LAPS.

20230809 WindowsLAPS 15 Windows LAPS and the migration from Microsoft LAPS 33

Nevertheless, the Legacy LAPS enters a password in the Active Directory attribute. However, the valid password is the Windows LAPS.

20230809 WindowsLAPS 16 Windows LAPS and the migration from Microsoft LAPS 35

In the Attribute Editor we can see that the legacy LAPS has entered the values in AD, but the local change has been prevented.

20230809 WindowsLAPS 17 Windows LAPS and the migration from Microsoft LAPS 37

Domain Controller and the Directory Service Recovery Mode with Windows LAPS

20230809 WindowsLAPS 18 Windows LAPS and the migration from Microsoft LAPS 39

If Directory Service Recovery Mode (DSRM) doesn’t mean anything to you, I recommend a look at the background article “Active Directory Service Recovery Mode (DSRM)“.

The old LAPS, when running on a domain controller, changed the password of the domain user “Administrator”. The new LAPS is smarter. It automatically changes the DSRM password on a domain controller even without the corresponding parameter, which corresponds most closely to a local administrator. The important thing here is that the domain functional level is at least 2016 and the domain controllers are running at least on Windows Server 2019.

DSRM also populates the password history if enabled. The password history is particularly important in conjunction with restoring from a backup and should be enabled. To display the password history, the parameter “-IncludeHistory” can be used in the Get-LAPSADPassword command.

This also ensures that the DSRM passwords are changed regularly.


When it comes to the Local Administrative Password Solution (LAPS), it is important to know when which setting/version is actually active and how.

Legacy LAPS Policy onlyNew LAPS Policy onlyBoth LAPS Policy
Only Legacy LAPS installedLegacy LAPSInactiveLegacy LAPS
Both LAPS installedLegacy LAPSNew LAPSNew LAPS *
Only Windows LAPS installedNew LAPS (Legacy Mode)New LAPSNew LAPS

* Both are active and write the changes to your AD attribute, but only the new LAPS can change it locally. Parallel operation is only officially supported if the two LAPS variants manage different accounts.

Since conflicts may occur, the old Microsoft LAPS should be uninstalled before migration to the new Windows LAPS policy.

My personal conclusion is that the functions that I have always missed have finally been added. Especially the history is indispensable when restoring from a backup. I also like the fact that the DSRM password is now changed on the domain controllers and no longer that of the domain account “Administrator”.

I think the integration into Azure AD is good in perspective, but I haven’t looked at it in detail yet.

Leave a comment