Secure Local Administrator Accounts with the Local Administrator Password Solution (LAPS) Tool

Microsoft’s Local Administrator Password Solution tool was released May 1st 2015, and consists of a Group Policy client-side extension (CSE) that enables organizations to manage local administrator account passwords on domain servers and workstations by automating regular password changes and storing them in Active Directory. In this article, I’ll explain why you should use LAPS, how it works, and show you how to set it up.

The Problem with Local Administrator Accounts

It’s not uncommon for local administrator accounts to be configured with the same password across all devices in corporate environments, leading to the possibility that if an attacker were to discover the password, every device could be compromised.

Some organizations manage this risk by manually renaming the built-in administrator account, setting a random password, and recording that information in a spreadsheet. But that doesn’t address the issue of changing the passwords periodically. Others go a step further, and disable the built-in administrator, creating a new administrative account on each device.

While there are third-party solutions that can help mitigate the threats posed by unmanaged local administrator accounts, Microsoft’s LAPS tool, which can be downloaded free here, presents a solution that randomizes passwords every 30 days, or a period of your choice, and stores them securely in Active Directory for each computer account.

Sponsored Content

Maximize Value from Microsoft Defender

In this ebook, you’ll learn why Red Canary’s platform and expertise bring you the highest possible value from your Microsoft Defender for Endpoint investment, deployment, or migration.

Download and Install LAPS

Follow the instructions below to install LAPS on a management computer. Log on to the computer as a local administrator. In this lab, I have one member server (contososrv1) located in the Member servers Organizational Unit (OU).

Secure Local Administrator Accounts with the Local Administrator Password Solution (LAPS) Tool
Installing the Local Administrator Password Solution (LAPS) tool (Image Credit: Russell Smith)
  • Run the downloaded LAPS.x64.msi or LAPS.x32.msi package, appropriate for your device’s architecture.
  • Click Next on the welcome screen.
  • Accept the terms and conditions on the End-User License Agreement screen, and then click Next.
  • If this a device from which you intend to manage LAPS, make sure that the Management Tools, including Fat client UI, PowerShell module, and GPO Editor templates, are also checked for install before clicking Next on the Custom Setup screen.
  • Click Install to complete the process, and then Finish.

Managed Computer Installation

To install LAPS on a managed computer, repeat the above procedure without adding the management tools on the Custom Setup screen. Alternatively, you can run a silent install from the command line if you want to automate installation, replacing c: with the folder path where LAPS.x64.msi is located.

Extending the AD Schema

Before the tool can be used to manage passwords, the Active Directory (AD) schema must be extended. Two new attributes are required, ms-MCS-AdmPwd and ms-MCS-AdmPwdExpirationTime, which store a device’s local administrator account password, and the time when it should be reset. Both are added to the computer class may-contain attribute set. Note that once you’ve updated the schema, you cannot undo the changes.
Updating the AD schema (Image Credit: Russell Smith)
Updating the AD schema (Image Credit: Russell Smith)
LAPS contains a PowerShell module to update the AD schema automatically. Remember that you must be logged in as a Schema Administrator to update the schema. To import the module and update the schema, open a PowerShell prompt and run the following two cmdlets:
If you have any read-only domain controllers (RODC) in your domain, and you want to replicate the two new attributes to those DCs, you’ll need to add them to the attribute set that gets replicated to RODCs. For more information on that process, see Modify the Read-Only Domain Controller Filtered Attribute Set Using ADSI Edit on the Petri IT Knowledgebase.

Setting Permissions for the New Attributes

There are several different access requirements for the new AD attributes that you need to consider.

Machine Rights

The first is giving devices permission to write to the new attributes. This is done using the Set-AdmPwdComputerSelfPermission PowerShell cmdlet that’s part of the AdmPwd module imported above. The –OrgUnit parameter should be followed by an OU name. If the specified OU contains other nested OUs, you don’t need to specify them individually as the command sets permissions recursively, as is the case with all the cmdlets included in the AdmPwd module.
Setting machine rights and finding who has 'All extended rights' (Image Credit: Russell Smith)
Setting machine rights and finding who has 'All extended rights' (Image Credit: Russell Smith)

All Extended Rights

Next let’s determine which users and groups have the All extended rights permission on the OU. Users with this permission have the right to read confidential attributes. Again, we can use a cmdlet that’s part of the AdmPwd module to achieve this:
In my domain, only Domain Admins and SYSTEM have this permission, so I don’t need to make any changes. If you do need to remove the All extended rights permission for specific users or groups from the OU, ADSI Edit is the right tool for the job and can be found on the Tools menu in Server Manager.

User Rights

Finally, decide which users and groups need to be able to read the contents of the new attributes. For example, helpdesk users might need access to the local administrator password. Again, the AdmPwd module contains a command to set rights on a given OU. In the cmdlet below, you can see that I’ve specified two domain groups, helpdesk and passwordadmins. Don’t forget to replace contoso with the name of your Active Directory domain.

Create a Group Policy Object

Now that all the prerequisites are in place, all I need to do is configure the LAPS settings in a Group Policy Object (GPO), and apply it to my Member Servers OU. For more information on creating and linking GPOs, see How to Create and Link a Group Policy Object in Active Directory on Petri.
Configuring LAPS settings in Group Policy (Image Credit: Russell Smith)
Configuring LAPS settings in Group Policy (Image Credit: Russell Smith)
The LAPS Group Policy settings are located under Computer Settings, Policies, Administrative Templates in the Group Policy Object Editor. There are four settings:
  • Password Settings
  • Name of administrator account to manage
  • Do not allow password expiration time longer than required by policy
  • Enable local admin password management
The Enable local admin password management setting must be set to activate LAPS on the managed computer. Password Settings allows you to configure password complexity, length and age. By default, LAPS uses maximum password complexity, a 14-character password length, and a password change every 30 days. You only need to enable the Password Settings policy if you want to change these defaults.
Changing the default password settings (Image Credit: Russell Smith)
Changing the default password settings (Image Credit: Russell Smith)
If you intend to use LAPS to manage the password of an account other than that identified by the well-known SID of the built-in administrator account, then you need to specify the account name in this policy. If you have renamed the built-in administrator account, there’s no need to enable this policy. Enabling the Do not allow password expiration time longer than required by policy setting strictly enforces the age of the local administrator account’s password. I.e. it is not allowed to drift beyond the specified age limit and is changed immediately should that occur.

View the Password Stored in Active Directory

Once you have a LAPS policy applied to an OU, and Group Policy has refreshed on computers in scope, users that have permission can view the passwords stored in Active Directory. The easiest way is to use the Get-AdmPwdPassword cmdlet included in the AdmPwd PowerShell module installed as part of the LAPS management components.
Alternatively, there’s a GUI tool (AdmPwd.UI.exe) included in the install package, located in C:\Program Files\AdmPwd\

The LAPS Fat UI shows password objects and expiry information stored in Active Directory (Image Credit: Russell Smith)
The LAPS Fat UI shows password objects and expiry information stored in Active Directory (Image Credit: Russell Smith)

Troubleshooting LAPS

If you run into any problems with the LAPS CSE, events are logged to the local computer’s Application log, and the level of information can be tuned on the local device by configuring the ExtensionDebugLevel registry value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}}\. 0 is the default value and logs errors only. 1 logs errors and warnings, and 2 is verbose mode and logs everything. If you set ExtensionDebugLevel to anything other than zero, don’t forget to set the value back to zero once you’ve finished debugging. The registry can be modified using the Registry Editor (regedit) tool in Windows 8 and Windows Server 2012, but remember that accidental changes to the registry can render a system unusable, so always have a backup before using this tool.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

IT consultant, Contributing Editor @PetriFeed, and trainer @Pluralsight. All about Microsoft, Office 365, Azure, and Windows Server.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: