Set up Microsoft LAPS (Local Administrator Password Solution) in Active Directory

• Author
• Recent Posts

Kyle Beckman

Kyle Beckman works as a systems administrator in Atlanta, GA supporting Office 365 in higher education. He has 17+ years of systems administration experience.

Latest posts by Kyle Beckman (see all)

• Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
• Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
• Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016

To set up the Microsoft Local Administrator Password Solution (LAPS) in Active Directory, you’ll first need to download LAPS from the Microsoft Download Center. You’ll want to download both the LAPS.x86.msi (for 32-bit systems) and LAPS.x64.msi (for 64-bit systems).

On my domain controller, I’m going to run the 64-bit installer, LAPS.x64.msi. After clicking Next for the first two screens and accepting the license agreement, you’ll need to ensure that the Management Tools (but not the AdmPwd GPO Extension) are set to install on the server.

Local Administrator Password Solution custom setup options for server

After a few more Next clicks, the LAPS management tools are installed on the server. If you go to the Start screen, you should see the new LAPS UI, which I’ll cover a little later.

LAPS UI on Start screen

Next, we’ll need to open a PowerShell window with Admin rights. At the PowerShell prompt, load the LAPS module and then run the Update-AdmPwdADSchema cmdlet:

Import-Module AdmPwd.PS
Update-AdmPwdADSchema

When you’re done running the commands, you should get three “Success” messages:

Extending the Active Directory Schema to support LAPS

Update user/group AD permissions

After updating the Active Directory schema, we need to check permissions in AD to ensure that only authorized users and groups can view the passwords that are stored there. By default, Domain Admins and Enterprise Admins will have access to view the stored passwords, along with any other groups or users you’ve delegated. First, open a PowerShell window and ensure that the AdmPwd.PS module is loaded. We can then use the Find-AdmPwdExtendedRights cmdlet to view which users and groups have access to view stored passwords:

Import-Module AdmPwd.PS
Find-AdmPwdExtendedRights –Identity "_Demos"

Find-AdmPwdExtendedRights output example

As you can see in the screenshot above, I don’t have any users that shouldn’t have access in my AD environment. If you do have users that shouldn’t be able to view the stored password information that show up in “ExtendedRightHolders,” you’ll need to remove their access to “All extended rights.” In Active Directory Users and Computers (ADUC), click View and ensure that you have Advanced Features checked. Right-click the OU name and then click Properties, Security, and Advanced.

Editing advanced permissions in Active Directory Users and Computers

Next, select the group (or user) that should not have access to view the managed Administrator passwords and click Edit. Clear the All extended rights check box. Click OK twice to save the change.

Removing access to all extended rights

If you want to give additional groups access to view the passwords, you can use the Set-AdmPwdReadPasswordPermission cmdlet to give users or groups the ability to read the attributes:

Import-Module AdmPwd.PS
Set-AdmPwdReadPasswordPermission –Identity "_Demos" –AllowedPrincipals "Help Desk"

Using Set-AdmPwdReadPasswordPermission to delegate additional groups

Update computer AD permission

Last, we’ll need to give the computers the ability to update the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes in Active Directory. Start by loading the module again (if you don’t already have it loaded) and running Set-AdmPwdComputerSelfPermission:

Import-Module AdmPwd.PS
Set-AdmPwdComputerSelfPermission –Identity "_Demos"

Using Set-AdmPwdComputerSelfPermission to give computers write access to passwords

You’ll need to run this for each OU that will have managed computers but not the sub-OUs because the new permissions will apply to the sub-OUs.

At this point, our Active Directory infrastructure is configured to support the new Active Directory attributes and permissions for those attributes. In the last part of this series, I’ll cover setting up the clients and configuring the Group Policy for LAPS.