In Part 2 of our series on Microsoft LAPS (Local Administrator Password Solution), I’ll show you how to update your Active Directory schema to support LAPS and configure permissions for both computers and admins.

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.

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

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

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:

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

Extending the Active Directory Schema to support LAPS

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:

Find-AdmPwdExtendedRights output example

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

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

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:

Using Set-AdmPwdReadPasswordPermission to delegate additional groups

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:

Using Set-AdmPwdComputerSelfPermission to give computers write access to passwords

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.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

0
Share
6 Comments
  1. Meng 3 years ago

    Hi,

    We changed LAPS' password length policy from 16 characters to 10 characters.

    When will this new password length of 8 characters apply on domain-joined workstations? We have updated the GPO more than 10 days now, and unless we forced a Password reset, computers still have 16 characters.

    Please shed some lights.

    thank you

    0

  2. bubu 2 years ago

    Do I need to install LAPS on Domain Controller?

    3+

    • Unknown 10 months ago

      no, just put the ADMX templte on the gpo container

      0

  3. Vik 2 years ago

    I want to restrict extended rights for our support desk staff.

    When I run Powershell to identify who has access to this password, I see domain admins only.

    However our support staff can still see this password.

    I have checked nested group already and do not see any issue there. What am I missing here...

    0

  4. MGauvreau 1 year ago

    Is it possible to restrict Set-AdmPwdComputerSelfPermission to a group of computers, and not to a whole OU? My organization has several OUs that contains computers object.

    Thanks in advance

    0

  5. jack Tors 6 months ago

    Great article, I wouldnt install LAPS client or management tools on domain controller (NOTE - it will try to manage the built-in administrator account). Instead install it on a workstation with DA and Schema Admin rights (remove after) Install all the management tools and then copy these files to your server (below) to update the AD Policy Store

    Copy C:\Windows\PolicyDefinitions\AdmPwd.admx to \\yourdoamin.local\sysvol\yourdomain.local\Policies\PolicyDefinitions\

    Copy C:\Windows\PolicyDefinitions\en-us \AdmPwd.adml to \\yourdomain.local\sysvol\yourdomain.local\Policies\PolicyDefinitions\en-us

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account