In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important to review configuration items and implement policies that can harden your endpoints and mitigate attacks from bad actors. Secret encryption, secret history, access control list (ACL) monitoring, and more play important parts in preventing and detecting unauthorized access. In this blog post, we will cover various policies and procedures to harden a Windows LAPS deployment.
For the purposes of this blog post, we will refer to the original version of LAPS as legacy LAPS, and we will refer to passwords as secrets. Any policies mentioned can be found in the Group Policy Management Console (GPMC) at Computer Configuration > Administrative Templates > System > LAPS.
1. Enable password encryption
By default, Windows LAPS secrets stored in Active Directory (AD) are not encrypted and are only protected by ACLs. When encryption is enabled, the device containing the managed admin account performs the encryption, so there are no artifacts that a bad actor can use to gain access to an encrypted secret. This has no impact on encryption of network traffic between the client and the DC it’s communicating with. The secrets are encrypted at rest using AES 256-bit encryption on the client prior to being sent to a domain controller (DC). If a bad actor gains control of the ntds.dit file (the AD database), they will not be able to read the encrypted Windows LAPS secrets. Implement secret encryption as an additional layer of protection to Windows LAPS secrets.
Windows Server 2016 domain functional level (DFL) is a prerequisite to use this feature. You must enable this setting to get any benefit from configuring authorized password decryptors, configuring the size of encrypted password history, and enabling password backup for Directory Services Restore Mode (DSRM) accounts. This setting can be found in the GPMC at Computer Configuration > Administrative Templates > System > LAPS > Enable password encryption.
2. Configure authorized password decryptors
If you enable secret encryption for Windows LAPS secrets, you must configure a principal that is allowed to decrypt those LAPS secrets unless you only plan on domain admins performing this task. A single principal can be defined for decrypting Windows LAPS secrets that are encrypted. You can use group nesting to get around this limitation. The principal can be defined in NetBIOS or SID format. If you want other groups to be able to decrypt Windows LAPS secrets that are encrypted, and you want your domain admins to also be able to decrypt those secrets, group nesting can come in handy. This setting can be found in the GPMC at Computer Configuration > Administrative Templates > System > LAPS > Configure authorized password decryptors.
3. Configure size of encrypted password history
You may enable secret history for secrets that have been encrypted. This solves the problem when you are restoring a computer from a backup or snapshot and more than one password reset was performed by the computer (which occurs automatically every 30 days by default) after the date of the backup/snapshot being restored. You need a local administrator secret to log in initially because the computer has lost its trust with the domain, which is where secret history comes into play. Secret encryption is a prerequisite to leveraging secret history.
There typically wouldn’t be any value in storing any more than six secrets for the secret history, and most value would be around keeping two secrets in the secret history. Be careful when setting this value to a high number. You could significantly increase the size of the AD database in a domain with tens of thousands (or more) computers. This setting can be found in the GPMC at Computer Configuration > Administrative Templates > System > LAPS > Configure size of encrypted password history.
4. Configure post-authentication actions
A policy can be applied to automatically log out the local administrator after a certain number of hours once account authentication has occurred. Alternatively, a reboot can be enforced, or you can simply have the secret changed. These actions are useful because the local administrator account is meant only for break-glass purposes. Using these actions enforces the behavior of only using the break-glass account for break-glass purposes. The most restrictive setting for this policy that would provide the least chance for misuse is Grace Period = 1 hour and Action = Reset the password and reboot the device. This setting can be found in the GPMC at Computer Configuration > Administrative Templates > System > LAPS > Post-authentication actions.
5. Audit ACLs and object ownership
Just like legacy LAPS, Windows LAPS has many of the same best practices that are also the same as AD permissions best practices. Do not grant FULL CONTROL, CHANGE OWNERSHIP, or WRITE PERMISSIONS on any objects (OUs and computers) beyond what the defaults are. These permissions are found in the ACL. They should be restricted to domain admins and generally should never be changed from the default values. When those rights are applied to an OU, any computers that fall under that OU are known as child objects. They will by default inherit the permissions from the parent OU and will be compromised if any account with those rights is compromised. Ownership or the ability to change the ownership or permissions of an object such as an OU or child computer objects allows that principal to grant themselves FULL CONTROL, which will allow them to read Windows LAPS passwords. Regularly audit for and remediate improperly assigned ACLs that allow for computers to be compromised.
6. Collect audit events for Windows LAPS secret retrieval
You should be sending all Windows LAPS secret read events from your DCs to a security information and event management (SIEM) collector. If you have advanced audit policies configured to audit success and failure events for the Directory Service Access category, you will see events with Event ID 4662, such as the following:
An operation was performed on an object.
Subject :
Security ID: Lab\t0-tom
Account Name: t0-tom
Account Domain: Lab
Logon ID: 0x4F7C6A1F
Object:
Object Server: DS
Object Type: computer
Object Name: CN=CLI01,CN=Computers,DC=cohovines,DC=com
Handle ID: 0x0
Operation:
Operation Type: Object Access
Accesses: Control Access
Access Mask: 0x100
Properties: Control Access
{771727b1-31b8-4cdf-ae62-4fe39fadf89e}
{72824d98-8edb-4535-86e1-afa393394c48}
{bf967a86-0de6-11d0-a285-00aa003049e2}
Summary
Secret encryption, secret history, DSRM management, and post-authentication actions were huge improvements that can be leveraged to harden any Windows LAPS deployment. If you are interested in hardening your Windows LAPS deployment and would like help, reach out to the experts at Ravenswood Technology Group. Contact us today!
