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 LAPSMany 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.1.0 (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:
- Check that legacy LAPS works as expected on all computers.
- Roll out update with Microsoft LAPS (already done inadvertently for some).
- Update Group Policy Templates (ADMX).
- Disable Legancy Microsoft LAPS distribution.
- check that Windows LAPS is correctly installed and disabled
- Uninstalling Legacy Microsoft LAPS
- Checking if Windows LAPS is running in Legacy mode
- 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”.
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
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 -AutoSizeThe EventLog of the Legacy LAPS can be called with the following PowerShell command:
get-winevent -ProviderName AdmPwd -MaxEvents 10 | ft -AutoSizeControl 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.
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.
Events after uninstalling Legacy LAPS
After uninstalling, the old event log is no longer available.
The new log shows how the new LAPS works in Leagcy mode.
In both cases, the passwords are changed.
With the new PowerShell module for Windows LAPS, the passwords of the legacy Microsoft LAPS can also be queried.
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:
| EventID | Description |
|---|---|
| 10003 | Marks the start of a background policy processing cycle. |
| 10004 | Marks the successful end of a background policy processing cycle. |
| 10005 | Marks the failed end of a background policy processing cycle. |
| 10018 | Logged when Windows LAPS has successfully updated the on-premise Active Directory with a new password. |
| 10020 | Logged when Windows LAPS has successfully updated the managed local account. |
| 10021 | Logged when the policy is configured to secure the password in the on-premise Active Directory. |
| 10022 | Logged when the policy is configured to secure the password in Azure Active Directory. |
| 10023 | Logged when Windows LAPS is configured to use a legacy Microsoft LAPS policy. |
| 10029 | Logged when Windows LAPS has successfully updated the Azure Active Directory with a new password. |
| 10031 | Logged when an attempt to change the password has been blocked. |
| 10041 | Logged when successful authentication is detected for the specified managed account. |
| 10042 | Logged when the time limit listed in event 10041 is reached. |
| 10043 | Logged when password rotation fails. |
| 10044 | Logged 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 /QIf 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 -ForceSwitching 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 Cmdlet | Legacy Microsoft LAPS Cmdlet | Description (Windows LAPS) |
|---|---|---|
| Find-LapsADExtendedRights | Find-AdmPwdExtendedRights | Used to find out which identities have been granted permissions for an organisational unit (OU) in the on-premise Active Directory. |
| Get-LapsAADPassword | Not applicable | Used to search the Azure Active Directory for Windows LAPS passwords. |
| Get-LapsADPassword | Get-AdmPwdPassword | Used to search the on-premise Active Directory for Windows LAPS passwords. |
| Get-LapsDiagnostics | Not applicable | Used to collect diagnostic information to investigate problems. |
| Invoke-LapsPolicyProcessing | Not applicable | Used to start a policy editing cycle. |
| Reset-LapsPassword | Not applicable | Used to initiate immediate password rotation. Used only when the password is stored in either Azure Active Directory or On-Premise Active Directory. |
| Set-LapsADAuditing | Set-AdmPwdAuditing | Used to configure Windows LAPS-related monitoring of OUs in the on-premise Active Directory. |
| Set-LapsADComputerSelfPermission | Set-AdmPwdComputerSelfPermission | Used to configure an OU in the on-premise Active Directory to allow computer objects to update their Windows LAPS passwords. |
| Set-LapsADPasswordExpirationTime | Reset-AdmPwdPassword | Used to update the validity period of a computer’s Windows LAPS password in the on-premise Active Directory. |
| Set-LapsADReadPasswordPermission | Set-AdmPwdReadPasswordPermission | Used to grant permission to read the Windows LAPS password information in the on-premise Active Directory. |
| Set-LapsADResetPasswordPermission | Set-AdmPwdResetPasswordPermission | Used to grant permission to update the validity period of the Windows LAPS password in the on-premise Active Directory. |
| Update-LapsADSchema | Update-AdmPwdADSchema | Used 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.
After updating the scheme, the group policy can also be configured.
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.
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”.
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.
The device looks like this when the legacy LAPS is still installed.
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.
Nevertheless, the Legacy LAPS enters a password in the Active Directory attribute. However, the valid password is the Windows LAPS.
In the Attribute Editor we can see that the legacy LAPS has entered the values in AD, but the local change has been prevented.
Domain Controller and the Directory Service Recovery Mode with Windows LAPS
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.
Conclusion
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 only | New LAPS Policy only | Both LAPS Policy | |
|---|---|---|---|
| Only Legacy LAPS installed | Legacy LAPS | Inactive | Legacy LAPS |
| Both LAPS installed | Legacy LAPS | New LAPS | New LAPS * |
| Only Windows LAPS installed | New LAPS (Legacy Mode) | New LAPS | New 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.
