Security Thoughts: Microsoft Local Administrator Password Solution (LAPS, KB3062591)

Reading Time: 7 minutes

As you might recall, Microsoft offered a solution to systems administrators to set the local administrator password on domain-joined devices using Group Policy Preferences, but ended the solution, almost a year ago, when the encoding mechanism was decoded and an attack was created towards this vulnerability (CVE-2014-1812).


Introducing LAPS

Yesterday, Microsoft introduced version 6 of their solution to set passwords for local administrators: Local Administrator Password Solution (LAPS).

Previously, this solution was only available to Microsoft Services customers and known as AdmPwd. This abbreviation is found throughout the solution, still.

LAPS provides a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, randomly generated password for the common local administrator account on every device joined to the Active Directory domain. Domain administrators who use this solution can determine which users, such as helpdesk administrators, are authorized to read passwords.

The local passwords can be configured with a maximum age, complexity and length. They can be server-based reset on a per-machine basis, if need be.


Implementing LAPS

To implement Microsofts Local Administrator Password Solution, you must first download it. It can be found in the Microsoft Download Center here.

Install the LAPS.msi corresponding with the architecture of the Operating System you’re using to extend the schema and manage the solution (either LAPS.x64.msi or LAPS.x86.msi). These packages include:

  • The Local Administrator Password Solution Group Policy Client Side Extensions
  • The Local Administrator Password Solution Management Tools
    • Fat Client User Interface (UI)
    • PowerShell Module
    • Group Policy Editor templates

Default Installation Options for the Local Administrator Password Solution (click for original screenshot)

Meeting the Requirements

Your Active Directory Domain Controllers need to run at least Windows Server 2003 with Service Pack 1.

Devices managed with the Local Administrator Password Solution (LAPS) need to run at least Windows Vista with Service Pack 2 (on client devices) or at least Windows Server 2003 with Service Pack 2 (on server devices). Both x64 and x86 versions of the above Operating Systems are supported, but Itanium-based devices are not supported.

To manage the Local Administrator Password Solution (LAPS), you will need to run .NET Framework 4.0 (or up) and PowerShell 2.0 (or up).

1. Extending the Active Directory schema

Because the Local Administrator Password Solution (LAPS) stores the local administrator password values in Active Directory, the schema needs to be extended by two new attributes:

  1. The first atrtibute is used to store the password of the built-in Administrator account for each device (ms-Mcs-AdmPwd)
  2. The second attribute is used to store the timestamp of password expiration (ms-Mcs-AdmPwdExpirationTime).

Both attributes are added to the may-contain attribute set of the computer class.

Extending the schema is done using a device that is equipped with the Local Administrator Password Solution (LAPS) Management PowerShell module. On this system use the following two PowerShell commands:

Import-Module AdmPwd.PS


In environments with Read-only Domain Controllers where you need to replicate the value of the ms-MCS-AdmPwd attribute, you will, additionally, need to change the 10th bit of the searchFlags attribute value for ms-Mcs-AdmPwd schema object to 0 (substract 512 from the current value of the searchFlags attribute) to add it to the Filtered Attribute Set.

2. Allowing devices to write passwords

The Write permission on the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes of all computer accounts has to be added to the SELF built-in account. This is also done using PowerShell, per Organizational Unit (OU):

Set-AdmPwdComputerSelfPermission -OrgUnit OU ShortName

Update-AdmPwdADSchema en Set-AdmPwdComputerSelfPermission in PowerShell (click for original screenshot)

You do not have to run this command for Organizational Units (OUs) that are subcontainers of configured Organizational Units (OUs).

3. Installing the Client Side Extensions (CSE) on devices

Since the Local Administrator Password Solution already comes as an *.msi file, it’s easy to distribute it using Active Directory Software Installation. The *.msi package contains a lot more tools that you don’t need or want on all devices, but its default installation procedure is to install the AdmPwd Client Side Extensions only.

When you deploy the Local Administrator Password Solution (LAPS) through MSI, you can modify the installation on management workstations afterwards, using the Programs and Features Control Panel applet (appwiz.cpl). LAPS will be listed as Local Administrator Password Solution from Microsoft Corporation.

To create a Group Policy object (GPO) to assign the Local Administrator Password Solution (LAPS) to domain-joined devices from a shared folder, perform these steps:

  • Log on with an account with sufficient privileges to create and/or modify group policy to a Domain Controller or a management workstation equipped with the Group Policy Management Console (GPMC).
  • In the Start Menu of Start Screen, search for Group Policy and then select the Group Policy Management Console from the search results. Alternatively run or search for gpmc.msc.
  • In the left pane, navigate to Group Policy objects. Right-click the container and select New from the context menu. Give the new object a meaningful name. Alternatively, edit an existing Group Policy object (GPO) that contains other software you assign.
  • Now, expand the Group Policy Objects node and select your newly created Group Policy Object. Right-click it and select Edit from the context menu.
  • In the left pane of the Group Policy Management Editor window, navigate to Computer Configuration \ Policies \ Software Settings \ Software Installation.
  • Right-click Software Installation and select New from the context menu and then click on Package… in the second context menu.
  • In the Open dialog window, type the full UNC path of the shared LAPS package you want to assign.
  • Click on the Open button.

Assign a software package for Active Directory Software Installation (click for original screenshot)

  • Click on Assigned and then click OK.
  • Close the Group Policy Editor to save your changes.

Now in the Group Policy Management Console, right-click every Organizational Unit (OU) containing computer objects, where you want to assign the Local Administrator Password Solution (LAPS) to, and Link an Existing GPO… to link the newly created Group Policy object (GPO).

Afterwards, close the Group Policy Management Console (gpmc.msc).

4. Delegating access

After we enable the Local Administrator Password Solution (LAPS), the passwords for the local administrator accounts on domain-joined devices will be stored in Active Directory. Every admin will have access to read this information. This might not be something you or your organization wants.

By default, members of the Enterprise Admins and Domain Admins groups have access to the attributes. Fortunately, you can granularly delegate access to the password values. You can even remove the Enterprise Admins and Domain Admins groups, although Microsoft didn’t test this scenario.

Again, you can use PowerShell to delegate read access to the password information:

Set-AdmPwdReadPasswordPermission -OrgUnit "OU ShortName" -AllowedPrincipals "users or groups shortname"

You can specify multiple groups and users in this PowerShell oneliner by separating them with commas.

To get information on the groups and users able to read password information for a specific Organizational Unit (OU), use the following PowerShell oneliner:

Find-AdmPwdExtendedRights -identity:"OU Shortname" | Format-Table

Set-AdmReadPasswordPermission and Find-AdmPwdExtendedRights in PowerShell (click for original screenshot)

Managing LAPS

With all the components in place, managing local passwords set by the Local Administrator Password Solution (LAPS) is pretty straight-forward.

Managing password settings

To manage the password settings for the Local Administrator Password Solution (LAPS), edit the settings in an appropriate Group Policy object (GPO). To manage these settings, LAPS need to be installed with the LAPS Group Policy Editor templates, or the LAPS Group Policy Editor templates need to be copied to a Central Policy Store.


There are four Group Policy settings located in Computer Configuration, Policies, Administrative Templates and then LAPS:

  • Password Settings
  • Name of the administrator account to manage
  • Do not allow password expiration time longer than required by policy
  • Enable local admin password management

To manage password settings, first, enable the Enable local admin password management Group Policy setting. Its default setting is Not Configured.

Then, open the Password Settings Group Policy setting and select appropriate settings for the local administrator passwords. Options include password complexity, password length and password age (in days).

The Do not allow password expiration time longer than required by policy Group Policy setting, when enabled, will make the Local Administrator Password Solution (LAPS) change passwords before they expire (as configured in the previous Password Settings Group Policy setting).

The Name of the administrator account to manage Group Policy setting allows you to manage custom local administrator accounts. You do not need to use this setting when you have renamed the local administrator account (LAPS detects the local administrator account using its RID). Instead, you can use this setting for any of your own local administrator account when you’ve opted for one and kept the local administrator accounts on devices disabled.

Reading passwords

Once everything is configured, and Group Policy has refreshed on targeted devices, (delegated) admins can look at the properties of computer objects and see the new settings.

The password is stored in plain text. The Expiration date is stored as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 untill the date/time that is being stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory

Now, of course, using the Attribute Editor in Active Directory USers and Computers (dsa.msc) or Active Directory Administrative Center (dsac.exe) is not the most useful way to read the passwords.

On management workstations equipped with the LAPS Fat Client User Interface (UI), a program is available labeled LAPS UI. Through this Graphical User Interface, a domain-joined device can be searched, after which its password information is presented in human-readable formatting:

The LAPS User Interface displaying the password information for PC1 (click for original screenshot)

Alternatively, you can use the Get-AdmPwdPassword PowerShell Cmdlet.

Resetting passwords

To manually reset the password click the Set button in the LAPS UI or use the Reset-AdmPwdPassword PowerShell Cmdlet.

Auditing read permission usage

The Local Administrator Password Solution (LAPS) also has granular accounting as a feature. Using PowerShell, you can enable auditing on principals when reading password information. Use the following PowerShell oneliner to this purpose:

Set-AdmPwdAuditing -OrgUnit "OU ShortName" -AuditedPrincipals "users or groups shortname"

When a password is successfully read, an event with Event-ID 4662 and source Microsoft Windows security is logged in the Security log of the Domain Controller.



With Pass-the-Hash (PtH) and Pass-the-Ticket (PtT) attacks being used to breach even the most secure networking environments, preventing lateral movement between domain-joined devices is welcome. Microsofts Local Administrator Password Solution (LAPS) presents a solution. It’s not perfect, but it’s something.

Further reading

Download Local Administrator Password Solution (LAPS)
Local Administrator Password Solution (LAPS) Now Available
Solution for management of built-in Administrator account's password via GPO
Local Administrator Password Solution (LAPS) from Microsoft
Microsoft makes Local Administrator Password Solution official
Microsoft Local Administrator Password Solution

30 Responses to Security Thoughts: Microsoft Local Administrator Password Solution (LAPS, KB3062591)


    So what happens when the computer leaves the domain and is Bitlockered? If you don't get the local admin password ahead of time are you screwed?

    • When you leave an Active Directory domain, you are prompted for the local administrator password to use in the workgroup.

      Additionally, it is a best practice to either store the BitLocker Recovery Information in Active Directory or on paper.


    We have implemented this solution in Windows 7 but we still have a few Windows XP machines where we need to implement this too.

    When we load GPOs, we are unable to get the admin template of LAPS.

    Please suggest !!

    • Unfortunately, Microsoft has released the free version of LAPS after the end of support for Windows XP.
      I understand remaining Windows XP installations would benefit most from these kinds of security solutions, but (the free version of) LAPS is not available for Windows XP.

      When you have an active Premier Support contract with Microsoft, you might be able to get access to a previous version of LAPS, that might still support Windows XP.


    So i still have to go round all the computers to create a custom administrator account, to control with LAPS, i can't do this through GPO any more??

    • Hi Gareth,

      Yes, Microsoft advises against using Group Policy (Preferences) to control local accounts and logins. Yes, When I have a mere guest account people can read local administrator passwords from GPOs with a simple script. Yes, Domain Controllers and Windows (Server) installations with RSAT configured, that have MS14-025 installed no longer allow you to set these passwords.

      No, you don't need to create a custom administrator account. With LAPS you can manage passwords for the built-in administrator or another/renamed administrator accounts of choice. No, you don't need to go round all the computers, since you can easily deploy the LAPS .msi file using Group Policy and set the specific settings through Group Policy, too. A (PowerShell) script to check for contents of the ms-Mcs-AdmPwd attribute of computer objects in scope. This will tell you if the solution is successfully deployed.


    Ok, thanks man.I have it msi'ing,
    Doesn't seem to install on win 10 machines, but i can figure that out; thanks for clearing things up for me.


    Hey what if i have 5 domain controllers in my organization so which one should i use to install LAPS. Can you please elaborate.

    • Hi John,

      It is certainly a best practice to run multiple Domain Controllers per Active Directory domain. Good to read you're doing that.

      In terms of deploying LAPS, only step 1 (Extending the schema) requires a certain Domain Controller. All the other implementation steps can be performed on any of the (non Read-Only) Domain Controllers.

      Extending the Schema should be performed on the Domain Controller holding the Schema Master FSMO role. The command netdom query fsmo on any of your Domain Controller will tell you which Domain Controller to perform the PowerShell Cmdlets on.

      I recommend installing the LAPS UI on the device you usually use to manage Active Directory. When you'd typically use Remote Desktop to a Domain Controller to manage Active Directory, install it on the Domain Controller. If you're using a Windows device running the Remote Server Administration Tools (RSAT) to manage Active Directory, install it on that device.


    Hello Sander,

    A common situation where the local administrator password is (temporary) required is where a computer is disjoined from the domain because the another computer is wrongly joined to the AD computer account of the concerned computer.
    I guess that with this LAPS solution the ms-Mcs-AdmPwd attribute is actually overwritten by last computer that joined the domain and therefore the prior password can’t be revealed anymore to rejoin the original computer to the domain.


    Does the schema upgrade create any conflict or any unwanted errors with the exchange server 2007 schema, and is this supported with exchange 2016?

    • Hi Hasan,

      The LAPS schema extension adds two new attributes (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime) to the computer class.
      The Exchange schema extensions do not directly touch the computer class. Therefore, the LAPS schema does not interfere with Exchange.

      However, you may have unpredicted results when you assign the LAPS policy to Exchange Servers.
      I would only deploy LAPS to domain-joined end-user devices.



    I recently installed LAPS in a test OU of my organization. All is working fine but it seems that a standard domain user can read the expiration date of computers/servers using the LAPS UI. Is it normal ?
    With an admin account, I'm able to read all attributes and change the expiry date.

    Thank you.



    How can I remove the Enterprise Admins and Domain Admins groups in DELEGATING ACCESS


    In reading the instructions for setting up LAPS, I understood everything could be run from a "management" station, including the schema upgrade (provided PS was run as a schema and enterprise admin). So that's the way I did it – from my workstation, not on one of our DCs, not specifically on the Schema Master. For my test OU, everything is working fine. Am I missing something?


    I know this is after a while, but is there any plans on a mobile device implementation of the FatUI so those of us who need to administer a local system can just pull the password to log in?


    I installed LAPS on a server 2016 TP5 DC server. At first, run Update-AdmPwdADSchema always got the error:

    Update-AdmPwdADSchema : An operation error occurred.
    At line:1 char:1
    + Update-AdmPwdADSchema
    + ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Update-AdmPwdADSchema], DirectoryOperationException
    + FullyQualifiedErrorId : System.DirectoryServices.Protocols.DirectoryOperationException,AdmPwd.PS.UpdateADSchema

    But the error disappeared after I checked the DC server. After many test I still could not figure out what the solution is. And I could not repro this in the other environments. What I want to know is, does anything additional need for a server 2016 TP5 OS to run LAPS?


    How do i unistall/disable LAPS from my domain?


    My 5 cents: be aware that when you install the LAPS agent on a domain controller, and you have the GPO configured, that it will reset the password of the administrator account for the domain (as Domain Controllers don't have local admin accounts).


    You may want to be careful applying the LAPS related ACLs. In our environment, the exchange admin console (ECP) throws errors whenever we open groups that are in an OU with ACLs for Read ms-MCS-AdmPwd applied – even though the permission does not apply to groups.


    Is there a way to install LAPS FatClientUI on PC's using GPO? Our techs are active on the floor and would prefer using "runas" themselves from the desktop to get proper Administrator credentials from AD when working on a PC.


    How secure are the passwords stored in ms-Mcs-AdmPwd?


    What happens if computer can't log into the domain (e.g., NIC issue) and the password in the AD has been changed? How can I login as a local administrator to fix the problem?


    Hello All,

    Can anyone shine some light on the error below? Yes, user is part of Enterprise and Schema admin group, and I also have registered schmmgmt.dll.

    PS C:UsersAdministrator> Update-AdmPwdADSchema
    Update-AdmPwdADSchema : An operation error occurred.
    At line:1 char:1
    + Update-AdmPwdADSchema
    + ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Update-AdmPwdADSchema], DirectoryOperationException
    + FullyQualifiedErrorId : System.DirectoryServices.Protocols.DirectoryOperationException,AdmPwd.PS.UpdateADSchema


    What happens to the AD stored local administrator passwords if you have Active Directory issues? How can you login to a member server while the domain is being restored or brought back online again? Also, what if a member server loses communication with the network and is disjoined from the network?


    We're having issues running the set-adminpwdcomputerselfpermission to assign to an OU. We have multiple OUs named "computers", which causes the command to fail stating "more than one object found". Even though we would install in on all computer OU anyway. It does work if we hit a root OU but then multiple OU's besides the computer OU gets hit. Looking for a workaround. Thank you.


    Hi Sander,

    I had deployed LAPS since 2017 April. It worked perfectly.

    Recently, some couple weeks ago, LAPS didn't work properly. After investigated, I found that two attributes(ms-Mcs-AdmPwd, ms-Mcs-AdmPwdExpirationTime) didn't show up when use comment get-adcomputer checked on new computer which was joined in Domain. The old Computer has still worked normally.

    I think that It caused LAPS agent couldn't update password to Active Directory.

    Please help me on this case.

    Hai Tran


    I've enabled auditing for LAPS password reads but 4662 events are noisy and don't all relate to LAPS. Is there an easy way to filter 4662 events to only those relating to LAPS password reads?


    You can even change the local administrator name and LAPS will still work.

    I have a dynamic script for it, which can change the administrator name dynamically.



    we have been using LAPS for last 1 and half years. recently a couple of our LAPS UI showing following error while retrieving passwords.

    "The LDAP Server is unavailable"

    please advice.

leave your comment

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