A look inside the Microsoft Local Administrator Password Solution

1 2 Page 2
Page 2 of 2

The solution

We now have an elegant solution available: the Local Administrator Password Solution, which may take the award for "Most Obvious Product Name Microsoft Has Ever Allowed Out Of Redmond." Essentially, the LAPS uses Group Policy client-side extensions to generate a random password on each individual domain member, and then it sets that random password for the local administrator account.

It then puts that randomized password into a confidential, secure (although not encrypted) attribute inside the computer's Active Directory computer account. The proper permissions are granted so the computer itself can change its own local administrator password data that is stored inside the Active Directory computer object, and domain administrators or delegated administrators can grant read permissions on this special attribute to workstation administrators, the help desk or anyone else that legitimately needs to be able to access the local administrator account on domain-joined machines.

To get started with it, download the LAPS MSI file; it is available in x86 and x64 editions. Then run the MSI file to install. On the first machine you run this, you should install all components, so that you get the management user interface as well as the GPO client-side extension. On all other computers, you just need the GPO client-side extension.

[New to PowerShell? Check out our downloadable beginner's guide here.]

You can also perform a silent install, perfect for scripting, using the following command:

Msiexec /i laps.x64.msi /quiet

Next, you have to update your Active Directory schema. While this is never a step to be taken lightly, these modifications are very minimal: Two attributes will be added to the current structure within the computer class of AD:

  • ms-Mcs-AdmPwd, where the actual password is stored
  • ms-Mcs-AdmPwdExpirationTime, where the time to reset the password to something different is stored

You can perform the schema update from PowerShell; open PowerShell as an administrator and then use the following cmdlets:

Import-module AdmPwd.PS


Next, you will need to adjust permissions for users and groups that should not have access to the password attribute. You specifically need to remove "All extended rights." Typically users don’t have this right granted but administrators do, and if you want the limit the scope of who can actually view the password, you’ll need to remove that right.

You can find a list of users who have this right in your PowerShell window:

Find-AdmPwdExtendedrights –identity [name of organizational unit]| Format-Table

If you need to adjust, then use the following steps:

  1. Open ADSIEdit from the Windows desktop
  2. Right-click on the relevant organizational unit and select Properties
  3. Click the Security tab, then click Advanced, and then select the users or groups that should not be able to read the password
  4. Click Edit, and then uncheck All Extended Rights

Now, you need to set up permissions so that the computers themselves can update that password attribute in Active Directory for their computer objects. You do this through PowerShell as well:

Set-AdmPwdComputerSelfPermission -OrgUnit [insert organization unit name here]

Next, use PowerShell to set up which users ought to be able to view the password attribute -- this is for your delegated administrators, help desk employees, and the like who need to be able to carry out their duties. Separate the users and groups with a single comma.

Set-AdmPwdReadPasswordPermission -OrgUnit [insert organization unit name here] -AllowedPrincipals [list relevant users and groups here]

Finally, give permission to those same users to force a password change on the local administrator account.

Set-AdmPwdResetPasswordPermission -OrgUnit OrgUnit [insert organization unit name here] -AllowedPrincipals [list relevant users and groups here]

You’re done with the back-end setup now. Next, you need to configure Group Policy. Set up a new Group Policy object within the Group Policy Management Console, and then edit it. Navigate to Computer Configuration\Administrative Templates\LAPS. Then:

  • Set the "Enable local admin password management" to Enabled.
  • Configure the "Password settings" setting however you wish; this is where you can choose the required complexity of the password.
  • If you have renamed a custom local administrator accounts, then enter the new name in the "Name of administrator account to manage" setting. Only use this if you have a custom local administrator account; if you have simply renamed the original inbox account, then leave this alone, as Windows will be able to detect it even through the rename.
  • Depending on your security preferences, you can enable or disable (or leave unconfigured) the "Do not allow password expiration longer than required by policy" setting.

The next time Group Policy refreshes, then the passwords will be managed. How do you view them? Via the LAPS user interface, a small utility that installs itself on the management computer. You can also view the password by looking at the properties of any computer object in Active Directory.

Evaluating LAPS

I see three main reasons why you should immediately begin deploying this. The overall benefits include:

  • It is free. You buy the Windows licenses, of course, but there is no additional charge for using the Local Administrator Password Solution. You can pretty well have it deployed in a day, too, so it costs very little in staff hours to get this up and running in your shop.
  • It does not require additional infrastructure servers. This solution plugs right into Active Directory and Group Policy, so it uses the same domain controllers and machines you already have and presents a negligible additional load on them. And since it is using standard in-the-box features, other management tools can play right into it without requiring reprogramming. It is truly a "drop-in" style answer to this problem.
  • It does not require new management software. Your existing identity lifecycle management software will work just fine. Software deployment scripts work just fine. Your processes and scripts and utilities for performing tasks on local machines that require administrative privileges will work just fine, too, because there is a password -- nothing has actually changed from the authentication and authorization perspective -- and once you have it, you are golden.

The last word

In some sense it is strange that we have finally found a nice, elegant way to solve a real problem that existed in a lot of deployments simply because of ignorance or inattention, or was solved in a horribly tedious brute-force way with Excel spreadsheets and lots of paid intern hours. But let us look on the bright side: The local administrator password solution is here. Overall, it is very inexpensive insurance to almost completely prevent an extraordinarily devastating attack that could take your organization down for weeks, months -- even permanently. Because it is free, I cannot commend it to you enough. Take a look and make a plan to start using it today.

You can download the Local Administrator Password Solution here.

Copyright © 2016 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Shop Tech Products at Amazon