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.

35 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.

  3. Hi, thank you for the great information. I have 1 question about LAPS.

    Can LAPS manage local admin for a user with a specific device? Meaning, users can only have local admin to their machine and not to the rest of device within the network.

    1. Thanks for the question! LAPS manages the passwords for local administrator accounts, it does not limit access or control who has local administrator privileges on devices or across the network.

    1. Hey Optimus,

      Thanks for the response. Based on my research installing LAPS on a DC will change the [DOMAIN]\Administrator account password. This is because Domain Controllers do not have local administrator accounts. It is suggested not to install LAPS on Domain Controllers, but only end points where these local admin accounts exist.

      1. Domain Controllers SAM files, which control the local user administration are only used during a recovery where Active Directory is not accessible on the machine. The password it would change, in theory, would be the Directory Service Restore Mode Administrator password.

  4. Hi Kevin.
    Do you know what happens if a server with LAPS is restored to a point of time where the password was changed a few times?
    is it possible to lookup passwords from a specific date in the past?

    1. Thanks for the question! I don’t think you’re able to get a password from a specific date in time. I believe you’d want to force the password to be reset using the UI client or PowerShell, and then query the new updated password.

      Something like this:
      Reset-AdmPwdPassword -ComputerName [RestoredComputer]

      You’ll need to wait for group policy to refresh on that computer before the PW is updated, but you should be able to kick that off in the Group Policy Management snap-in.

      1. If a memberserver is restored and its local admin acount password has changed between the backup and the restore, it is most likely the computer account password has also been changed. Hence:
        – no local admin password to access the local machine to re-connect it to ad
        – no domain-access to the local machine due to lost of access between ad and the local machine.

        The only solution here is to reset the local admin password using an alternate boot system. Bad luck if you have secured the boot meganism to not be able to boot from any other device than the os device.

  5. Hi,

    Thanks for the information. What happens if the server being managed by LAPS loses it’s connection to the AD domain? How would you log into it? The only reason we even have a local admin enabled is in case domain login stops working

    1. Thanks for the question! In this case the password should be stored in the AD attribute for the computer object, you can query it to retrieve the current password using the LAPS UI or PowerShell cmdlets. Then you should be able to use it to login as the local admin even though the computer is not able to connect to the domain for whatever reason.

    1. The laps fat client is not needed to have the passwords reset and stored in ad. The laps fat client is most likely only needed to get the password and optionally forcefully reset it.

  6. Hi!

    What happens if we restore a backup of a server that i older than the maximum age configured for the LAPS clients?

    The password has changed since the backup was taken, and we will then have no local Administrator to log on to the server an rejoin it to the domain..?

    Is there any possibility to store some kind of password history. Maybe 2 or 3 passwords back in time.

    Thanks!

    Regards
    Fredrik

    1. Thanks for the comment. I did a little digging into this, and it seems some folks are exporting the LAPS password on a regular basis and storing it in a secure manner to handle this situation. I think that potentially raises a security concern, and I wouldn’t advise going down that path. Something I thought of when looking into this, is that you could modify your AD schema to include a few more LAPS related attributes, and script something that would take the current LAPS password and populate it in one of the newly created attributes and continuing that process as time goes on storing X passwords, where X is the number attributes you decided to create. Treating these new attributes in a secure manner, similar to the native LAPS attributes would be necessary here, but at least it’s not exporting the passwords and storing them on a file system somewhere.

      Unfortunately for end-users, it seems Microsoft may have not accommodated for this scenario, and a custom solution would need to be created in the instance this is a frequent process in an organization.

  7. Hi Kevin,

    my company is considering implenting LAPS.
    The only issue for us is that it’s not possible to find the local admin password without having to connect to AD.

    For example: if im logged into the laptop as user with no internet connection, i can’t login to our AD environment and check the current local admin password.

    Is there a workaround for this?

    Thank you

    1. Hey Bob, unfortunately, you need connectivity to an Active Directory domain controller to query the current password for a LAPS managed machine. I’m a little confused about the situation you posed though. If you’re already logged into the laptop, what do you need to query the password for? How LAPS works is the password is changed every X days (configured in the LAPS policy). If for whatever reason the laptop/PC isn’t connected at the time of the rotation, it will change in AD, but it wont be updated on the endpoint until it is reconnected to the network and can communicate with the Domain Controller. This means that if you know the current password (presumably you do because you were able to login), the password should remain the same for that machine until it is reconnected to the network/Active Directory environment, at which point it should rotate. Once it rotates, as long as you’re still connected to the network, you should be able to query the password again.

      Hopefully that helps, if not feel free to clarify where I may have been confused and I’ll try to assist further.

  8. Hello,

    Does LAPS work when a client computer is authenticating against an RODC and RODC has connectivity to RWDC.

    The client computer itself doesnt have direct connectivity to RWDC.

    Thanks

    1. Thanks for the comment! I unfortunately have not tested that scenario myself in my lab, I only used a RWDC. I did do some digging and found that when a RODC is at play, you need to update the Filtered Attribute Set (FAS) to include the LAPS attributes in the schema to be replicated. I found this guide that explains how that can be done. I hope this helps, and sorry for not having an answer to your specific question! If possible, I would suggest testing that scenario in a Dev/QA type environment before deploying to production.

      https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754794(v=ws.10)

    1. Once you configure and enable LAPS, it should update the password(s). Then, the new passwords will be determined based on the configured value for the password age in the group policy settings.

  9. Using the Microsoft LAPS client and group policy, is it possible to control more than one administrator account on the machine? So let’s say we had admin, dave, bob, and john on different computers throughout the company as local admins. Could you administer all those different names with the policies?

    1. It may get a little tricky from a management perspective if different machines have different named Admin accounts, but yes, this should be possible. When a Local Administrator account, other than the default Administrator account is to be managed, you can specify that in one of the group policy settings for LAPS: “Name of administrator account to manage”. You can see the policy in the first screenshot in the blog, although I did not dive deeper into that setting and its configuration.

      Just to note, this is not needed if you RENAME the Administrator account to a different name, as this account is identified by its SID. If you’ve created a net new account and disabled the default Administrator account then you can use this setting to get them managed.

  10. Hi,

    I’ve successfully tested the Microsoft DaRT tool to reset the local admin password in a lab environment (both physical and VM), which should mitigate the problems highlighted above.

    This might seem to open a security hole in LAPS, but remember, you need physical (or virtual physical) access to the server to run DaRT. And as some security guy who i can’t remember the name of said, “once your adversary has physical access to the system, it’s game over”.

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 Stealthbits Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other