What is the Local Administrator Password Solution?

Simply put, Microsoft’s LAPS tool randomises the local administrator account on each computer and stores the new password on the computer object in Active Directory.

Specifically, part of the installation process extends your Active Directory schema to include two new values:

ms-Mcs-AdmPwd

Stores the current Administrator password.

ms-Mcs-AdmPwdExpirationTime

Stores the timestamp (measured in 100-nanosecond chunks that have elapsed since 1st January 1601 (GMT)).

A DLL (AdmPwd.dll) is installed on each client which runs a check against the timstamp when a Group Policy refresh occurs to see if the password needs to be refreshed.

A Note on Interacting with LAPS (and a better solution than the ones provided by default)

The LAPS technology as it stands is mostly concerned with the action of randomly refreshing Local Administrator passwords. It has little concern for day-to-day usability, and as such it expects you to install either the AD client tools or the LAPS client utility (“Fat Client UI”) on each and every computer you want to be able to access the passwords from.

Naturally this is less than ideal, and should you need to access it from a mobile or non-Windows device, there are limited options available.

For this reason we have made OverLAPS available, which is a simple, self-hosted web interface for LAPS that allows multi-device, multi-operating system access to LAPS managed passwords, and makes it super simple to control who gets that access.

Installing LAPS

We’ll now go over the (relatively) simple installation process for LAPS. Note that we’ve brought up a development domain specifically for this purpose, and would strongly recommend anyone following this do the same before making schema changes to your Active Directory structure.

Step 1: Prerequisites

The current version of LAPS is 6.2 and is available from Microsoft’s website here.

(Note: Part 2 of this tutorial will also be going over the OverLAPS installation and configuration procedure as it provides a much more intuitive interface to LAPS, so we’ve grabbed the installer for that as well, see here)

You’ll also need a Domain Administrator or other account with permissions to modify the AD schema. The installation can be run from any domain joined computer or server.

Step 2: Installation

Launch LAPS.x64.msi (or LAPS.x32.msi if you’re in a 32bit OS).

The features we’ve opted to install here are:

AdmPwd GPO Extension

Installs the LAPS client for managing this devices password (as a Group Policy Object extension so that it can run during GPO update).

PowerShell module

Required for extending the AD schema and initialise configuration of LAPS.

GPO Editor templates

Installs the ADMX for enabling and configuring LAPS through Group Policy.

We have opted not to install the “Fat Client UI” because we’ll be using OverLAPS instead.

Step 3: Active Directory Schema

The next step is to extend the AD schema with the two new computer object properties. To do this, we’ll need PowerShell (running as a Domain Administrator or another user with the rights to modify the schema).

Start by importing the LAPS AdmPwd.PS module, which contains all the tools we’ll need today.

Next, run the command to update the AD schema. If everything goes to plan, you should see “Success” all the way down the Status column.

Step 4: Check Existing Permissions

Now before we do anything else we need to secure Active Directory to make sure only people/services we allow can access the new properties. We can do this from within PowerShell by using the command “Find-AdmPwdExtendedRights” with the root OU for your computer objects (in our case a container called “ManagedDevices”)

We can see from this that only SYSTEM and Domain Admins have access to these OUs, but if you notice any groups you don’t want here (for example “Authenticated Users”, which would indicate all logged in users have access), load ADSI Edit and find the root OU for your computer objects.

Right click this and go to Properties -> Security, then click the Advanced button. Select the “Authenticated Users” (in this example) principal and click Edit.

Make sure that “All extended rights” is unchecked. Then click OK to apply the change.

Step 5: Allow Computers to Record their Password Changes

Now your computers will need to the rights to change the password and expiry values from the LOCAL SYSTEM account. Back in PowerShell, use the Set-AdmPwdComputerSelfPermission command to apply this permission to computers in your root computer OU.

This will add two new ACLs to the container for the “SELF” account, one for writing a new password, and another for reading/writing the expiration timestamp. Note that the account does not have read access to the password.

Step 6: Configure LAPS Group Policy

We go into greater detail on the individual policy settings in our post A Look at the Microsoft LAPS Group Policy Settings, but a brief overview of these are included below.

Define a new Group Policy Object linked to the root Computer container and navigate to Computer Configuration -> Policies -> Administrative Templates -> LAPS.

Password Settings

Allows you to configure the compexity, length and maximum age of LAPS managed passwords.

Name of administrator account to manage

If you’ve renamed your Local Administrator accounts, you can use this setting to specify the new name. (Take a look at our article Local Administrator: To Rename or not to Rename for our views on this).

Do not allow password expiration time longer than required by policy

Setting this tells LAPS that a password expiry longer than the one defined in “Password Settings” is not allowed (if being set manually). This prevents users with write access to the timestamp from setting it to a year in the future (for example) when the password policy clearly dictates it should reset every 7 days.

Enable local admin password management

The master switch for LAPS. Enabling this enables Local Administrator password management.

Step 7: Distributing the LAPS “Client”

The LAPS AdmPwd.dll CSE (Client-Side Extension) must now be distributed to all managed computers and registered. You have a number of options for achieving this, but we’ll concentrate on the two most common ways.

1. Group Policy

One simple method is to place the DLL on a share and have Group Policy copy the file to each computer, and use a startup script to register it.

I’ve worked in environments before where the proliferation of complex GPOs caused massive slow-downs however; and as the DLL really doesn’t need to be registered on every system startup, this may not be the best solution.

2. MSI

You can also simply run the LAPS .msi installer on your clients with the “/quiet” parameter. By default only the CSE is installed.

Your choice of how to do this depends very much on your environment: maybe you’d use SCCM or a similar technology. We opted to use our own Overcee suite though as I suppose you could say we’re experts in that technology.

For a more detailed look at setting up a custom tool like this in Overcee, please see our post titled “Tutorial: Privilege Escalation Vulnerability Scan Tool and Overcee“.

Installation Complete

That’s it for LAPS. Your computer’s administrator accounts may not change right away, but pretty soon you should see them starting to update.

What’s Next?

Head over to Part 2 of this article where we set up a funky web interface for LAPS so that we can access from any device while on the go.