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 domain based computers also have local accounts that can be used in attack or lateral movement. It isn’t uncommon to have 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 blog post 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 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:
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.
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.
First, let’s create all necessary groups. This means we will need:
Now, let’s create a file share and copy all files to the remote location. Then let’s clean up local temporary files:
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 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 ;)
What is the point of storing 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:
Now, we need to:
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:
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.
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.
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:
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.
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 different ways to achieve that.
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.