LAPS Deployment & Configuration

UPDATE (2022-01-11): Please see the note added to the “Base Group Policy Configuration” section below regarding changes to the recommendation of renaming the built-on Administrator account.

Microsoft Local Administrator Password Solution (LAPS) is a utility used to generate random passwords for a local Administrator account on Windows endpoints. It is an excellent tool to provide access to a local account for recovery/”break the glass” purposes, while keeping the password complex, stored in a restricted location, and periodically rotated. The password is written to a confidential attribute within the computer object in Active Directory, and can be retrieved by a user who has been delegated the necessary permissions. LAPS can be downloaded, along with documentation, via https://www.microsoft.com/en-us/download/details.aspx?id=46899.

Best practices recommend to use LAPS to control the builtin Administrator account (aka the “500” account), instead of specifying a named account to control. There are a few reasons for this:

• The builtin Administrator account is targeted via well-known SID, instead of username
• The builtin Administrator account cannot be locked out

Controlling a different local account can lead to a situation when someone that gains privileges via controlled account can retain them by renaming the account, where LAPS will no longer be able to “find” it. Utilizing the builtin account also allows you to configure more advanced group policy settings in conjunction with LAPS, including user rights assignments and local group preferences, where you can ensure that the only local account that is usable on the endpoint is the controlled account, and that account is not usable remotely. See the following links for further information:

• User Rights Assignment
• How to block the remote use of local accounts in Windows

The following guide will walk through the initial configuration of LAPS, along with packaging/deploying the application via Microsoft Endpoint Configuration Manager (ConfigMgr).

1. Schema Extension & Group Policy Templates
2. Permissions Delegation
3. Base Group Policy Configuration
4. Verification
5. ConfigMgr Deployment

Schema Extension & Group Policy Templates

In order to utilize LAPS, the AD schema needs to be updated in order to introduce two new computer object attributes. To complete this, perform the following via a domain controller, preferably the one holding the schema master role, or a tier 0 tool server/PAW, while logged in with an account that is a member of the Schema Admins group:

1. Copy the LAPS MSI locally and install it (PowerShell module and ADMX components only):
   msiexec.exe /i LAPS.x64.msi /qn ADDLOCAL=Management.PS,Management.ADMX
2. Import the PowerShell module and update the schema:
   Import-Module -Name AdmPwd.PS
Update-AdmPwdADSchema -Verbose
3. The output should look similar to the following if completed successfully:
   Operation DistinguishedName Status
--------- ----------------- ------
AddSchemaAttribute cn=ms-Mcs-AdmPwdExpirationTime,CN=Schema,CN=Configuration,DC=a… Success
AddSchemaAttribute cn=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=ad,DC=ajf8729,D… Success
ModifySchemaClass cn=computer,CN=Schema,CN=Configuration,DC=ad,DC=ajf8729,DC=com Success
4. Copy the LAPS group policy templates from the local store to the central store on the DC holding the PDC Emulator role (Don’t have a central store? Go make one! How to create and manage the Central Store):
   Copy-Item -Path C:\Windows\PolicyDefinitions\AdmPwd.admx -Destination \\addc01a.ad.ajf8729.com\SYSVOL\ad.ajf8729.com\Policies\PolicyDefinitions
Copy-Item -Path C:\Windows\PolicyDefinitions\en-US\AdmPwd.adml -Destination \\addc01a.ad.ajf8729.com\SYSVOL\ad.ajf8729.com\Policies\PolicyDefinitions\en-US
5. At this point, LAPS can be uninstalled from the DC if desired:
   msiexec.exe /x LAPS.x64.msi /qn

Permissions Delegation

In order for computers to write their password to AD, and users to retrieve/reset passwords, a few delegations will need to be configured on the desired OUs. In my lab environment, I have a Clients OU and a Servers OU that I will be configuring for use:

1. Create new AD groups that will be used to grant reset permissions for each OU:
   New-ADGroup -Name LAPSAdmin_Clients -Path "OU=Groups,OU=AJF8729,DC=ad,DC=ajf8729,DC=com" -GroupScope DomainLocal
New-ADGroup -Name LAPSAdmin_Servers -Path "OU=Groups,OU=AJF8729,DC=ad,DC=ajf8729,DC=com" -GroupScope DomainLocal
2. From a management client, install LAPS with all features:
   msiexec.exe /i LAPS.x64.msi /qn ADDLOCAL=CSE,Management,Management.UI,Management.PS,Management.ADMX
3. Configure permissions for computers to update their own password attributes:
   Import-Module AdmPwd.PS
Set-AdmPwdComputerSelfPermission -Identity "OU=Clients,OU=AJF8729,DC=ad,DC=ajf8729,DC=com"
Set-AdmPwdComputerSelfPermission -Identity "OU=Servers,OU=AJF8729,DC=ad,DC=ajf8729,DC=com"
4. Configure permissions for the newly created groups to access/reset passwords:
   Set-AdmPwdResetPasswordPermission -Identity "OU=Clients,OU=AJF8729,DC=ad,DC=ajf8729,DC=com" -AllowedPrincipals AD\LAPSAdmin_Clients
Set-AdmPwdResetPasswordPermission -Identity "OU=Servers,OU=AJF8729,DC=ad,DC=ajf8729,DC=com" -AllowedPrincipals AD\LAPSAdmin_Servers

Base Group Policy Configuration

UPDATE (2022-01-11): Since this post was originally written, things have changed. The following images and instructions mention to rename the built-in Administrator account. This is no longer recommended as it provides no real security value, and it caused issues with a Windows 10 update at one point. Please ignore any screenshots or instructions below regarding renaming the built-in Administrator account. Just leave it alone.

Prior to deploying LAPS to all endpoints, the necessary group policy settings should be in place. In my configuration, I configure a top-level policy to disable the local Administrator account, and lower-level policies to configure and enable LAPS. This will ensure that the local account remains disabled until LAPS is present.

Top-level policy configuration to rename and disable the builtin Administrator account:

Lower-level policy configuration:

The above Server policy is configured to only enable the account if the LAPS DLL exists. The Client policy is essentially the same, except the the age is set to 30 days. This item-level targeting configuration will ensure that the top-level policy will win and the account will be disabled on any endpoint that does not have LAPS installed.

Verification

In order to verify that LAPS is functional, install LAPS on a member server or client, and perform a group policy update:

msiexec.exe /i LAPS.x64.msi /qn ADDLOCAL=CSE
Invoke-GPUpdate

From a management client, install LAPS with all features, and verify you can obtain a password:

msiexec.exe /i LAPS.x64.msi /qn ADDLOCAL=CSE,Management,Management.UI,Management.PS,Management.ADMX

Get-AdmPwdPassword -ComputerName MECM01 | Format-List

ComputerName : MECM01
DistinguishedName : CN=MECM01,OU=MECM,OU=Servers,OU=AJF8729,DC=ad,DC=ajf8729,DC=com
Password : 48jO11Zqd3xF5YP0$0zBScJgjL24+#0u
ExpirationTimestamp : 8/27/2020 3:44:01 PM

The LAPS “fat client” can also be used:

ConfigMgr Deployment

Once LAPS has been initially configured and testing, it’s time to deploy it to all endpoints. In my lab, I’ll be creating a new application, adding an MSI deployment type, and deploying it to a pre-created collection containing all clients and servers: