This third part of the article series "Simple measures for more security in AD" deals with the passwords of local administrator accounts. In many environments, the local administrator passwords are always the same, but this sometimes opens the door to malware and makes lateral movement possible or at least simplifies it.
However, manually assigning different passwords for the local administrator for each client and server is usually also impractical. Cyclical password changes on servers and clients are also almost impossible to manage manually. Microsoft has published the LAPS (Local Administrator Password Solution) tool for precisely this purpose. Using LAPS, a small agent generates an individual password on each client and server and also changes it cyclically. The local admin password is stored in the Active Directory and can be read by authorized persons using a small GUI. LAPS is conveniently controlled via group policy.
This HowTo is about the installation and configuration of LAPS, ideally in an Active Directory that already contains the Admin Tier Model used.
Installation
To install LAPS, the required components must first be downloaded:
LAPS requires an update of the Active Directory schema and the creation of group policies, so I perform the installation directly on a domain controller, so all the necessary components are available on a DC to set up LAPS.
The installation itself is done with just a few clicks, so there are only comments on relevant settings:
The installation of LAPS does not add any additional services to a DC, but only installs management tools such as a PowerShell module and GPO extensions. The "Fat Client UI" is not required on the domain controller and should therefore not be installed:
After installation, the AD schema for LAPS must be extended.
Extend Active Directory schema and prepare authorizations
After the LAPS package has been installed on the domain controller, the Active Directory schema must be extended. This is one of the rare cases in which schema admin rights are required. If an Admin Tier concept has already been implemented, a Tier 0 Admin must be added to the "Schema Admins" group at this point:
After the user has been added to the group, they must log out of Windows once and log back in again.
The AD schema can now be extended. The following commands can be used for this within an administrative PowerShell:
Import modules AdmPwd.ps Update-AdmPwdADSchema
The schema admin rights are no longer required, so the user can be removed from the "Schema admins" group again.
In order for computers to be able to save the local administrator password in the Active Directory, appropriate authorizations must be configured. The computer accounts require the right to write to the AD attributes "ms-Mcs-AdmPwd" and "ms-Mcs-AdmPwdExpirationTime". Within the AD, these rights can be assigned at OU level.
To ensure that all clients change their administrator password cyclically in future and save it in AD, the corresponding authorizations can first be configured on a client OU.
Die Konfiguration der Berechtigungen kann anhand des “distinguishedName” einer OU erfolgen. Die Schreibrechte für “ms-Mcs-AdmPwd” und “ms-Mcs-AdmPwdExpirationTime” werden dabei an untergeordnete OUs vererbt:
The following command gives the computer accounts the right to save their administrator password in the Active Directory:
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Clients,DC=frankysweblab,DC=en"
If there are other OUs in AD that contain computer accounts and are to change the password via LAPS, the command must also be executed accordingly for other OUs.
Another important point is the configuration of the authorizations for administrators, who can display the password from the Active Directory. LAPS contains the "LAPS UI" for displaying passwords, which administrators can install.
Since in this example the clients (Admin Tier 2) are initially provided with LAPS, the Tier 2 administrators should also be given authorization to read the local administrator password from the AD. With the following command, the "Tier2Admins" group receives authorization to read the passwords of the computer accounts within the "Clients" OU from the AD:
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Clients,DC=frankysweblab,DC=en" -AllowedPrincipals "Tier2Admins"
This completes the preparation of the Active Directory. The group policies for controlling LAPS can now be created.
Create group policy for LAPS
To manage the passwords using LAPS, a new group policy must be created. First, a new empty GPO is created and the user configuration settings for the new GPO can be deactivated:
The LAPS folder now contains the settings for the properties of the password and its maximum age. These settings must be activated accordingly:
In order for the password to be changed cyclically by the LAPS client, the setting "Enable local admin password management" must be activated:
The group policy is now ready and can be linked to an OU. In this case, the GPO initially applies to clients (Tier 2):
Note: At the end of the article you will also find instructions for activating LAPS on Tier 0 and Tier 1.
LAPS client installation via group policy
LAPS requires a small client on the computers so that the password can be changed automatically. So that the client does not have to be installed manually, the LAPS client can be installed automatically via GPO. Alternatively, the LAPS client can of course also be installed on the computers via SCCM or manually.
A share is first required for automatic installation via group policy. The two LAPS packages are provided within the release (x86 and x64):
In order for the client to be installed successfully, read authorizations are required on the share:
Before a corresponding group policy is created for installation, it should be checked once whether the share is accessible:
A new empty group policy can now be created. The user configuration settings can be deactivated for the GPO:
The LAPS client can now be created as a new package within the GPO:
The x64 client is first selected as the software package:
The package is assigned the "Assigned" provisioning method:
The x64 version of the client can now be distributed with the GPO:
To ensure that x86 clients also receive the corresponding package, the x86 version can be imported in the same way:
In the properties of the x86 package, the setting "Deploy this 32-bit x86 application for Win64 computers" must now be deactivated:
In order for the LAPS client to be installed on the computer, the GPO must still be linked to the corresponding OU. In this case, the "Clients" OU:
Note: Alternatively, two GPOs can also be created here, which filter for x64 and x86 operating systems using WMI filters. Here is an example of corresponding WMI filters:
SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth = '32' SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth = '64'
Testing LAPS
To check the functionality of LAPS, you can first log on to a client and check whether the LAPS client has been installed. The client should identify itself as the "Local Administrator Password Solution" program under "Apps and Features":
If the password has already been changed and saved in AD, it can be read out using LAPS UI (assuming appropriate authorization):
If the password has not yet been stored in AD or the user does not have access to the password of the respective computer account, no password is displayed:
Incidentally, there is a small disadvantage of LAPS here: the password is stored unencrypted within the AD and can be viewed by all accounts that have the "Full access" right in the AD:
Users with domain admin rights can therefore display the password directly in plain text via ADSI Edit or "Active Directory User and Computer MMC". Although the plain text password is transmitted to the AD via an encrypted connection, it is stored in the AD in plain text. Normal users with read rights cannot read the password.
Users with domain admin accounts can also change the value for "ms-Mcs-AdmPwd" in AD, but the new password is not set on the client. Only the LAPS client transfers the password to the AD, so it is not possible to reset a password by changing the attribute in the AD.
After the password has been read out using the LAPS UI or directly from the AD, the client can be logged in with the password. If the login is possible, LAPS works correctly.
Also use LAPS for servers
Of course, it also makes sense to change the local administrator passwords of the servers cyclically using LAPS. Anyone who has already implemented the Admin Tier concept can now also use LAPS for Tier 1 and Tier 0 servers with little effort.
Here is another screenshot of the Admin Tiers from the previous article:
If you have configured this in a similar way, you only need to create one or two more GPOs (if different cycles or password policies are to apply to the respective tiers) and set the authorizations accordingly. Here is a quick run-through for Tier 1 and Tier 0 servers.
Set the authorization for the computer accounts to save the password in the AD:
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=en" Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=en"
Configuration for the Admin Tier groups to read the passwords from the AD:
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=en" -AllowedPrincipals "Tier0Admins" Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=en" -AllowedPrincipals "Tier1Admins"
Create group policies for Tier 0 and Tier 1 (example of different password policies):
Link GPOs for installation and administration with OUs:
Note: If the local administrator account has been deactivated and a new admin account has been created, this can also be managed using LAPS. In this case, the name of the new account must be specified in the GPO:
If the local administrator account has only been renamed, this policy does not need to be configured. LAPS should not be used for the domain controllers in the "Domain Controllers" OU, as there is basically no local administrator account here.
LAPS Audit
For servers (possibly also for clients), it can be useful to keep an eye on which users retrieve the local admin passwords from the AD. Here is an example of how the audit for retrieving passwords for the server OUs and server admins is activated:
Set-AdmPwdAuditing -OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=en" -AuditedPrincipals "Tier1Admins" Set-AdmPwdAuditing -OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=en" -AuditedPrincipals "Tier0Admins"
As soon as an admin retrieves the password from the AD via the LAPS UI, event 4662 is logged on the domain controller, which responds to the request. The screenshot shows that the user "Tier1Admin" has retrieved the password for the computer "FS1":
Unfortunately, event 4662 is quite generic, so to generate a meaningful access report for the passwords from it, you have to go a little deeper and filter accordingly for the custom switches:
Here, for example, you could create a PowerShell script that processes the data accordingly or forwards the events to a SIEM system for evaluation.