Int64 Software Ltd
Windows Local Administrator Password Solution (LAPS) – New and Improved from Microsoft
Introduction
The Windows LAPS Announcement
On April 11th 2023, Microsoft announced the release of Windows LAPS, a new and improved version of their Local Administrator Password Solution. The new LAPS is designed to completely supersede the old product and is now delivered by default to compatible devices. You can read the announcement here:
As the company behind the popular OVERLAPS for Microsoft LAPS, this directly impacts us and our customers. So here’s what you can expect, what we’re doing, and how you can migrate to the new LAPS with the minimum of fuss.
System Requirements
The new version of LAPS is now being delivered via Windows Update to the following Operating Systems:
- Windows 11 Pro, EDU and Enterprise
- Windows 10 Pro, EDU and Enterprise
- Windows Server 2022 and Windows Server Core 2022
- Windows Server 2019
Older devices can continue to run the “legacy” LAPS client as needed, and OVERLAPS will continue to support them.
In addition to this, to enable the new Password Encryption feature, you need to be running at least Domain Functional Level 2016 or later.
Official Documentation
You can find Microsoft’s official documentation here:
https://learn.microsoft.com/en-gb/windows-server/identity/laps/laps-overview
New Features
Password Encryption
One of the biggest complaints we’ve heard against LAPS in the past is that the managed passwords are stored as plain text in Active Directory. Although this is not an issue if you manage your permissions correctly, it is still a concern.
To tackle this issue, Windows LAPS now supports encrypting the password in AD. It does this using the extended DPAPI-NG (or CNG DPAPI) library which makes use of Public Key Encryption and AES-256 to encrypt passwords so that they can only be decrypted by specific user or group principals.
The encrypted password is stored in the “msLAPS-EncryptedPassword” attribute as an Octet String. Be warned that if you’re trying to write a script to read this and decrypt it using the DPAPI-NG API yourself that Microsoft prepend a header to the encrypted binary data (this is not documented anywhere that I can find), and any attempts to decrypt it without removing this header will therefore fail. We’ll write up a post in the future about how to properly deal with this.
Password History
OVERLAPS already has a Password History feature, and has done for quite some time now, but now the official Windows LAPS has a password history as well. The history is stored alongside the current password using similar techniques to the “msLAPS-EncryptedPassword” password attribute.
Note that there is currently no UI to access the password history, it is only available through the Windows LAPS PowerShell module.
This feature is also only available if you enable Password Encryption, there is no history feature for unencrypted passwords.
Directory Services Restore Mode (DSRM) Password Backup
In addition to Local Administrator Accounts, Windows LAPS now supports backing up the DSRM account password on Windows Server domain controllers.
Automatic Rotation (and other Post Authentication Actions)
Windows LAPS has the ability to automatically reset a Local Administrator account password when it is used to login (either locally, remotely, as a service, etc) to a client device. This can be configured to happen after a specified grace period in order to allow the user to perform the tasks that they required the account for.
In addition to this, the policy can be configured to forcefully log the user out after this grace period, or to restart the computer.
New LAPS Tab in Active Directory Users and Computers
Microsoft have added a new tab to ADUC for viewing and expiring LAPS passwords. This is not compatible with the legacy LAPS attributes however, so if you’re running in legacy mode or have a hybrid environment then it may not be of much use.
Significant Changes
New AD Schema
If you want to get an Active Directory Administrator to break out in cold sweats all you have to do is propose making changes to The Schema. However, anyone familiar with LAPS will have probably done this in the past already, and will know it is actually pretty pain-free. While setting up test environments for both legacy LAPS and the new one, we’ve probably run through this process hundreds of times, and we have yet to break AD. Of course, that isn’t on a live environment, and we all know that’s where things tend to go wrong!
The new Schema attributes added by Windows LAPS are:
msLAPS-EncryptedDSRMPassword
If enabled, and the computer is a Domain Controller, then this will contain the encrypted DSRM password.
msLAPS-EncryptedDSRMPasswordHistory
History for the above.
msLAPS-EncryptedPassword
If encryption is enabled, the encrypted password data will be stored here. Again, watch out for the prepended header information in the encrypted data if you’re trying to decrypt this manually.
Once decrypted, this has the same JSON format as “msLAPS-Password”.
msLAPS-EncryptedPasswordHistory
History for the above.
msLAPS-Password
The unencrypted password if encryption isn’t enabled. This is stored in JSON format as shown in the example below:
{“n”:”Administrator”,”t”:”1d96ex2d53551ee”,”p”:”password”}Where “n” represents the account name, “t” is the timestamp when the password was updated (in hex format), and “p” is the password.
msLAPS-PasswordExpirationTime
This is the date and time that the password is set to expire. It is stored as a 64bit integer in Windows File Time format using UTC as the time zone, the same as legacy LAPS did.
New Group Policy Settings
Microsoft have added a new Administrative Template to Group Policy for managing Windows LAPS. Found under Computer Configuration -> Administrative Templates -> System -> LAPS, there are some familiar settings from the legacy LAPS Group Policy and some new ones. Fortunately, a lot of the settings “do what they say on the tin”, and Microsoft have done a top-notch job of providing a decent description for each setting as well, but I’ll go over each one further down the page.
One important note though is that if you are planning on running LAPS in “legacy mode”, which is to say using the new client but the old AD attributes (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime), then you can do so by continuing to use the legacy policies. If you remove the legacy LAPS client, Windows LAPS will then continue using the old attributes, but if you enable the new policies then Windows LAPS will switch to using the new attributes.
New PowerShell Commands
Along with the new client, Microsoft have provided a range of new PowerShell cmdlets. Some of them will be familiar to previous LAPS users, but they’ve added a few new ones as well. They have taken the time to document them all at the link below, but I’ll go over the main ones later in this article:
https://learn.microsoft.com/en-gb/windows-server/identity/laps/laps-management-powershell
Microsoft’s Unofficial Guide to Migration
Jay Simmons from Microsoft outlined what a migration might look like in the comments of the initial announcement, this is quoted here:
- Extend your AD schema with the new Windows LAPS attributes
- Add a new local admin account to your managed devices (call it “LapsAdmin2”)
- Enable the new Windows LAPS policies to target LapsAdmin2.
- Run Windows LAPS and legacy LAPS side-by-side for as long as needed to gain confidence in the solution (and also update IT worker\helpdesk procedures, monitoring software, etc). Note you will have two (2) separately managed local managed accounts that you may choose to use during this time.
- Once happy, remove the legacy LAPS CSE from your managed devices.
- Delete the original LapsAdmin account.
- (Optionally), purge the now defunct legacy LAPS policy registry entries.
Questions and Answers
What happens when the update is installed?
Depending on your IT policies, you may already have the update. When the Windows LAPS client is installed, it behaves differently depending on your setup:
I have never installed LAPS.
Windows LAPS will lie dormant, and not impact your environment at all until you enable it.
I have legacy LAPS clients installed.
The new LAPS client will detect the legacy one and allow it to continue working as normal. The only thing to watch out for is that there is a bug in the new LAPS where both clients could break if the legacy one is installed after the Windows LAPS update. Microsoft are aware of this and have promised to fix it next month.
If the legacy client is installed you should see Event 10033 in the Windows LAPS event logs:
“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.”
I have uninstalled the Legacy LAPS client, have left the its policies in place, and haven’t enabled the new LAPS policies.
The new Windows LAPS client will take over management of the client using the legacy LAPS policies, and will continue to store passwords in the old attributes (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime).
I have never installed LAPS, or I have uninstalled the LAPS client. Now I have enabled the new LAPS policies.
The new Windows LAPS client will take over management of the device, storing the password and additional data in the new attributes.
How do I activate Windows LAPS?
Windows LAPS is activated by enabling the “Configure password backup directory” Group Policy setting and changing the “Backup directory” to either Azure Active Directory or Active Directory depending on whether the device is a member of an Azure domain or a local one respectively.
How do I update the AD Schema?
Updating the schema is done within PowerShell running as a user who is a member of the Schema Admins group. The command is:
Update-LapsADSchemaYou should get a message that the operation was successful, and checking any computer object will now show the additional attributes.
Note that according to Microsoft’s documentation, doing this is a “one-time operation for the entire forest”, so you don’t need to update the schema on each domain in your forest.
How do I Configure the AD Permissions?
As with Legacy LAPS, there are three permissions you need to worry about:
- “Self” permissions for the computer so that they can check and update their password expiry time, and so that they can update the password when a new one is generated.
- Read permissions for the passwords and expiration time attributes for any users who you want to be able to read the Local Admin passwords.
- Write permissions to the expiration time for any users that you want to be able to configure a password reset.
For the latter two, our guidance has always been to grant the permissions to two Security Groups (we always use LAPSReaders and LAPSWriters, but you can name them whatever you want), because then managing the members and therefore the permissions is a lot easier.
If you’re using OVERLAPS, it’s important to remember to add the server’s computer object to these groups to make sure it has permission to read and expire the passwords.
The relevant PowerShell commands for updating permissions are shown below.
Set-LapsADComputerSelfPermission -Identity <OU Name>Use this PowerShell command with the name of an OU to grant computers their Self permissions. Note that the “<OU Name>” can be just the name of an OU, or the FQDN. If using the short name and a conflict is found (two containers with the same name) the script will warn you and not make any changes to the permissions.
Find-LapsADExtendedRights -Identity <OU Name>
Shows users and groups that have extended rights to the OU. This should only show NT AUTHORITY\SYSTEM, Domain Admins, and any users or groups you have specifically granted permission to. If it finds any others then they should be removed before enabling LAPS.
Set-LapsADReadPasswordPermission -Identity <OU Name> -AllowedPrincipals <User\Group Name>Grants Read permissions to the password and password expiration time attributes. This includes the encrypted password attribute, but the user will only be able to decrypt it if they are an authorized decryptor (see below when we discuss Group Policy).
The user or group name can be given by name, SID, or as an array of principals. For more information, see Microsoft’s official documentation.
Set-LapsADResetPasswordPermission -Identity <OU Name> -AllowedPrincipals <User\Group Name>As above, but this grants permission to set the password expiration time attribute.
Get-LapsDiagnostics –OutputFolder <folder>This produces a zipped analysis of your LAPS setup, identifying any potential problems or mis-configurations. You can also optionally use “-ResetPassword” to perform a diagnostic across a forced password reset operation, or “-CollectNetworkTrace” which will also collect network tracing information.
How do I configure Group Policy?
Some of the Group Policy settings you’ll recognise from the legacy LAPS settings, and some will be new. Be wary that although some of the settings may be familiar, there may be changes to the wording or the way they work, so it makes sense to take the time to check each setting before enabling the policy.
Enable password backup for DSRM accounts
As the name states, this enables the DSRM password management and backup. This only applies to Domain Controllers, and only if Password Encryption is enabled. It is disabled by default.
Configure size of encrypted password history
Allows you to specify between 0 and 12 previous passwords to be backed up to Active Directory. Only works if Password Encryption is enabled. This is also disabled by default.
Enable password encryption
If you have configured the Group Policy to backup passwords to Active Directory (not Azure AD), and your DFL is at Windows Server 2016 or above, then this will instruct clients to encrypt the password when writing it to Active Directory. Encryption is handled by the DPAPI-NG API.
Important Note: Password encryption is enabled by default if Windows LAPS is enabled! As mentioned below, this means that by default only Domain Admins will be able to retrieve the passwords.
Configure authorized password decryptors
Allows you to specify a user or group who will be allowed to decrypt encrypted Local Administrator passwords stored in Active Directory. If this setting is disabled or not configured, it will default to the Domain Admins group.
We recommend setting up a specific security group for this (to limit the use of the Domain Admins group) and remember that if you’re using OVERLAPS then adding its server object to the group will allow it to read the encrypted passwords.
Whenever you change this setting, any currently encrypted passwords will still only be accessible by the user(s) in the previous setting until a password reset operation occurs. It seems that the new LAPS client is smart enough to detect changes in the policy and initiate this process itself however, but that won’t happen until a GP update occurs.
Name of administrator account to manage
If you are using a different administrator account to Local Administrator, you can specify it in this policy setting. Note though that if you have just renamed the Administrator account you shouldn’t specify it here as LAPS will use the well-known SID instead.
Configure password backup directory
This is the main on\off switch for Windows LAPS. Setting this to Active Directory or Azure Active Directory will enable LAPS managing local administrator passwords on the computers targeted by the GPO.
Do not allow password expiration time longer than required by policy
Enabling this policy prevents users from setting an expiration time beyond what would normally be set to by default. So, for example, if your policy states that the password should be reset every 30 days, then you couldn’t set it to 60 days in the future. (Or rather that’s the principal, in fact if you do set it beyond the limit with this policy enabled, the client will instead immediately reset the password and set the normal expiry date.)
Password Settings
Identical to the legacy LAPS password settings policy. Use this to specify the complexity and length of generated passwords, and the frequency which it should reset.
Post-authentication actions
Allows you to specify an action that will occur after a grace period (in hours). Available actions are: Reset the password, Reset the password and logoff the managed account, and Reset the password and reboot the device.
If this setting is not configured, it will default to reset and logoff after 24 hours.
How do I remove the Legacy LAPS Schema Changes?
The Legacy LAPS AD schema changes (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime) are here to stay if you already added them I’m afraid:
No way to remove those extensions AFAIK – but this is a long-standing AD limitation, not something specific to LAPS. AD does offer a “schema defunction” feature (see here), but honestly I would not be in any hurry to defunct the AdmPwd\legacy LAPS attributes.
Jay Simmons, Microsoft
How do I manage the Group Policy settings from a version of Windows Server older than 2019
If you have an older server that you want to manage the Group Policy settings from, you can copy “%windir%\PolicyDefinitions\LAPS.admx” file from any new server. You’ll also need to copy the “LAPS.adml” file for your language as well, for example: “%windir%\Policydefinitions\en-us\LAPS.adml”.
OVERLAPS Support for Windows LAPS
You’ll be happy to hear that we’ve already completed work on adding support to OVERLAPS, and an update should be out at about the same time as this article is published.
Passwords are now retrieved on an order of priority, so first it checks if an encrypted password has been set and retrieves and decrypts it if it has, failing that it’ll check for an unencrypted Windows LAPS password, and failing that it’ll finally check for a Legacy LAPS password.
We haven’t yet implemented support for the Password History feature as we already have our own solution for this built into OVERLAPS. However, we have added a work item to add support as we are happy to give our customers the option to use either (or both!).
Unfortunately we’re in the process of transitioning to a new documentation system at the moment which will make it much easier for us to update it in the future, but this has had to be put on hold while we worked on this patch, so it may take some time before our official documentation reflects this information accurately. We apologise for any confusion this may cause, and ask your patience while we carry out this work.
Steps to take when installing the update
We’ve tried to make the migration for OVERLAPS as painless as possible, however there are a few things you’ll need to do to install the update and enable support for the new Windows LAPS:
- OVERLAPS 3.2 now requires the .NET Framework runtime version 4.8 to be installed on the server.
- Setup your permissions to allow OVERLAPS access to read passwords and expiry times, and set expiry times if you want to use it to reset passwords. If you already use groups to do this, you just need to add the OVERLAPS server to the group.
- If you’re using Password Encryption then it is best to use a group for the “Configure authorized password decryptors” Group Policy setting, then add the OVERLAPS server to that group so that it can decrypt the passwords.
- Install the OVERLAPS 3.2 update.
- Sit back and enjoy a nice cup of tea (or your beverage of choice), your job is done!
Like the article? Share with your friends: