In October 2022, I published a blog post titled The 10 most important details about the upcoming Windows LAPS solution, which revealed that Microsoft was developing a new LAPS solution called Windows LAPS. This solution would address the long-awaited support for cloud-only devices. As of April 11, 2023, Windows LAPS for Windows Server Active Directory is now publicly available. Previously, Windows LAPS was only accessible through private preview. Unfortunately, Windows LAPS for Azure Active Directory remains in private preview and is not open to new customers. However, the Azure Active Directory LAPS scenario is anticipated to enter public preview in Q2 2023. In this blog post, I will be sharing my initial testing impressions of Windows LAPS with the Windows Server Active Directory (on-premises) scenario.
- Supported platforms
- The advantages of Windows LAPS over Legacy Microsoft LAPS
- Windows LAPS for Windows Server Active Directory – Configuration
- Windows LAPS for Windows Server Active Directory – Admin Experience
- Conclusion
Supported platforms
When Microsoft first announced the new LAPS solution, it was not yet known exactly which operating systems would be supported by Windows LAPS in addition to Windows 11. The supported platforms have now been definitely announced:
- Windows 11 Pro, EDU, and Enterprise
- Windows 10 Pro, EDU, and Enterprise
- Windows Server 2022 and Windows Server Core 2022
- Windows Server 2019
The Local Administrator Password Solution (LAPS) developed in 2015 will still be available and supported. Microsoft now calls the former solution Legacy Microsoft LAPS.
The advantages of Windows LAPS over Legacy Microsoft LAPS
# Seamless integration
Without a doubt, the most significant benefit of Windows LAPS is its seamless integration with Windows. This eliminates the need for any additional installation steps, and consequently, there is no longer a requirement to distribute the LAPS MSI package.
# Password encryption
One of the shortcomings of the earlier version of LAPS was the storage of passwords in Active Directory in plain text format. Although it was feasible to limit the permissions on the LAPS password attributes, it remained a vulnerability. With Windows LAPS it is now possible to encrypt the passwords (AES-256). The only requirement is that the domain functional level is set to 2016.
# More New capabilities
Windows LAPS also offers many new features. Enclosed a complete overview:
| Windows LAPS for Azure Active Directory Features | Windows LAPS for Windows Server Active Directory |
|---|---|
| Store passwords in Microsoft Azure (on Azure device object) | New Group Policy object and AD schema attributes |
| Cloud-based management experience – Passwords retrieved via Microsoft Graph – Settings configuration via Microsoft Intune – On-demand password rotation via Microsoft Intune | Account name stored side-by-side with password |
| Automatic password reset on use (client-driven) | Automatic password reset on use (client-driven) |
| Support for password encryption (requires WS2016 DFL) | |
| Password history support for encrypted passwords | |
| Support for managing DSRM account passwords on domain controllers | |
| New PowerShell module | |
| New LAPS property page in AD User & Computers snap-in |
Windows LAPS for Windows Server Active Directory – Configuration
That’s enough of the introductory remarks. It’s time to evaluate Windows LAPS and its new features! 🙂 My test systems are each two Windows Server 2022 machines. 1x domain controller and 1x member server.
Windows LAPS Requirements
First of all, the Cumulative Update from April 11, 2023 (KB5025230) must be installed. This latest update integrates the Windows LAPS solution as a built-in Windows feature.
Be careful with this update if legacy LAPS is already in use:
The April 11, 2023 update has two potential regressions related to interoperability with legacy LAPS scenarios. Please read the following to understand the scenario parameters plus possible workarounds.
Issue #1: If you install the legacy LAPS CSE on a device patched with the April 11, 2023 security update and an applied legacy LAPS policy, both Windows LAPS and legacy LAPS will enter a broken state where neither feature will update the password for the managed account. Symptoms include Windows LAPS event log IDs 10031 and 10033, as well as legacy LAPS event ID 6. Microsoft is working on a fix for this issue.
Two primary workarounds exist for the above issue:
a. Uninstall the legacy LAPS CSE (result: Windows LAPS will take over management of the managed account)
b. Disable legacy LAPS emulation mode (result: legacy LAPS will take over management of the managed account)
Issue #2: If you apply a legacy LAPS policy to a device patched with the April 11, 2023 update, Windows LAPS will immediately enforce\honor the legacy LAPS policy, which may be disruptive (for example if done during OS deployment workflow). Disable legacy LAPS emulation mode may also be used to prevent those issues.
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview#windows-laps-supported-platforms-and-azure-ad-laps-preview-status
Prepare Windows LAPS ADMX templates
After the successful installation of the April 2023 CU the new LAPS ADMX/ADML templates are now available:
- C:\Windows\PolicyDefinitions\LAPS.admx
- C:\Windows\PolicyDefinitions\en-US\LAPS.adml
Now they only have to be copied to our Active Directory Central Store:
| Source | Target |
|---|---|
| C:\Windows\PolicyDefinitions\LAPS.admx | \\%domainname%\SYSVOL\%domainame%\Policies\PolicyDefinitions |
| C:\Windows\PolicyDefinitions\en-US\LAPS.adml | \\%domainname%\SYSVOL\%domainame%\Policies\PolicyDefinitions\en-US |
Update the Windows Server Active Directory schema
As with the previous LAPS version, we first need to extend the Active Directory schema with the following PowerShell cmdlet.
Update-LapsADSchema
The schema update adds a total of 6 new Windows LAPS Active Directory attributes:
Grant the managed device permission to update its password
Now we have to give our devices write permissions to their own (SELF) Windows LAPS password attributes. These permissions can be set using the Set-LapsADComputerSelfPermission PowerShell cmdlet. This sets inheritable permissions for desired organizational unit (OU) in which our devices are located.
Set-LapsADComputerSelfPermission -Identity "Your Active Directory Device OU"
The identity can be specified with the distinguishedName as well as with the simple OU name. If the specified OU name is not unique, the distinguishedName must be used.
Delegate Windows LAPS permission
By default, only Domain Admins and NT AUTHORITY\SYSTEM have read and write permissions on all ms-LAPS attributes. This can be checked via the Find-LapsADExtendedRights PowerShell cmdlet.
To assign delegated rights for admin groups the following two PowerShell cmdlets can be used.
| PowerShell cmdlet | Description | Permissions |
|---|---|---|
| Set-LapsADReadPasswordPermission | Grant permission to read the Windows LAPS password. | msLAPS-EncryptedPassword (read) msLAPS-EncryptedPasswordHistory (read) msLAPS-Password (read) msLAPS-PasswordExpirationTime (read) |
| Set-LapsADResetPasswordPermission | Grant permission to trigger a Windows LAPS password reset. | msLAPS-PasswordExpirationTime (read and write) |
To enable flexible management of permissions through domain global role groups, I have created two domain local security groups.
Next, the permissions can be assigned using the appropriate PowerShell cmdlets:
Set-LapsADReadPasswordPermission -Identity "Your Active Directory Device OU" -AllowedPrincipals "Your Active Directory Group"
Set-LapsADResetPasswordPermission -Identity "Your Active Directory Device OU" -AllowedPrincipals "Your Active Directory Group"
Configure policy settings for Windows LAPS
In the last step, we configure our Windows LAPS group policy and link it to our device OU: Computer Configuration > Administrative Templates > System > LAPS.
To activate Windows LAPS you basically only have to configure the password backup directory setting:
The password is encrypted by default as long as the domain functional level has already been upgraded to 2016. Since we want to test all the new features, we will of course activate several settings like Enable password backup for DSRM accounts, Configure size of encrypted password history and Password Settings.
| Setting | Description |
|---|---|
| Enable password backup for DSRM accounts | Use this setting to enable backup of the Directory Services Repair Mode (DSRM) account account password on Windows Server Active Directory domain controllers. |
| Configure size of encrypted password history | Use this setting to configure how many previous encrypted passwords are remembered in Active Directory. Supported values are 0-12. |
| Enable password encryption | Use this setting to enable encryption of passwords in Active Directory. Enabling this setting requires that your Active Directory domain be running at Domain Functional Level 2016 or later. |
| Configure authorized password decryptors | Use this setting to configure the name or security identifier (SID) of a user or group that can decrypt the password that’s stored in Active Directory. This setting is ignored if the password currently is stored in Azure. If not specified, only members of the Domain Admins group in the device’s domain can decrypt the password. If specified, the specified user or group can decrypt the password that’s stored in Active Directory. |
| Name of administrator account to manage | Don’t specify this setting unless you want to manage an account other than the built-in local administrator account. The local administrator account is automatically identified by its well-known relative identifier (RID). In case you prefer using a different account, it is necessary to ensure that it has been set up on all clients beforehand, as Windows LAPS does not generate the local administrator account on your behalf. |
| Configure password backup directory | Use this setting to control which directory the password for the managed account is backed up to. |
| Do not allow password expiration time longer than required | When you enable this setting, planned password expiration longer than password age dictated by “Password Settings” policy is NOT allowed. When such expiration is detected, password is changed immediately and password expiration is set according to policy. |
| Password Settings | Use this setting to specify password settings like PasswordAgeDays, PasswordLength and PasswordComplexity. |
| Post-authentication action (Automatic password reset on use) | Execute predefined actions (Reset the password, reset the password and logoff the managed account, reset the password and reboot the device) with a certain delay (Grace period) after a successful login of a Windows LAPS managed device. |
After the GPO has arrived on our devices, we can verify the status in the event logs:
Applications and Services > Logs > Microsoft > Windows > LAPS > Operational.
Windows LAPS for Windows Server Active Directory – Admin Experience
Read Windows LAPS Password
In our first attempt we try to read the LAPS password via PowerShell and via dsa.msc with a user who is not a member of our defined delegation groups.
Get-LapsADPassword -Identity "Your Device"
Get-LapsADPassword -Identity "Your Device" -AsPlainText
As expected, the Windows LAPS password cannot be read:
Now we add our test user to the read password delegation group and repeat the same test. Having done this, we can read several attributes and also see that the password was stored encrypted. However, we do not have permission to read/decrypt the password yet. By default, this is only possible for Domain Admins.
In order to decrypt the password, we must first add our created delegation group to our LAPS Group Policy. The following setting must be activated and configured Configure authorized password decryptors. The group can be specified either as SID or in the format domain\groupname. I could not add multiple password decryptor groups. So you have to make sure that the Domain Admins group is added to the Password Read Delegation group, otherwise it will not be possible for Domain Admins to decrypt the password.
Ok, time to repeat the test again.
Windows LAPS password rotation
A password change can either be done locally on the device via Reset-LapsPassword or the ExpirationTime can be adjusted via Set-LapsADPasswordExpirationTime.
We now try to do this first without the required rights again.
Local admin rights are adequate to execute the Reset-LapsPassword PowerShell cmdlet, and the user running it does not require any special Active Directory permissions related to a specific LAPS attribute.
A locally created admin user (non domain user) can trigger a password change:
Now we try to adjust the expiration time with our domain test user.
Set-LapsADPasswordExpirationTime -Identity "Your Device"
As expected, this does not work, because we do not have write access to the ExpirationTime attribute with our test user yet. So we add the test user to the ExpirationTime delegation group and repeat the test.
The next time Windows LAPS wakes up to process the current policy, it sees the modified password expiration time and rotates the password. If you don’t want to wait, you can run the Invoke-LapsPolicyProcessing cmdlet.
Get Windows LAPS Password History
The password history can be read out via the same Get-LapsADPassword cmldet. Only the –IncludeHistory parameter must be added.
Get-LapsADPassword -Identity "Your Device" -AsPlainText -IncludeHistory
Password backup for DSRM accounts
For this feature to work, the Domain Functional Level 2016 is required and encryption must be active. Furthermore this password can only be read and decrypted by Domain Admins. Settings made in Configure authorized password decryptors are ignored. In that scenario, this setting always defaults to the Domain Admins group of the domain controller’s domain.
I just had to link the LAPS Group Policy to the Domain Controller OU. Set-LapsADComputerSelfPermission did not need to be executed on the Domain Controller OU.
Run Get-LapsADPassword with Domain Admin rights:
Get-LapsADPassword -Identity "Your DC" -AsPlainText -IncludeHistory
Conclusion
The previous solution, Legacy Microsoft LAPS, was already quite straightforward to set up and control. However, with the integration of Windows LAPS into the operating system and the introduction of new PowerShell modules, implementation and management have become even simpler. Furthermore, security has been enhanced through the encryption of passwords, password history tracking, automatic password reset on use, and the ability to manage DSRM accounts. We can only hope that the implementation of Windows LAPS for Azure Active Directory goes as smoothly as the on-premises scenario and that we don’t have to wait that long for the public release.
Gobisweb 