15 Oct (E)SAE DEEP DIVE SERIES PART 6 – Local Administrator Password Solution (LAPS)
This part of the series deals with local administrator passwords on servers. In many companies, the same password for the local administrator account is used on all Windows servers. This password is often known to a relatively large number of employees and often also to former employees of the company or its service providers. However, if the password is changed regularly, the password change is often carried out with self-developed solutions based on scripts or group policies. The password is stored locally in plain text or disguised and the administrator password remains the same for a large number of systems.
Microsoft offers the Local Administrator Password Solution (LAPS) as a free download. This solution enables the assignment of individual passwords and their automated change for the local administrator account on Windows systems.
How does LAPS work?
The solution consists of different components. The passwords are stored in an attribute in the Active Directory, which is protected by an ACL, so that only authorized accounts can read the password. This requires an extension of the Active Directory Schemas that adds the attributes ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime to the Computer class.
On Windows systems a Group Policy Client Side Extension (CSE) is installed. Via CSEs the functionality of Group Policies can be extended almost unlimited. CSEs are implemented as DLL and registered in the Windows Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. The CSE is then loaded by the Group Policy Engine and first reads the ms-Mcs-AdmPwdExpirationTime attribute, which stores the password expiration date. If the expiration date is older than the current date, a new password is generated according to complexity criteria configurable via Group Policy Settings. The CSE also validates the password against the domain’s complexity policies. The CSE writes the new password in plain text to the attribute ms-Mcs-AdmPwd and the new expiration date to the attribute ms-Mcs-AdmPwdExpirationTime. After updating both attributes the new password for the local account is changed.
Installation and configuration of LAPS
For the installation of LAPS the following steps are basically necessary:
1. Install the LAPS management tools on a management computer. Ideally, Privileged Admin Workstations (PAW) are used for administration and the LAPS Management Tools are installed there. If you are not yet using PAWs, you will need to wait until part 7 of this series for more information 😊. The LAPS installation includes a Fat Client UI, a PowerShell module and the Group Policy Template admx. If a Central Store für Administrative Group Policy Templates is used, the file AdmPwd.admx must also be copied there.
2. LAPS erfordert eine Erweiterung des Active Directory Schemas. Dazu muss das ausführende Konto Mitglied der Gruppe Schema Admins Dazu wird das Cmdlet Update-AdmPwdADSchema verwendet. Das PowerShell-Modul kann aus dem Installationsverzeichnis $PSHOME\Modules\AdmPwd.PS auf die PAW kopiert werden. Sollten keine PAWs im Einsatz sein, kann das Modul auch einfach auf den Domain Controller kopiert werden.
3. the password is stored in plain text in the attribute ms-Mcs-AdmPwd in the Active Directory. Therefore, it is important to adjust the permissions so that only authorized persons have access to this attribute. The adjustment of permissions is done for each OU, which contains computer objects for Windows servers. A detailed description of the necessary steps can be found in chapter 6.2 of the document Local Administrator Password Management – Detailed Technical Specification, which is included in the LAPS download.
4. LAPS also includes an administrative template (AdmPwd.admx), which allows you to manage the LAPS client settings as usual with the Group Policy tools. The name of the local administrator account can be configured via the setting Enable local admin password management. If this setting is not activated, the account with the Well-Known Security ID 500 is used by default. This is always the local BUILTIN\Administrator account in every Windows installation, regardless of the language of the Windows version.
The settings can also theoretically be made directly in the Windows Registry in HKLM\SOFTWARE\Policies\Microsoft Services\AdmPwd. These are described in the document Local Administrator Password Management – Detailed Technical Specification.
5. the Group Policy CSE must be installed on all systems on which the local administrator password is to be changed The file AdmPwd.dll is copied to %ProgramFiles%\LAPS\CSE\ and registered in the system. With regsvr32.exe the DLL can also be registered
Typically it is installed automatically with a management suite such as Microsoft Endpoint Configuration Manager, but can also be installed using group policies.
6. it is recommended to log the auditing of read operations on the attribute ms-Mcs-AdmPwd in the Security Event Log as described in chapter 5.3 of the LAPS Operation Guides.
The installation and configuration is described in detail in the LAPS documentation, in the Technet Gallery you will also find a detailed description.
Security of LAPS
Customers often ask us whether LAPS is safe. At this point we would like to summarize the most important information for you.
Password storage and transmission
The password of the local administrator account is stored in plain text in the ms-Mcs-AdmPwd attribute of the Computer object. The attribute is protected with an ACL and, if configured correctly, only authorized people have access to the password. Microsoft justifies the decision with the fact that encryption would have resulted in a much higher complexity of the solution, because complex mechanisms for key distribution and protection would have had to be implemented. ACL protection is sufficient for most environments, but each company must evaluate this for itself based on existing security requirements.
The password is transmitted to the domain controller via a channel protected by Kerberos Encryption and therefore cannot be easily read by a network sniffer like Wiresharek.
Another scenario that needs to be considered: The user who “joined” a Windows system to the domain is entered as owner in the Computer object by default and therefore has full permissions on the Computer object and can read the plaintext password stored in ms-Mcs-AdmPwd. In enterprise environments normal users are usually deprived of the right to join computers to the domain. If you want to do so, it is useful to set the Domain Admin group as owner on all objects by script.
An article by the security company Praetorian describes a man-in-the-middle attack in which the LDAP session is redirected by help desk employees to a “rogue” server, which can then intercept the plaintext passwords. As a countermeasure the article recommends to activate LDAP Signing via Group Policies. Another possibility is to add the accounts of Help Desk employees to the Protected Users group. Members of this group cannot authenticate themselves via NTLM. However, depending on the environment and applications used, this can lead to side effects, so this scenario must be tested in any case.
Microsoft has been trying to push the topic of LDAP signing since 2019 (ADV190023). Our experience shows, however, that the changeover is not quick and easy. Who has not yet dealt with it, should start soon.
If the Group Policy CSE AdmPwd.dll is not installed by MSI but manually, it is important to install it in a directory that cannot be written to by a non-administrative user. Otherwise it can be overwritten with an own DLL, which “intercepts” the password in clear text to misuse it. An attacker who has managed to gain administrative privileges on the local system can also use this scenario to persist his administrative access. A demonstration of this attack was given by Maxime Clementz and Antoine Goichot on a Hack.lu talk.
For the sake of completeness we also want to mention the 2014 vulnerability CVE-2014-1814. The vulnerability in the Windows Installer Service allows an attacker to use the repair function to overwrite an existing application if the MSI was installed from a user-writable location. The vulnerability has been patched and is no longer present after Windows 8 / 2012 R2 and should therefore no longer be relevant for new installations.
From our point of view, LAPS is safe and much better than the “classic” alternatives if configured correctly.
In the day-to-day operation of LAPS you may encounter the following problem. Suppose we need to restore a backup that is a bit older. Between the backup and today, both the computer account password and the LAPS password were automatically changed. After the restore, you find that you cannot log on using a domain account because the trust relationship between the computer and the domain no longer works. If you now try to log on with the LAPS password stored in AD, this also does not work because they do not match either. You effectively have no way to log on to the system anymore.
We see two solutions for this problem. Either you overwrite the local administrator password with tools like the Ultimate Boot CD or you write the LAPS passwords via script regularly into a file on the domain controller. This may sound insecure at first, but if an attacker has already made it to the domain controller, the security of the local administrator passwords is usually the smallest problem.
If this is too complicated for you, you can have a look at AdmPwd.E. The product is conceptually very similar from the original developer of LAPS and LAPS, but with some useful features like a password history added. But there is a downside: AdmPwd.E is unfortunately not free.
Overall, LAPS is a secure, robust and free solution for managing local administrator passwords, albeit with minor limitations. It uses the existing Active Directory components and therefore does not require separate infrastructure and training for administration. Permissions for reading and resetting passwords can be flexibly and granularly assigned to any groups and users.
If you liked the article, you can already look forward to the next part of the series about Privileged Admin Workstation (PAW).
FROM OUR SOCIAL MEDIA
Sieh dir diesen Beitrag auf Instagram an
Sieh dir diesen Beitrag auf Instagram an
In our January blog, we started an SAE deep dive series and explained how to use Hyper-V as a secure hypervisor in an (E)SAE scenario. Since by far not all our customers use Hyper-V, but many also use VMWare...15 June, 2020
(E) SAE Deep Dive Series Part 1: Hyper-V Host Guardian Service (HGS) and Shielded VMs in an EASE Environment
After the success of the first ESAE series, we decided to launch a deep dive series in which we go into a little more detail on various measures....16 January, 2020
After Hyper-V HGS and VM protection with VMWare, now the third part of our (E) SAE Deep Dive Series follows. Maybe you follow us on LinkedIn, Xing, Facebook, Instagram or Twitter and ...15 July, 2020