Microsoft LAPS Security & Active Directory LAPS Configuration Recon

Over the years, there have been several methods attempted for managing local Administrator accounts:

  1. Scripted password change – Don’t do this. The password is exposed in SYSVOL.
  2. Group Policy Preferences. The credentials are exposed in SYSVOL.
  3. Password vault/safe product (Thycotic, CyberArk, Lieberman, Quest, Exceedium, etc).
  4. Microsoft Local Administrator Password Solution (LAPS).


LAPS Overview

Microsoft’s LAPS is a useful tool for automatically managing Windows computer local Administrator passwords. It’s important to ensure every computer changes their local Administrator password regularly, that it’s unique for every computer, there’s a way to track when it gets changed, and there’s a way to force password changes. I cover LAPS in an earlier post, including deployment, pros & cons, among other information.

Here’s a quick overview of LAPS:

  • Initial install which includes schema extensions – adds ms-mcs-AdmPwd (clear-text password) & ms-mcs-AdmPwdExpirationTime (date/time when password expires which forces the LAPS client to reset the password) attributes to computer objects.
  • Deploy the LAPS client to all computers to manage their local Administrator account password.
  • Delegate all computers access to update the ms-mcs-AdmPwd & ms-mcs-AdmPwdExpirationTime LAPS attributes on their own computer account (SELF write access).
  • Delegate the LAPS computer attributes so the appropriate users have access to view the LAPS password and/or force a reset of the LAPS password (clearing the value of ms-mcs-AdmPwdExpirationTime forces the LAPS client to change the local Administrator password).
  • Configure a new Group Policy Object (GPO) to enable & configure LAPS management of local Administrator account password management.

Note that the LAPS GPO setting “Do not allow password expiration time longer than required by policy” is set to Enabled. This is important as you’ll see at the end of this post.

LAPS Key Points

There are a few interesting key points regarding LAPS:

  • When the schema extension is performed, there are two new attributes created for computer objects in Active Directory:
    • ms-mcs-AdmPwd – a “confidential” computer attribute that stores the clear-text LAPS password. Confidential attributes can only be viewed by Domain Admins by default, and unlike other attributes, is not accessible by Authenticated Users. This value is blank until the LAPS password is changed. No one but Domain Admins can view this attribute by default. For this reason, delegation of the ms-mcs-AdmPwd attribute has to be carefully planned and performed.
    • ms-mcs-AdmPwdExpirationTime – a regular attribute computer attribute that stores the LAPS password reset date/time value in integer8 format. This value is blank until the LAPS password is changed. When the LAPS password is changed, the value in this attribute is updated based on the LAPS password change threshold (Password Age in days) configured in the LAPS GPO.
  • The interesting thing is that while only Domain Admins and delegated groups/accounts can view the LAPS password value stored in the ms-mcs-AdmPwd attribute, any authenticated user can view the value of the ms-mcs-AdmPwdExpirationTime attribute. This means that any user in the Active Directory forest (and any user in a trusted forest/domain) can enumerate the value of this attribute for all computers providing interesting LAPS information:
    • If a computer is managed by LAPS (no value vs value present)
    • When the computer’s local Administrator password was last changed (read value in LAPS GPO and subtract this value from the date/time value in the attribute).
    • If a computer’s local Administrator password is no longer managed by LAPS (value is equal to a date/time in the past).
  • The LAPS GPO Client Side Extension (CSE) runs at the client Group Policy refresh time (90 minutes by default plus a random offset of 0 – 30 minutes to ensure that all clients don’t refresh at the same time). At this time, the LAPS CSE checks the ms-mcs-AdmPwdExpirationTime value and if the value is less than the current date/time, LAPS will generate a new password (following settings in the LAPS config GPO), update the value on the computer object’s ms-mcs-AdmPwd attribute with this new password, and if successful, change the local account password to the newly generated password, and update the ms-mcs-AdmPwdExpirationTime attribute value to be today + the Password Age value in the LAPS GPO.

Identifying if LAPS is Installed on a Computer

When the LAPS client is installed, the Group Policy Client Side Extension (CSE) is configured on the computer. This is a DLL (admpwd.dll) located in c:\program files\LAPS\CSE and is configured in the registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.

Using PowerShell, we can check for the presence of the DLL:

   Get-ChildItem 'c:\program files\LAPS\CSE\Admpwd.dll'

Using PowerShell v5, we can check the file hash & hashing algorithm on the DLL:

   Get-FileHash 'c:\program files\LAPS\CSE\Admpwd.dll'

Using PowerShell v5, we can check the digital signature on the DLL:

   Get-AuthenticodeSignature 'c:\program files\LAPS\CSE\Admpwd.dll'


Discovering LAPS in Active Directory

Since LAPS requires the computer attributes to be present, we can check to see if LAPS is “installed” in Active Directory by checking for the presence of the LAPS attributes in AD.

Here we use the Active Directory PowerShell module cmdlet Get-ADObject to check for the LAPS password attribute ms-mcs-admpwd.



Identifying LAPS Password View Access (Delegation)

Active Directory objects and their attributes are typically accessible by Authenticated Users. This also includes the security permissions (ACLs) on the objects. Since we have the ability to view these permissions, including delegation, we can

Using PowerView, we can enumerate permissions in the Domain and OUs to discover LAPS attribute delegation.


Here we can see that on the Workstations OU (OU=Workstations, DC=lab,DC=adsecurity,DC=org), the “Workstation Admins” group is delegated read access (ReadProperty) for the ms-Mcs-AdmPwd attribute on computer objects (InheritedObjectType). The “Server Admins” group is also delegated read access to the ms-Mcs-AdmPwd attribute on computer objects in the Servers OU (OU=Servers, DC=lab,DC=adsecurity,DC=org). Furthermore, there is another group called “LAPS Password Admins” which is delegated read access to the ms-Mcs-AdmPwd attribute on computer objects in the Workstations OU (OU=Workstations, DC=lab,DC=adsecurity,DC=org).

From this information we know there are three AD groups that have view access to LAPS passwords on one or more OU:

  • Workstation Admins
  • Server Admins
  • LAPS Password Admins

With this data, we can get a list of accounts that have LAPS password view access in the domain.
The easy way to do this is to get membership of all the identified delegation groups (and their sub-groups) and enumerate all unique members.


With this information, we know what accounts in Active Directory have the ability to view LAPS password data for at least one OU.
Since Active Delegation is challenging to get right, though the LAPS PowerShell scripts make it pretty straightforward, and even more difficult to track and report on.


Backdoor to View LAPS Password Data

If a group is delegated “All Extended Rights” to an OU that contains computers managed by LAPS, this group has the ability to view confidential attributes, including the LAPS attribute ms-mcs-admpwd which contains the clear text password. Any group with these rights should be evaluated and removed if necessary. Domain Admins has this right by default, as does SYSTEM. Leave SYSTEM alone.

The issue is this may include groups that shouldn’t have LAPS password view access.
We can enumerate these rights using the LAPS PowerShell module cmdlet “Find-AdmPwdExtendedRights”.


In this scenario, Help Desk Level 3 Admins should *not* have access to view passwords on the Workstations OU.

Additionally, if a group/account has “Owner Rights” on the computer objects, then the group/account has the ability to modify permissions on the objects and attributes. I’ll cover AD rights more in a later post.

Discovering LAPS Password Data

Once we have the appropriate rights (in this example, an account that’s a member of LAPS Password Admins group) we can pull the list of computers and their LAPS passwords.



Identifying LAPS Computer Management

Since the LAPS computer attribute ms-mcs-AdmPwdExpirationTime is a regular attribute, authenticated users have read access, we can track LAPS usage in an environment, including the discovery of computers being managed by LAPS as well as those that aren’t actively LAPS managed.


The fun thing about this is if delegation of the ms-Mcs-AdmPwdExpirationTime attribute is too broad, compromise of one of these accounts can change the value of this attribute to be a date/time far in the future, just forcing the local administrator password to not change until then. This is handy for an attacker who has identified the LAPS password(s) and can then extend the use of these passwords.


That’s interesting… One of the computers has an expiration date well past the 30 days configured in the GPO. This means that the LAPS CSE won’t change the local admin password until after that date. Nice little LAPS hack. 🙂

The scenario in the last graphic – preventing LAPS from updating the local password until some point in the future only works if the LAPS GPO setting “Do not allow password expiration time longer than required by policy” is set to “Not Configured” or “Disabled”.
The best way to mitigate this potential issue is to ensure the LAPS GPO setting “Do not allow password expiration time longer than required by policy” is set to “Enabeld” as shown in the graphic at the beginning of this post.


(Visited 138,815 times, 5 visits today)


    • Ryan on August 16, 2016 at 5:13 am

    I would be interested to know your thoughts on the password stored in clear text? Our security team are not happy to approve LAPS as they see that as a security risk and want the password encrypted.

    my initial thoughts are that the password is stored on a confidential attribute so you would need to compromise AD and the ACLs to get access which at that point does it really matter where your passwords are stored..don’t you have bigger issues?

    1. I agree that it would be better if the password was encrypted and note as much in my earlier post on LAPS (
      Since the password is stored in a confidential attribute which only Domain Admins have access to by default (not including custom delegation), the password data is appropriately secured. IF the issue is the difference between changing local admin passwords versus not, the answer is simple, use LAPS (or another password management solution).

Comments have been disabled.