Over they years I’ve seen a number of ways to deal with Local Administrator account passwords from setting it once at build and never resetting, to deploying a change routinely via GPO (Group Policy Objects) among other poor practices. Problem with the first method is obvious, one password across multiple endpoints that never changes, wrong for so many reasons. Changing passwords with GPO is a small step up from set at build, you have ability to update passwords as needed, but the issue remains of a common password on all endpoints making pivoting throughout your domain effortless. Its also possible to extract the password from sniffing GPO traffic. There are better options.
Enter LAPS
Microsoft LAPS (Local Administrator Password Solution) made its debut in May of 2015 offering a FREE method for System Admins to manage domain joined Local Workstation or Server Administrator account passwords via Group Policy and password storage in AD. LAPS allows for truly randomized passwords to be applied individually to each Server or end user laptop/desktop using a fully customizable password policy.
A couple important notes to consider when deploying the solution: LAPS does not support UNIX, LINUX or MacOS operating systems, Windows is it. Local Guest or unique accounts are not compatible with LAPS either, only the Administrator account. Lastly there is no true Centralized Console for auditing, reporting and alerting of issues. The LAPS UI can be used to query domain machines, but its a very basic tool, my preference is the Powershell Module I’ll touch on later.
With those considerations in mind, if you are looking for a free solution, quick and easy to configure and low maintenance after initial set up, LAPS is an excellent option, so lets run high level through the config and deployment, I’ll be concentrating mainly on the GPO and AD side of things. Your method to build deployment to push the LAPS agent to managed workstations will vary depending on tools at your disposal. Microsoft has a nice work instructions doc that would include the deployment side, LAPS_OperationsGuide.docx which is included with the download.
Current version of LAPS is 6.2
Download and guide: https://www.microsoft.com/en-us/download/details.aspx?id=46899
My config steps below are the 3,000ft view to highlight notes and recommendations, refer to guide above for in the weeds install
Summary of install
• Installation of GP CSE (Group Policy Client Side Extension) via MSI installation
• On management computers
• On clients to be managed
• AD preparation
• schema extension
• Permission updates
• Group policy configuration
During install I like to push out the all administrative options to those admins that need access to LAPS passwords. The UI client in the pic above is nice for admins that may not be avid PowerShell users, our HelpDesk is the main user of the fat client UI.
Your Active Directory Schema will need to be modified for the LAPS install. Schema updates are low risk, especially on something like LAPS that has been around for years, however always run any sort of potentially high impact Schema update during off hours or better yet during a maintenance window where if the absolute worst happens you have time to recover. Schema is extended to add two new Attributes to AD Computer objects, “ms-Mcs-AdmPwd” and “ms-Mcs-AdmPwdExpirationTime”. The first new attribute, ms-Mcs-AdmPwd stores the Local Administrator Password and fairly self explanatory the ms-Mcs-AdmPwdExpirationTime is the expiration time and when the reset will take place. The Password is stored in Clear Text in the attribute, we’ll work on locking this down later.
GPO Creation is next on the to do list. Located at Computer Configuration > Policies > Administrative Templates: > LAPS
Password Settings: GPO setting allows to set Password length, complexity and maximum age
Enable local admin password management: Enables management of password for local administrator account. If you enable this setting, local administrator password is managed. If you disable or not configure this setting, local administrator password is NOT managed
Since the attribute is stored in clear text, we’ll need to lock that down next to only allow those admins that require it to be able to query. There are two methods to do this, basically remove inherited permissions, or set Deny permissions on the attribute. Both methods have their advantages, which ever you go with make sure to thoroughly test after making the change using different copied AD User accounts. MS does provide PowerShell Scripts to assist in setting proper permissions, as well as locking down.
“SELF” computer object permission is required for the computer to write to the ms-Mcs-AdmPwdExpirationTime and ms-Mcs-Adm-Pwd attributes for updates after passwords reset is executed. Next run an audit to see what users or groups permission to “All extended rights”, this will need to be removed from anyone that does not need to access passwords. The other option to lock this down would be to create a group with Deny permissions on read/modify for ms-Mcs-Adm-Pwd. Last permission are needed for who has access to force reset a password on the objects. Use the available MS scripts to assist, they lay it out very nicely.
Now that LAPS is configured and deployed lets take a quick look at the PowerShell modules available. The following basic commands should be all you ever need:
Get password: Get-AdmPwdPassword -ComputerName ‘name’ | fl
(I prefer to pipe the results to fl or format-list just encase the password is long and gets cut off)
Reset password: Reset-AdmPwdPassword -ComputerName ‘name’
That’s it, its really too easy, and in my opinion PowerShell is way quicker than using the UI client
Lets hit some potential questions that often come up:
Laptop not connected to VPN scenario– if a laptop is not connected to the network the password wont reset at the expiration time. The old password will still work just fine until the laptop connects back to the network, checks in to GPO and updates properly.
LAPS storing passwords in clear text is a major weakness– Yeah, this is an issue and guaranteed one of the first checks an attacker makes when on a network. First you MUST ensure your attribute is locked down properly. Second, you know who has access to the LAPS attribute, so use that to your advantage and set up a SIEM alert on LAPS queries for anyone outside that group. At that point you’re using it to your advantage and it almost becomes a honeypot.
Is there a record of past passwords– No, this is something that needs to be discussed within your Org and decided whether its acceptable or not. There is the possibility that a restored VM snapshot could have the old password, and if your admin account hasn’t logged in to cache could cause issues. My opinion is benefit outweighs the potential risk, but that needs to be a case by case decision.
How do I tell what computers are out of compliance- Another limitation with LAPS is the ability to audit compliance, there just isn’t a centralized console to run reports from. However, we’re admins and can script anything. Set a PowerShell query on a schedule to reach out and dump a report from workstations for the attribute date that is out of spec. Give it enough time where if an employee is on vacation and missed it by a week we aren’t bugging them, but if its 3 weeks out of spec, dig in to that one.
Microsoft LAPS is free, flexible in configuration, and better than having a single Administrator password across the board on all computers. Is it the best solution out there, not the best if you compare it to a paid solution, but may be the best free option.
WeisterCreek InfoSec – 2/3/2021
WEISTER CREEK 