I want a "Red Teaming"
Michael Schneider
This is How Local Admin Password Managent works with LAPS
Windows LAPS is natively integrated into the operating system and no longer needs to be installed via an MSI package. Updates are thus distributed via the usual update channel. LAPS now supports encrypted passwords and the use of the Azure Active Directory (AAD). Passwords in the AAD are retrieved via Microsoft Graph and access rights are managed with Azure Role-Based Access Control (Azure RBAC) policies. Password management is done through the Azure Portal and policies are distributed using Intune. On 21 April 2023, AAD support for LAPS was released as a Public Preview.
In the article, we describe the new functions of Active Directory integration, the encryption of passwords, the use of LAPS and what to consider when migrating from legacy LAPS. The use of LAPS in Azure Active Directory is not part of the article.
Microsoft developed new functions for use in an Active Directory infrastructure. The username and password are now stored in an attribute in the AD object. This attribute can now also be stored in encrypted form, which was one of the most requested functions in legacy LAPS. It is also possible to configure a password history to retrieve old passwords. This is useful when a system has been restored from a backup. If a LAPS account has been used on a system, the password can be automatically rotated afterwards to minimise the risk if the password was compromised during the operation.
Besides the native integration into the operating system, new group policy settings and the integration into the AD management tools have been implemented. LAPS now has its own event log channel. In addition to managing local administrator accounts, LAPS can also be used to rotate passwords for Directory Services Restore Mode (DSRM).
A demonstration of LAPS is shown in the video Managing local admin account passwords in AD and Azure AD by Microsoft’s Jay Simmons.
Windows LAPS requires Windows 10, 11 and Windows Server 2019, 2022 as well as the Domain Functional Level (DFL) Windows Server 2016
and the installation of the Security Update April 2023.
In legacy LAPS, the password was stored unencrypted in the AD object under the attribute ms-Mcs-AdmPwd
. By setting an ACL, access to this attribute could be restricted to authorised users and groups. In the new version, Microsoft implemented encryption for storing the passwords.
The documentation Key concepts in Windows LAPS describes the encryption function only briefly. The Cryptography API: Next Generation Data Protection API (CNG DPAPI) is used. LAPS only supports encryption against an AD security principal (user or group) and is based on the AES-256 method. The principal can be defined via GPO, by default it is the group Domain Admins
. The encryption process takes place on the client, the encrypted blob is stored directly in the msLAPS-EncryptedPassword
attribute.
According to Microsoft, the key material is stored on domain controllers and replicated via AD. Our assumption is that Microsoft uses the same principle for Windows LAPS as for Managed Services Accounts (gMSA) and uses Key Distribution Services KDS Root Keys for this. The procedure is explained in detail by Microsoft’s Windows and authentication specialist Steve Syfuhs in the article How Managed Service Accounts in Active Directory Work.
Jordan Borean, Senior Software Engineer at Red Hat, is working on a LAPS decryption project, which may provide further insight into the functionality. He publishes his work on GitHub in the repository sansldap. Further research was conducted by Adam Chester, he also published a proof of concept on GitHub.
The introduction of LAPS is documented by Microsoft in the article Get started with Windows LAPS and Windows Server Active Directory.
The basic requirement is the installation of the Security Update April 2023. Since Windows LAPS uses new AD attributes, a schema extension is necessary. The PowerShell cmdlet Update-LapsADSchema
can be used for this. The schema extension is documented under Windows LAPS schema extensions reference.
For the roll-out of LAPS, an organizational unit (OU) needs to be defined and the LAPS clients need to be granted permission to self-manage their AD object. The cmdlet Set-LapsADComputerSelfPermission
can be used for this task.
PS C:\Windows\system32> Set-LapsADComputerSelfPermission -Identity 'OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch' Name DistinguishedName ---- ----------------- t2_Workstations OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch
The ACL for access to the LAPS attributes is essential for the security of LAPS. The cmdlet Find-LapsADExtendedRights
can be used to check who has access to the attributes. By default, this is the Domain Admins group.
PS C:\Windows\system32> Find-LapsADExtendedRights -Identity 'OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch' ObjectDN ExtendedRightHolders -------- -------------------- OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch {NT AUTHORITY\SYSTEM, LAB\Domain Admins}
After the installation and the rights assignment, a policy must be created. The settings can now be found under Administrative Templates\System\LAPS. First, the setting Configure password backup directory
defines where the passwords are stored, in AD or AAD – both are not possible.
Other settings include the use of password encryption, the definition of the security principal who may decrypt passwords, the name of the user to be managed, settings for password complexity and length of history. The group policy settings are documented under Configure policy settings for Windows LAPS.
In the first step, LAPS was activated, and encryption function was deliberately deactivated. On the client, the policy was rolled out and the first LAPS password was set. The user has the LAPS access rights and can read out the password via the cmdlet Get-LapsADPassword
. With the parameter AsPlainText
the password is returned in plain text, by default it is returned as Secure String.
PS C:\> Get-LapsADPassword -Identity client01 -AsPlainText ComputerName : CLIENT01 DistinguishedName : CN=CLIENT01,OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch Account : LapsAdmin Password : W1MH0B97/Aro&qpVR77;{Xj74Y9U}9o7 PasswordUpdateTime : 4/12/2023 2:18:40 PM ExpirationTimestamp : 5/12/2023 2:18:40 PM Source : CleartextPassword DecryptionStatus : NotApplicable AuthorizedDecryptor : NotApplicable
The attributes for the expiry date and the credentials are now stored in the AD for the client:
msLAPS-Password: {"n":"LapsAdmin","t":"1d96d38ea49092f","p":"W1MH0B97/Aro&qpVR77;{Xj74Y9U}9o7"}; msLAPS-PasswordExpirationTime: 5/12/2023 2:18:40 PM W. Europe Daylight Time;
As mentioned, the username is now also saved. The password is visible in plain text in the attribute msLAPS-Password
. Now the policy will be adjusted so that the password is encrypted and can only be decrypted by the security principal LAB\laps_admins
. When querying via PowerShell, the source is now set to EncryptedPassword
.
PS C:\> Get-LapsADPassword -Identity client01 -AsPlainText ComputerName : CLIENT01 DistinguishedName : CN=CLIENT01,OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch Account : LapsAdmin Password : h460}65,O02wI[}9hv05$#!Z]1/DvN5] PasswordUpdateTime : 4/12/2023 2:20:59 PM ExpirationTimestamp : 5/12/2023 2:20:59 PM Source : EncryptedPassword DecryptionStatus : Success AuthorizedDecryptor : LAB\laps_admins
In the AD object itself, the attribute msLAPS-Password
was removed and replaced by msLAPS-EncryptedPassword
. The encrypted blob is stored in this attribute.
msLAPS-EncryptedPassword: <ldp: Binary blob 1312 bytes>; msLAPS-EncryptedPasswordHistory: <ldp: Binary blob 1312 bytes>; msLAPS-PasswordExpirationTime: 5/12/2023 2:20:59 PM W. Europe Daylight Time;
The group LAB\laps_admins
has the right to decrypt the password. In this example, the group Domain Admins
is not a member of this group. Therefore, it is not possible to decrypt the password as a domain administrator:
PS C:\Windows\system32> Get-LapsADPassword -Identity client01 -AsPlainText ComputerName : CLIENT01 DistinguishedName : CN=CLIENT01,OU=t2_Workstations,OU=Systems,OU=scip-red.ch,DC=lab,DC=scip-red,DC=ch Account : Password : PasswordUpdateTime : 4/12/2023 2:20:59 PM ExpirationTimestamp : 5/12/2023 2:20:59 PM Source : EncryptedPassword DecryptionStatus : Unauthorized AuthorizedDecryptor : LAB\laps_admins
The decryption fails and the status is returned as Unauthorized. With the definition of the security principal for the password decryption, a further security layer can be implemented.
Legacy LAPS migration is not documented at the time of publication. In a comment on the release announcement, Jay Simmons describes the procedure as follows when Legacy LAPS is in use with an additional local account:
If LAPS is used for the default administrator account (RID 500), then parallel use is not possible. Therefore, Jay Simmons recommends uninstalling Legacy LAPS CSE on the clients first and then roll out Windows LAPS, a transition period is not possible.
Microsoft has introduced new functions with the new version of LAPS and eliminated the criticism of the lack of encryption. Now it is possible to activate encryption through group policies and define which user or which group is allowed to decrypt a password. If someone gains (unauthorized) access to the LAPS AD attribute, but has no right to decrypt the content, the access alone is useless.
Native integration has made LAPS even easier to use, and support for Azure Active Directory gives cloud-only infrastructures the ability to manage on-premises administrator accounts. LAPS therefore provides a simple way to automate the management of the local administrator account password and should be used in a Windows infrastructure.
Our experts will get in contact with you!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Our experts will get in contact with you!