In the world of IT security, lateral movement refers to the practice of attackers moving within an infrastructure from one system to the next. In such cases, the attacker usually has valid authorization, such as the hash value of the local administrator account. We often see many of our customers using the same local administrator password on all client computers, or even the servers. This makes it easy for attackers to hop from one system to the next. Using local administrator rights, they can easily gain access to additional authorizations and thus expand their rights.

One way to guard against this is to set a different password for each system. The first technical countermeasure, however, was to use group policies to deploy the password. But this did not offer adequate security, because the respective password is visible to all users who have access to the respective policy. When using a group policy, the password is indeed stored in encrypted form, but the key for it is still public knowledge. This means that a password can be easily decrypted.

Local Administrator Password Solution

In May 2015, Microsoft released a Security Advisory 3062591 in which it presented its Local Administrator Password Solution. LAPS makes it possible to set a unique, randomly generated password for the local administrator account on each system of the domain, and the password is saved in the active directory. Password administration is therefore handled automatically. As soon as the password expires, the LAPS client generates a new one.

The LAPS client is what is known as a GPO client-side extension (CSE), which carries out the following steps when updating a group policy:

1. Check whether the password of the local administrator account has expired
2. Generate a new password if the old one has expired or if a change is enforced
3. Check whether the new password meets the requirements defined in the password policy
4. Save the password in Active Directory, in the computer object with the attribute Confidential
5. The new expiration date is also saved in the computer object
6. Change the password of the administrator account

Installation and configuration

The LAPS installation consists of two modules:

• the administrative components
• the LAPS client

The LAPS client must be installed on each system to be managed. The administration components can be installed on any system and consist of a GUI client, PowerShell cmdlets and GPO templates. An Active Directory schema extension is also required. Two attributes are included as well: ms-Mcs-AdmPwd (containing the password in plain text) and ms-Mcs-AdmPwdExpirationTime (time stamp for expiration of the password). Both attributes are added to the class Computer. The attribute ms-Mcs-AdmPwd is what is referred to as a confidential attribute. By default, only domain administrators can read these attributes.

Along with the setup files, Microsoft offers an operational guide for download that explains the necessary installation steps in detail.

The LAPS configuration is deployed via the group policy. LAPS is basically activated with the Enable local admin password management setting. The password format can be defined under Password Settings. We recommend the following complexity requirements: large letters + small letters + numbers + special characters, password expiration set to 30 days, password length of 28 characters (based on research by Rob Fuller). The setting Do not allow password expiration time longer than required by policy should be enabled, because LAPS observes the currently set expiration date and only makes a change at that time. If an expiration date is then set beyond the defined value, LAPS would otherwise perform the change only at that point.

If desired, local accounts can also be managed with LAPS by specifying the user name. The setting Name of administrator account to manage exists for this purpose. A side note concerning the deployment of this policy: If this policy should also be applied to domain controllers, then the password of the administrator account of the domains (“local” administrator on a domain controller) is also changed via LAPS.

Managing access rights

The passwords generated by LAPS are saved in plain text. For this reason, protecting access to the password attribute is very important. After installation, the access rights must be defined in the AD attributes.

Firstly, it is necessary to authorize the machine account itself to save its newly generated password in the appropriate AD computer object. This is performed as follows and must be defined for each organizational unit managed using LAPS:

PS C:\Users\Administrator> Set-AdmPwdComputerSelfPermission -OrgUnit Policy

Name                 DistinguishedName                                                 Status
----                 -----------------                                                 ------
Policy               OU=Policy,OU=Labs,DC=labs,DC=scip,DC=ch                           Delegated

As previously mentioned, the password is stored in a confidential attribute. By default, only SYSTEM and domain administrators have the right to read confidential attributes. However, if a user or group in an OU possesses All Extended Rights, they will be permitted to read confidential attributes. It is therefore crucial that only authorized groups possess this right. This can be checked with the following command:

PS C:\Users\Administrator> Find-AdmPwdExtendedRights -Identity Policy

ObjectDN                                      ExtendedRightHolders
--------                                      --------------------
OU=Policy,OU=Labs,DC=labs,DC=scip,DC=ch       {NT AUTHORITY\SYSTEM, LABS\Domain Admins}

Additional groups, such as the IT support group, can be added by using the command Set-AdmPwdReadPasswordPermission.

All requirements for the introduction of LAPS are now met and we were able to roll out the policy on two clients in our test lab. After restarting, the administrator password was reset, as expected. This can be checked using the PowerShell cmdlet Get-AdmPwdPassword. As a test, we executed the command with a normal domain user named jdoe:

PS C:\Users\jdoe> Get-AdmPwdPassword -ComputerName client0*

ComputerName         DistinguishedName                             Password           ExpirationTimestamp
------------         -----------------                             --------           -------------------
CLIENT01             CN=CLIENT01,OU=Policy,OU=Labs,DC=labs,DC=s...                    16.07.2017 12:37:38
CLIENT02             CN=CLIENT02,OU=Policy,OU=Labs,DC=labs,DC=s... .3x@+}30dn[Afr8... 16.07.2017 12:34:50

As expected, the user does not have rights for the Client01 password. So why is the password displayed for Client02? The reason is that the computer Client02 was added to the domain by the user jdoe (domain join). As a result, the user becomes the CREATOR OWNER of the respective object and has special rights for the object. The default rights of the computer object allow for granting the CREATOR OWNER the right All Extended Rights for the respective object. In the blog post LAPS and permission to join computer to domain Jiri Formacek explains how to change the default rights for the computer object. Another option is for the computer to be added to the domain only with a specific service account and not with normal user accounts.

Conclusion

LAPS offers a simple method for automated password management of the local administrator account. Built-in Windows features are used here, and the configuration can be deployed via group policies.

The downside, however, is that the password is stored in plain text in the computer object. It is therefore essential to be conscientious when granting access rights to the respective attribute, and to monitor access.

However, we see this as a typical IT security tradeoff. Using LAPS provides considerably better security for the entire infrastructure than avoiding the solution simply because passwords are stored in plain text. An alternative approach that also saves the password in encrypted form would, of course, be preferable.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://blogs.msdn.microsoft.com/laps/2015/07/17/laps-and-permission-to-join-computer-to-domain/
• https://learn.microsoft.com/de-de/security-updates/securityadvisories/2015/3062591
• https://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2
• https://room362.com/post/2017/05-06-2017-password-magic-numbers/
• https://social.msdn.microsoft.com/profile/Jiri+Formacek
• https://twitter.com/mubix
• https://www.microsoft.com/en-us/download/details.aspx?id=46899