MS Local Administrator Password Solution. Part 1

In May 2015 Microsoft released Local Administrator Password Solution (LAPS) to help address the issue of keeping local administrator accounts secure. Setting the account password by GPO generally means a large number of computers will have the same password.

LAPS provides the ability for workstations to have randomly generated passwords, that are constantly refreshed and easy to retrieve. Managed workstations will set a random password which is stored in an AD attribute called ms-Mcs-AdmPwd. Passwords are automatically changed according to GPO settings. Using additional AD attributes means for LAPS to work, a schema extension is required.

LAPS can be downloaded from There are two MSI installers for LAPS, one for 64 bit and one for 32. Download both, as the MSI files will be used for client deployments and supplying the management tools.

On to the installation

The first step for installation is to make sure you AD environment is healthy and replication is working. MS have also released a tool to help determine the health of AD replication.

The installer has two component sections. The Client Side Extension (CSE), this is to be installed on the workstations to be ‘controlled’; or ‘managed’;. The management tools, these are used to view set passwords, extend schema, set permissions and GPO templates to apply settings.

Install management tools on the computer you are going to use for the setup / management of LAPS. Management tools will also need to be installed on computers of people who will be checking the passwords.


Setting up AD

Providing AD health is good, we can be on to setting up AD. This is going to be done in PowerShell. The first test is to import the new modules.

Import-Module AdmPwd.PS

Now update the Schema, you have had change control approval, right??


All going well you should get similar output

AD Schema

The next stage of configuration is to set up correct permissions to the new attributes. We want computers to be able to update the attributes, but we don’;t want unintended users to be able to see the values in those attributes. This requires making modifications in ADSIedit, while the process is straight forward this is one of those times where if you think you need to ask, ask.

First, we are going to remove the ability to see extended attributes for security principals that shouldn’;t see them

Launch ADSIedit.msc and connect to the Default Naming Context


Find the OU which contains computers that are going to have their passwords set using LAPS. Right click > Properties > Security > Advanced. For each non-administrative group, edit the permissions and make sure “All Extended Rights” is unchecked.

Group Rights

Depending on the OU structure, you may need to repeat this step for the relevant OU’;s.

It’;s now time to set permissions allowing computers to set their password.

The permission change is recursive. Looking at the OU structure below, if I had computers in all OU’;s and want to make the permissions change for all of them. I only need to run the command against OriginalOUName and the rest will be granted the permissions.

OU Structure

The command is

Set-AdmPwdComputerSelfPermission -OrgUnit "OriginalOUName"

We can verify the command worked, show that the recursive nature of the command and principals with rights to view the passwords by running

Find-AdmPwdExtendedRights -Identity "OrgininalOUName" | FL

Extended Rights

To allow more people, such as non-domain admins, to view the passwords run

Set-AdmPwdReadPasswordPermission -Identity "OriginalOUName" -Allowed Principals "Ticket Ninjas"

That’;s all for this section of setting up LAPS. In the next part, I’;ll cover off deploying to client computers via GPO, GPO settings and how to view the passwords.

Part2: Client deployment