Running LAPS in the Race to Security

Running LAPS in the Race to Security

Managed Passwords for Local Administrator Accounts

What is Microsoft LAPS?

Microsoft Local Administrator Password Solution (LAPS) is a password manager that utilizes Active Directory to manage and rotate passwords for local Administrator accounts across all of your Windows endpoints. LAPS is a great mitigation tool against lateral movement and privilege escalation, by forcing all local Administrator accounts to have unique, complex passwords, so an attacker compromising one local Administrator account can’t move laterally to other endpoints and accounts that may share that same password. A benefit, compared to other password managers, is that LAPS does not require additional computers, or application servers, to manage these passwords. The management of these passwords is done entirely through Active Directory components. You can read more on Microsoft LAPS here, and download it here.

Setting up Microsoft LAPS

Setting up LAPS in your environment requires a couple steps, and Microsoft does a good job outlining all of those steps in their LAPS_OperationsGuide.docx which is included in the download. I’ll walk through at a high level what some of these steps are. The installation of LAPS on an endpoint results in a few optional components being laid down.

  1. Fat client UI
  2. PowerShell module
  3. Group Policy templates
  4. AdmPwd GPO Extension

Management consoles need one or more of the above features to be installed to manage LAPS, whereas all the endpoints to be governed by LAPS only need the AdmPwd GPO Extension. Microsoft offers a few ways to push the AdmPwd GPO Extension to your endpoints inside the Operations Guide.

The next step in the process is to extend your Active Directory schema to accommodate LAPS. Microsoft provides a PowerShell module that will aid in this process. There are two computer attributes added to your schema, ‘ms-Mcs-AdmPwd’ and ‘ms-Mcs-AdmPwdExpirationTime’. The ‘ms-Mcs-AdmPwd’ attribute stores the local Administrators password for the computer object in clear text, scary, I know, but I’ll expand on this later. The ‘ms-Mcs-AdmPwdExpirationTime’ attribute stores the time until the password expires.

Once the schema is extended, you can push out through Group Policy the configuration of LAPS to all your member servers. There is a new Group Policy template you have access to configure once this is installed.

The ‘Password Settings’ GPO setting allows you to configure the password complexity for the passwords for these local administrator accounts, including the length and age.

The ‘Enable local admin password management’ GPO setting controls if the endpoints governed by the GPO are being managed by LAPS. These are the only two settings I configured for my testing, but there are two other settings that allow you to control some other things. One of them allows you to control non-default local administrator accounts passwords (local accounts not named ‘Administrator’) and the other allows you to enforce the password expiration time set in the ‘Password Settings’ policy to ensure that no password expiration exceeds the ‘Password Age (Days)’ setting.

Ensuring LAPS is Secure

After you’ve extended your AD schema, the next step is going to be ensuring that the permissions to these new attributes are correctly applied. This is one of the most important steps in the process, as you only want to grant access to the ‘ms-McsAdmPwd’ attribute to objects that need it. Microsoft provides plenty of PowerShell scripts to check who has access to the attribute currently, and to apply new permissions to these attributes where needed. At a high level, there a few categories that you’ll want to consider when trying to understand your 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 (remember it’s stored in clear-text in an attribute). The next permission to be aware of, is the computer object or ‘SELF’ principal requiring 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 users and groups that are allowed to reset passwords on these local administrators to the attributes on these computer objects. Locking these attributes down via permissions isn’t the only way you can stay on top of your LAPS implementation. Monitoring LDAP traffic against the two LAPS attributes is another way to stay ahead of any attackers querying this information when misconfigured permissions allow. StealthDEFEND for Active Directory is a tool that can provide real-time alerting after creating a policy to monitor LDAP traffic against these attributes.

Attached below is a script that should assist in the review of currently applied permissions to understand who has access to these attributes today.

Seeing LAPS In Action

There are a few ways to get the current local Administrator password through LAPS, but the easiest way is the GUI.

Entering a computer name that you want to query the local Administrator password for returns you with the plaintext password as well as the expiration date. You also have the capability to update the expiration date in this client. You can also query this information using PowerShell.

To Review Microsoft Local Administrator Password Solution (LAPS)

Microsoft LAPS is a powerful solution to manage the local Administrator passwords across all of your endpoints. When implemented correctly, it is an effective way to prevent some potential lateral movement or privilege escalation within your environment. Unfortunately, when it is not implemented correctly, it can create a very large opening to attackers. Understanding Active Directory permissions is a critical component of securing your environment, and the addition of LAPS attributes only makes that more complex to understand and secure. I’ve provided a script below that can assist in identifying MOST of the permissions applied directly or through inheritance that would grant access to these extended attributes. Another effective way to help understand your Active Directory permissions would be to take a look at StealthAUDIT Active Directory Permissions Analyzer. This feature of StealthAUDIT can help you understand who has access to some of the most important objects within Active Directory, including the LAPS attributes. I created two reports within StealthAUDIT that identify generic permissions to computer objects (Full Control, Write All Properties, Read All Properties, etc.) and specific permissions to the LAPS attributes.

Learn more about StealthAUDIT Active Directory Permissions Analyzer here.

4 thoughts on “Running LAPS in the Race to Security

  1. Hi i was curious to know, my organization want to implement LAPS, but not sure what would be the impact, have you seen any impact when implementing LAPS?

  2. Can LAPS help me with local admins which their user name is not “Administrator”?
    I have an organization that I manage with domain, but through the time many users made themselves local admins on computers.
    Can LAPS can change all those local users’ passwords randomly ?

    1. Hey Eden, yes, LAPS has a Group Policy setting that allows you to specify the names of accounts that aren’t ‘Administrator’. You would just need to configure this policy during the implementation of the solution.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.