How to securely manage LAPS on a Windows network

Passwords have always been a pain point in securing computing infrastructure. Complexity and length are key components of a strong password, but both make it inherently difficult for a human to remember. Additionally, passwords should be changed periodically, fine when you’re working with a handful of devices, but when your network is distributed geographically with hundreds, or thousands of computers things get more complex. Fortunately, Microsoft has had a solution to this problem in the form of Local Administrator Password Solution (LAPS), though it’s certainly not marketed as heavily as other Microsoft solutions. LAPS is a utility that enables local administrator passwords to be set programmatically based on a provided schedule using the complexity parameters you define.

How to make the best use of LAPS initial installation

As any experienced Windows administrator knows, most Windows computers in a Microsoft Active Directory (AD) domain retain accounts that are local to that computer to facilitate administrative access to individual devices in cases where the domain may not be available (network issues or even missing hardware drivers are common reasons). Securing these local accounts becomes a bit tricky. Group Policy provides options to rename the default administrator account on computers within the policy scope, but managing the password requires a bit more effort.

At a high-level, installing and configuring LAPS requires software installation on one or more management servers, minor customization of the AD schema, configuration of settings using Group Policy, and deployment of the add-on to member servers and workstations. We’ll dig into each of these components a bit more, and also identify a few issues you might encounter along the way.

The first step in deploying LAPS is installing the utility on a server that has the Group Policy management tools pre-installed. Additionally, as part of the LAPS deployment process involves modifications to the AD schema, I recommend you do this installation on a domain controller, ideally the domain controller which holds the schema master role. During this installation you’ll want to install all of the features under the Management Tools node (the Fat client UI, PowerShell Module, and GPO Editor templates).

The second step is to configure Active Directory to be able to store each computer’s local administrator password and the expiration date for that password, which requires customizing the AD Schema to add these fields. Opening an administrative PowerShell window and executing the Import-Module AdmPwd.PS command followed by Update-AdmPwdADSchema should result in a list of three actions performed successfully. If this step gives you any trouble you might need to ensure that your user has the appropriate Schema Administrator permissions, the Active Directory Schema snap-in is registered (regsvr32 schmmgmt.dll), and Active Directory replication is healthy.

Tim Ferrill

Third, for computers to be able to set passwords for their local administrator when required and for admins to read and reset those passwords, there are some permissions that must be configured on the AD organizational units (OUs) that contain computer accounts. While this could be done manually the LAPS install offers PowerShell cmdlets to help manage these permissions. The Set-AdmPwdComputerSelfPermission cmdlet can be used to configure the permissions on an OU to allow computers to store the local admin password and track the date of the change. The Set-AdmPwdReadPasswordPermission and Set-AdmPwdResetPasswordPermission allow the designated groups the ability to retrieve or reset the password respectively.

Finally, Group Policy settings related to the LAPS configuration must be set. There are four different settings under Computer Configuration/Policies/Administrative Templates/LAPS that are straightforward to configure.

1. First is Password Settings, which requires you to identify the types of characters that should be used for complexity, the length of the passwords to be generated, and the number of days before password resets occur automatically.
2. The second setting is used to identify the Local Administrator account to manage. This setting is only used if the account to be managed is not the built-in Administrator account and should not be used to reference the built-in Administrator account even if it’s been renamed.
3. Setting number three is used to ensure that the LAPS password expiration time does not exceed that of the standard Active Directory Password Settings policy.
4. Lastly the Enable local admin password management setting simply enables LAPS for computers within the scope of the GPO.

Tim Ferrill

LAPS security ramifications

The biggest thing to be aware of when considering using LAPS is the fact that Local Administrator passwords are stored in plain text in Active Directory. In the grand scheme of things this risk is mitigated with permissions to the key attributes being restricted. Additionally, the risk of a single Administrator account being compromised is extremely low compared to having all the accounts set to a single password that isn’t changed automatically.

Active Directory forests, which have been around for a while, may have allowed computers to be joined to the domain by non-administrative accounts. If so, Computer accounts joined by non-admins may have the msds-CreatorSid attribute set, which grant the users that created the account additional permissions for these Computer objects in AD, including the ability to read the ms-Mcs-AdmPwd attribute containing the password for the Local Administrator account.

Computer objects with the msds-CreatorSid should be identified and handled accordingly, and best practices dictate that only Administrators should be allowed to add new computers to the domain.

Retrieving and resetting passwords in LAPS

Generally, the only manual interaction admins will have with LAPS will be to retrieve a local administrator password for a single computer. If the LAPS administration components have been installed this is as easy as using the LAPS UI, typing in the computer name, and retrieving the password. The LAPS administration components also include the Get-AdmPwdPassword PowerShell cmdlet to retrieve passwords.

Tim Ferrill

Alternatively, standard Active Directory administrator tools such as AD users and computers or the Get-ADUser PowerShell cmdlet can each read the ms-Mcs-AdmPwd attribute, assuming the user has the proper permissions.

Local administrator passwords for computers can be reset using either the LAPS UI or the Reset-AdmPwdPassword cmdlet. These tools merely trigger the LAPS utility to re-generate a random password for the administrator account by updating the expiration to a time in the past. The PowerShell utility is particularly useful for resetting administrator passwords in bulk, a function that should be leveraged whenever a privileged user leaves the team.

Microsoft further invests in LAPS

LAPS is not a new solution and it has its shortcomings. The good news is that Microsoft is actively investing in LAPS for their latest operating systems in order to remedy some of the weaknesses in legacy LAPS and even leverage modern technologies like Azure AD. Note that currently modern LAPS is only supported on Windows 11 Insider Preview Build 25145 and later, and support for integration with Azure AD is limited to select Windows Insider users, so at the moment it’s not ready for prime time.

The first major feature modern LAPS brings to the table is the ability to store local administrator passwords in either Active Directory or Azure AD. Microsoft will also support storing encrypted passwords in your on-prem Active Directory (running at the 2016 domain functional level or above), but not Azure AD. This closes a major security gap in legacy LAPS for those using Active Directory. Modern LAPS also supports backing up AD’s Directory Services Restore Mode (DSRM ) password, a key credential for performing disaster recovery on Active Directory, but one that is rarely used and therefore easy to forget, particularly in enterprise environments.

Like legacy LAPS, much of the configuration of the modern implementation on Active Directory involves management of Group Policy objects, but of course with new features there are new settings. One new setting allows you to specify the user or group that can decrypt passwords. If this setting is not configured only members of the domain admins group in the same domain as the computer can view passwords. The Azure AD implementation is obviously quite the paradigm shift, but chances are if you’re going that route, you’ve likely already invested in Azure AD and the complexities of managing device policies through the Microsoft cloud.

One last new feature is the ability to configure LAPS to automatically handle a password reset after a local administrator account is used. This feature is intended to limit the damage if a local administrator account becomes compromised and involves the configuration of two Group Policy settings, though a malicious user that gains administrative privileges can interrupt these actions.

The post-authentication actions setting allows you to trigger a simple password reset, a password set and a forced sign-out of the user, or a password reset and a reboot of the computer. Each of these options have their place in different scenarios. The second setting allows you to configure a reset delay of up to 24 hours (with a value of 0 disabling the feature altogether).