LAPS deployment

What is LAPS and why I need it

In windows domain based environments accounts with domain admin rights should be protected by all means. We all know that those accounts have the greatest privileges in the domain. There are other accounts that should be kept secure as well. Sean Metcalf has a great article about it. He is a Great Fountain of Knowledge about Active Directory!

But what many admins tend to forget is that the domain based computers also have local accounts that can be used in attack or lateral movement. It isn’t uncommon to have a local Administrator account with the same password on many machines (think mass deployment from WDS, VM templates). Some change the default name of the Administrator account but that’s not enough – it can be easily enumerated using SID (Well-known security identifiers in Windows operating systems).

Back in 2015 Microsoft has released LAPS – Local Administrator Password Solution. Jessica Payne has a great writeup describing what is LAPS and what it’s not. I really recommend reading it very carefully. Also, there’s a great TechNet article with more details here.

It’s been over two years since this is available for free for everyone. Yet I haven’t seen this implemented anywhere. I’ve heard the tales, yet no proof. Recently I had to deploy a new domain. With this came the opportunity to automate the deployment of LAPS as well. I’ve created a small script that will help with the process. With it I can easily perform all steps – which is great even for building test environments.


Before we dive in I’d like to step through the necessary steps:

  1. Prepare Active Directory
    1. Extend AD scheme
    2. Prepare OU for computers’ objects with necessary permissions
    3. Prepare delegation for designated groups of people to read the passwords
  2. Deploy application to the endpoints (workstations and servers) – either through Software Deployment products (like SCCM) or through GPO. I will be using GPO.

Basically, LAPS is a Group Policy Client Side Extension (CSE) that sits on endpoints. Occasionally (this is configurable) it changes specified administrator account password and stores it in its Active Directory computer object property ms-Mcs-AdmPwd. This is an extended attribute so not everyone can read it.

Get the LAPS files

This isn’t rocket science – simple web search will point you to Microsoft site with LAPS installation files. But hey, remember we’re automating? With these few lines, we can have all necessary files fetched for us. The last line will also install only management modules on the station we’re running the code from.

Prepare AD groups and FileShare

First, let’s create all necessary groups. This means we will need:

  • Two groups that will have read and full access rights to a file share which will be used in GPO – based installations.
  • Two groups with permissions to read password attribute from Active Directory – respectively for Workstations and Servers

Now, let’s create a file share and copy all files to the remote location. Then let’s clean up local temporary files:

Extend AD

To extend AD scheme the account must be in “schema admins” group. Make sure you’ve got that sorted out before you proceed.

Every time you need to extend Active Directory you should have a strong business need behind it. Remember to create AD backup and document the change. Then brace yourself for a very hard task. This time it’s this hard:

Phew, this wasn’t hard at all 😉

Check OU Permissions

What is the point of storing the passwords to all machines in AD if everyone could read it? To make sure only required groups can read the extended attributes we run this code:

The output should look similar to this:

Alter OU permissions

Now, we need to:

  • grant computers the right to modify their own AD object with password property
  • grant proper groups permissions to read these attributes

Endpoint deployment

We’re nearly done. The last step is to deploy LAPS to endpoints. As stated before I’ll be using GPO. There are some caveats to have in mind with this type of deployment:

  • Software installation will trigger only before user is logged in (link)
  • Therefore, it requires network access before user logging in
  • Computer account is used to access network share to get installation files (link)

As this is a small deployment I’m using single Group Policy Object to both install and configure LAPS. It could be easily split into two different parts though.

LAPS configuration through GPO

To be able to configure LAPS through GP, we need to have the admx templates installed on the machine from where we will create a GPO. This was done when we first downloaded and installed the files. Create a GPO, link it to the OU where computer objects are stored, edit and navigate here: Computer Configuration \ Policies \ Administrative Templates \ LAPS. Basically, there are only a handful of options here which are self-explanatory. I’ll be using Enable local admin password management . If you want to manage the passwords of different account than ‘Administrator’, just enable and edit Name of administrator account to manage. As far as I know, you can only manage one account per computer object – because there’s only one ms-Mcs-AdmPwd property for a computer object. Also, only one account name per GPO. If, for example, you have different default local administrator name for workstations and servers – you will require two Group Policy Objects to cover that.

LAPS deployment through GPO

To install LAPS through GPO, I’ll be using Software Installation options that can be found here: Computer Configuration \ Policies \ Software Settings \ Software Installation.

Remember that software installation will occur only during machine logon time and only if network is connected and share is available. If there will be issues with this, an event log like this will be recorded:

followed by

We can edit Computer Configuration \ Policies \ Administrative Templates \ System \ Logon \ Always wait for the network at computer startup and logon and forcing Windows to wait for network connectivity before processing any GPO, but that can extend logon time, especially when users often work remotely. I use it for OUs where servers’ computer objects are stored.

Once the app is installed it requires some time before changing the password and propagating it to AD. The CSE only runs at Group Policy refresh cycles.

Reading the password

OK, we have everything set up and configured. Our workstations and servers are happily grabbing GPOs and installing LAPS. What’s next? How to get the password? There are various ways to achieve that.

  • We can simply use ‘Active Directory Users and Computers’ snap-in and then ‘Attribute Editor’ tab.

  • We can use the fat client – LAPS UI application that get installed with management tools.

  • We can also use PowerShell to retrieve the password using simple command.

LAPS auditing

In the next part I’ll cover LAPS auditing. How to enable logging of security events who accessed which machine’s password. If you’re interested – please stay tuned.


LAPS is not a silver bullet. It’s not a magic pill that will fix everything. LAPS is designed to help in randomizing local administrator password in a domain environment. This is an important step that you can implement for free. This is a first step to a multilayered, complex defense strategy we should deploy to protect our network from adversaries.


9 thoughts on “LAPS deployment

  1. But why? I don’t see the need or point to implement a not that easy solution to do something for no reason at all. What is the point? I can reset passwords on local accounts without all the fuzz (even random per script any time). I can also turn off the local admin account. So again what is the reason for your article?


    1. Sure You can do IT with a script. Either running somewhere on a management server and targeting endpoints or as a part of a login script. Then it will have to store the passwords somewhere secure. The overhead of maintaining it and troubleshooting is increasing greatly with the growth of the number of endpoints. This does that all for You running as part of your domain environment (processing GPO). Disabling local accounts is not always recommended or possible (think loss od network connectivity or a remote user or a critical resource – HyperV server).
      As I pointed out – this is not a Cure to all. This is to help lower the attack surface and/or lower maintenance time.
      What I wanted to show is how to automate the deployment process to make it repeatable – the whole point of automation.
      Whether You deploy LAPS or not – that’s another question. Though I highly recommend it. It’s free. It helps make your domain more secure.


    2. LAPS is a solutions to resolve a certain issue. Not in every environment it is possible to disable local accounts. Not everywhere it will be scalable to script. When You need local accounts and want to randomize passwords and store then safely – You can script it and maintain it later oraz You can use this. There is no forcing. There is no “one size fits all”.
      And LAPS is super easy to idę and deploy. Whether its 10 computers or 1000s.

      And this article is to help deploying when You need LAPS.
      It doesnt answer the question – why. This is the answer everyone has to answer themselves.


  2. There is also a Fairley big issue with LAPS and the confidential attributes that LAPS creates in AD. If you provision or Stage computers to be added to a domain with different domain based accounts, those account also have the ability to see those confidential attributes that are stored in AD. Here is a link to a MS article that mentions this:
    MS recommend that all computers are joined to a domain by using 1 account (ie SCCM). To me this is a risk that MS are not willing to change which is why we did not want to use LAPS.


  3. Thanks for the well documented process I feel this is better than having Localadmin accounts assigned by SEc groups on local devices .


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s