Written by Charlie Stubbs
What is Microsoft LAPS?
Local Administrator Password Solution (LAPS) acts as a password manager for Active Directory (AD). It ensures that all local administrators have unique and complex passwords and it rotates these passwords on a regular basis.
LAPS is a great way to prevent hackers from having the ability to move laterally through an environment and mitigates the opportunity for them to perform privilege escalation. This reduces the risk associated with lateral escalation from administrators who have the same local account and password combination on multiple devices.
Why do we Recommend a LAPS Solution?
When dealing with Incident Response cases, it is often seen that the same local administrator password is used throughout the organisation. Once the password is compromised, it is just a matter of time before an attacker can compromise the entire environment.
Commonly, the password is often the same because many organisations leverage the Sysprep process to deploy new operating systems (Sysprep is Microsoft’s System Preparation Tool for Microsoft Windows operating system deployment). Most organisations have a system image in place that has all the business software preinstalled, then clone machines from that image to automate and speed up the process of provisioning new equipment.
The problem with this imaging process is that once a system has been cloned from one machine to another, the local Security Account Manager (SAM) database will be cloned as well and the database stores all the hashes of each local account.
This is where utilising a LAPS solution makes all the difference.
How does LAPS work?
LAPS relies on a client-side extension which is a set of .dll files that contain the settings that have been applied to a targeted computer. The client-side extension performs multiple administrative tasks, such as checking if the built-in Administrator password has expired. If it has expired, it will rotate the password automatically and store it as a confidential Active Directory attribute that is only readable for users with the right permissions. The permissions can be managed via AD Access-Control List (ACL) as discussed in more detail below.
Installing and configuring LAPS is not as simple as just downloading and executing a setup application, there is some manual configuration that requires using PowerShell and Group Policy. You will need to have the AD Schema Administrator permissions for some parts of the setup process. Microsoft also has some excellent documentation on installing and setting up LAPS. Check out the ‘LAPS_OperationsGuide.docx’ document for more detailed information.
Deploying AdmPwd GPO Extension to Endpoints
Before you can manage all the endpoints with LAPS you will have to deploy the ‘AdmPwd GPO Extension’, this can be done in a few ways, including the example below:
- Run the LAPS.x64.exe application on all endpoints and only install the GPO extension.
- Copy and deploy the .dll file across all machines.
- Silently install the application via group policy.
Once LAPS is implemented, you can manage the passwords in several ways, for most administrators and help desk staff the easiest way is using the LAPS UI application.
You can also use PowerShell to read and reset the passwords. Forcing a password reset for a client system through PowerShell is accomplished by issuing the Reset-AdmPwdPassword command as follows:
Reset-AdmPwdPassword –Computer Client1A –WhenEffective (Get-Date).AddDays(-1)
This instructs the Client-Side Extension that the password has now expired and should be reset. After a brief period, the password on the client machine will be updated and visible using the Get-AdmPwdPassword command.
Ensuring LAPS is Secure
One common criticism of LAPS is that passwords are stored in plaintext, however, using AD ACL’s to lock down the groups that have access to the passwords is an effective way to mitigate this risk.
After you’ve extended your AD schema, the next step is going to be making sure that the permissions to these new attributes are correctly applied as you only want to grant access to the ‘ms-McsAdmPwd’ attribute to objects that need it.
At a high level, there are a few categories that you’ll want to review when setting permissions. The first one you’ll want to be aware of is removing the existing ‘All extended rights’ permission from users and groups on computer objects that shouldn’t be able to view the password of the local Administrator accounts.
The next permission to be aware of is granting the computer object or ‘SELF’ principal the capability to write the ‘ms-Mcs-AdmPwdExpirationTime’ and ‘ms-Mcs-AdmPwd’ attributes so it can update the passwords and expiration times when a password expires. The ACE for ‘SELF’ is required on all the computer objects governed by LAPS.
The last permission to be knowledgeable of would be to grant access to the attributes on these computer objects to users and groups that are allowed to view and reset passwords on the local administrator accounts.
Locking these attributes down via permissions isn’t the only way you can stay on top of your LAPS implementation. Monitoring LDAP queries against the two LAPS attributes is another way to stay ahead of any attackers querying this information when misconfigured permissions allow.
Following these recommendations will provide additional assurances that any potential Threat Actors will have to work a little harder to gain access across the environment, and allow an administrator to focus on other tasks.
For more information about Microsoft LAPs or help to implement your own LAPs solution. Please do contact us using the form below.