Deploying Microsoft LAPS

As a summary, LAPS is the Local Administration Password solution from Microsoft. This software changes the local administrator password on a selection of machines on a schedule and stores that password in plain text in Active Directory.

The first time I came across LAPS was when I hear about project Honolulu and I’ll admit that I hadn’t heard about it before which is something of a shame because LAPS is one of those very handy little add-ins that Microsoft should be offering as part of the core AD experience.

For those who haven’t come across LAPS before, LAPS is a handy tool for scenarios where you need to change or set the local admin password to something random because you need to give out that password. The two scenarios that immediately come to mind for something like this are:

1. Travelling laptop users – If you’ve ever had a need to hand out the local admin password to a traveling sales rep then you know that pains that can be associated with this. LAPS can be a very nice way to reduce the impact of such a need.
2. User provisioning of private cloud servers – Much like how AWS and Azure set a random local admin password and present that to you, LAPS can do this quite nicely.

Before I go into detail on how LAPS works, there are a couple of downsides as well:

1. It’s GPO based so password changes to the local password, even scheduled ones happen on a GPO refresh which could be several hours from when you need it to happen.
2. As per point 1, LAPS, being GPO based means that any new build machines need to auto-join your domain and if they can do that you can use GPO’s to push out local admin groups based on the OU so that your users never need to know the local admin password.
3. If you’re thinking of using LAPS for internal AWS type scenarios, LAPS needs the computer joined to the domain and in an OU where it has delegated rights. If your unattended build script sets the computer name, you’ll have an AD OU full of random computer names. This can be mitigated a little by pre-staging the computer name and using WDS or another deployment tool to read that but that’s probably for another article!

In short, all LAPS does is use a DLL called by a GPO to set the local administrator password to something random and then it stores that password in plaintext in Active Directory so that it can be read by applications or retrieved by helpdesk user.

At first, this may sound like something of a security risk but that has been taken into account as there are a couple of PowerShell commands that can be used to restrict who has access to what plus there are the extended rights permissions in AD

LAPS is an interesting little project from Microsoft, it’s largely PowerShell based and it requires Windows 2012 R2, not for any particular features but because the PowerShell elements need the AD extensions that come with Windows 2012 R2 and above.

Getting LAPS setup and working can be a little fiddly because there are several PowerShell commands and a GPO to set as well as the deployment of the admpwd.dll file on computers that you want LAPS to control the local admin password on.

In short, the setup process is this:

1. Download the MSI from https://www.microsoft.com/en-us/download/details.aspx?id=46899.
2. Decide which OU (or OU’s) you want LAPS to control the local admin password on.
3. Decide which group will have the ability to see and set the local admin password. For this, I created a domain local group called LAPS admins and made domain admins a member.
4. Perform a full install of the MSI you downloaded in step 1. This MUST be on a Windows Server 2012 R2 domain controller, the domain functional level doesn’t have to be 2012 but the DC does because it has the required PowerShell AD elements to make it all work.
5. Extend the Schema with the commands:

Because the schema needs to be extended for LAPS to work, the account you use must be an enterprise or schema admin and your schema master role needs to be online and available.

6. Give the OU you choose in step 2 permissions to set its own local admin password

Note that OrgUnit is that it’s one of the few LAPS PowerShell commands that doesn’t need to full path to the OU in question, just the name of the OU itself.

7. Set the ability for the group you selected in step 2 to be able to read and request a reset of the local admin password

8. Set up the GPO to control the local administrator password policy.

Included in the setup files is an ADMX file that needs to go into your central policy definitions store. Once that is done, you can launch the GPMC and you’ll see the LAPS section under computer configuration -> Policies -> Administrative Templates -> LAPS.

There are four options:

The password settings allow you to set up what characters the password will use large letters, small letters, numbers and special characters.

The “Name of administrator account to manage” is not configured on my system because my local administrator account is the default administrator. Even if you rename administrator you do not need to set this option as renamed administrator accounts still have the same SID (-500 which is why renaming accounts is not a good method for stopping hackers). Only if you create a new administrator account and disable the original should you use this option

The third option I thought was a bit strange “Do not allow password expiration time longer than required by policy”. If I’m setting a policy, then I want that policy to happen when I expect it to happen.

The last option “Enable local admin password management” has to be enabled because that basically enables LAPS to do its thing. Once the policy is set it needs to be linked to the same OU’s that you set up back in step 2.

9. Finally, install the DLL on a machine you want LAPS to change the local admin password on, this computer will need a computer object in the OU you’ve selected above.
   Once done, just wait for the GPO refresh and it should all work, I did do a “gpupdate /force” on a test box and that brought down the policy just fine.

The LAPS password UI can also be installed locally so if you’re using LAPS for your traveling laptops, maybe this is a good tool for the helpdesk admins to have. By setting up a LAPS admins group all they need is to have their usernames in that group and a copy of the LAPS UI installed locally.

There is also the PowerShell command Get-AdmPwdPassword -ComputerName <computername> which may be handy for the more automated type deployments.

All in all, I quite like LAPS. It’s a little fiddly to get set up and the operations guide does a decent job in explaining it all. Where I tripped up at first was that I didn’t realize that the admpwd.dll file needed to be installed on all machines that I wanted LAPS to control. Once I’d done that it all worked fine.

Related materials:

5 tips to help you explore the world of PowerShell scripting

Useful tips for setting up Microsoft Active Directory Domain Controllers