Securing Local Privileged Accounts in Active Directory

We recently talked about how we go about securing the execution of untrusted code on our endpoints by defining a Software Restriction Policy. Once we’ve got this base covered, from a security perspective, we now need to take the next steps towards securing our local systems.

Local administrator accounts – the challenges

Every Windows system has a local administrator account. We’ve moved on from the days where every user was a local administrator – or we should have! – and it is usually pretty standard practice in enterprise environments these days for administrators to have a non-admin account for day-to-day work, and an administrative account that they use on occasions they require elevation. This “separation of duty” is pretty much standard practice – but that single local administrator account remains. And in a lot of cases, this local administrator account would often have a single password – which meant that if it was exposed, every single machine on your domain would be at risk. If the password hash was compromised, it could be used in a Pass the Hash (PtH) attack without needing to perform a brute-force attack to obtain the plain-text.

For a long time, enterprises addressed this by disabling the local administrator account (whether in the image or through Group Policy), and simply allowed groups of Active Directory users to be local administrators on the local machines. This raises a couple of tricky points, though. Firstly – if you’re relying solely on AD-based users to administer your machines, and for some reason a machine isn’t able to contact Active Directory, then you’re pretty snookered when it comes to fixing the issue; you won’t be able to log on! Secondly, if you make large groups of users administrators on large swathes of your devices, then if just one of these administrative accounts is compromised, then an attacker potentially has access to many other machines and can swiftly escalate their intrusion through your estate.

The next approach that enterprises took to these issues was generally to make the local Administrator account password unique, so that you could re-enable it but not take the risk of an attacker using it on every single machine on the network. However, humans being humans, it was often standard practice to use something memorable or that could be guessed from a known value – MAC address, serial number, computer name, any of the above with some added constants, etc. Whilst this offered slightly more in the way of security, any attacker gaining insight into the variables that make up the local admin password would again have free rein across the environment. It has been clear for a long time that a more secure answer to this question is required. This is where an application called LAPS (Local Administrator Password Solution) comes into its own.

Note: we’ve seen many organizations store the local Administrator password in Group Policy Preferences (GPP). This is a bad idea, as detailed in this blog post on decrypting the password found in GPP.

Deploying LAPS

LAPS is a Microsoft product and requires nothing more than a functional Active Directory to implement onto Windows endpoints. There is no cost associated with it either, so there is no excuse not to use it as an additional layer of security.

The idea behind LAPS is that AD manages a unique password for each endpoint that is “enrolled” into LAPS. When a user requires administrator access to a particular device, they look up the local administrator password and use that to access the machine. When they are finished, they reset the password by clicking a button inside of LAPS, which then initiates a change of the local administrator password at the next Group Policy refresh. They can also “set” the next password change time when they check out the administrator password, ensuring that it is only valid for a specified period of time.

The LAPS software can be downloaded from this address.

Deployment is pretty simple to do. You need to install three components:-

The LAPS PowerShell extension allows you to adjust the AD schema and permissions required. This only needs to be done on a machine with access to Active Directory, not a domain controller itself. While you can use the DC itself, you may want to keep the attack surface to an absolute minimum on this critical system.

The LAPS Management UI is used to look up and reset specific local admin passwords. This is best installed onto a management station.

The LAPS GPO CSE is a client-side extension for Group Policy that enables the LAPS functionality. This needs to be installed on every endpoint that is going to be managed via LAPS.

The LAPS GPO Editor Templates are simply ADMX and ADML files which should be installed on the station where Group Policy management is done from (usually a management desktop)

Installing LAPS PowerShell extension

Run the LAPS installer for your processor architecture (in this case, LAPS.x64.msi) and select the options as follows:

This will install the required PowerShell module.

Installing LAPS Management UI and GPO Editor templates

As above, run the appropriate installer and check the options shown below:-

Note – there is nothing stopping you from installing the PowerShell module, Editor Template and/or LAPS UI onto the same machine. Select the right combination for the environment you are in.

Installing LAPS GPO CSE

This is the installation that will need to go to a large portion of your estate – i.e. every machine that is to be managed. If you are doing a manual install, you can use the options below:-

If you need to touch a large number of machines, it may be better to use the command line installation options. This will suit any deployment technology in use, such as SCCM.

msiexec /i \\server\share\LAPS.x64.msi /quiet

This shows an example running the x64 version of the LAPS installer from a network path.

Once this is done, you should be ready to move to the stage of structuring your LAPS implementation.

Preparing Active Directory for LAPS

Active Directory requires a schema extension so that the machine password attribute can be stored, so there is some AD work required. Prior to performing this, though, it is important to think about how you will be structuring the access to local administrator passwords.

Structure

Rather than have a single AD group that gives access to the local administrator password on all of your machines, it makes much more sense from a security perspective to group them out appropriately. The target machines should be grouped into OUs, and AD groups should be created to hold users that have access to the local administrator passwords. LAPS works predominantly on an OU level, so for instance, if you had an OU full of machines called “Engineering”, you could create an AD security group called “LAPS Engineering Admin” and add this group to the permissions set for the specified OU. Map out your target OU names and the associated group names prior to beginning the AD preparation stage, making sure that you have the full name (Distinguished Name) of the OUs you are targeting to hand.

For simplicity within this example, I have an OU called “Workers” that I wish to give LAPS access to, and the group that receives this access is called “LAPS Users”.

AD preparation

Log on to the machine where the LAPS PowerShell extension is installed, and open an administrative PowerShell instance. Make sure that the user you are running the PowerShell as is a member of the Schema Admins group in your Active Directory domain.

Firstly, run this to load the required module

Import-module AdmPwd.PS

Once this is done, run the following line of PowerShell

Update-AdmPwdADSchema

Which should show the following output

You can see that two attributes have been added which will now hold both the password, and the password expiration date.

Next, you need to make sure that users do not have “All extended rights” permissions onto the target OUs. This can sometimes happen and will give them the rights to read confidential attributes (such as the password).

To check, run the following PowerShell (substituting your target OU or OUs names where appropriate)

find-admpwdextendedrights -identity “OU=Workers,OU=Citrix,OU=Workstations,OU=Devices,DC=james-rankin,DC=com” | format-table

This will show you a list of all users holding extended rights on the OU(s) specified. If it looks similar to the below (where only Domain Admins hold these rights), then no intervention is required.

If there are other users showing as having extended rights, you need to open up ADSI Editor (run adsiedit.msc from a DC) and connect to your domain. Browse to the target OU(s) and right-click them before choosing Properties, then the Security tab, and then the Advanced button. Find the users in the list who were mentioned in the output from the PowerShell command, and check them for “All extended rights”, removing as appropriate (image below shows an example where a group has the “all extended rights” permission, which needs removing).

When you have removed them, verify with the PowerShell command from earlier and make sure no other users or groups have these rights.

The next command is required so that the machines can update their own passwords and the timestamps in AD. Run this, with the OU names substituted as appropriate

set-admpwdcomputerselfpermission -orgunit “OU=Workers,OU=Citrix,OU=Workstations,OU=Devices,DC=james-rankin,DC=com”

Finally, you need to run the commands that delegate the authority to read and/or reset passwords. The first command provides the ability to read (substitute OU name and group name as required)

set-admpwdreadpasswordpermission -orgunit “OU=Workers,OU=Citrix,OU=Workstations,OU=Devices,DC=james-rankin,DC=com” -AllowedPrincipals “LAPS Users”

and the second allows the ability to trigger a reset of the password

set-admpwdresetpasswordpermission -orgunit “OU=Workers,OU=Citrix,OU=Workstations,OU=Devices,DC=james-rankin,DC=com” -AllowedPrincipals “LAPS Users”

Once all of these steps are done, your AD should be ready to accommodate use of LAPS.

Setting up policies for LAPS

Next, you need to actually configure the LAPS policies which will configure your target machines.

Before starting, make sure that the machine you are running Group Policy Management Console (GPMC) from have access to the ADMX and ADML files for LAPS. They are installed when you install the GPO Editor Templates from the LAPS installer (as mentioned earlier). They can be installed alongside any other combination of features from LAPS that you wish.

Don’t forget that this copies the ADMX and ADML files to c:\windows\policydefinitions and c:\windows\policydefinitions\en-us respectively, so if you are using a GPO Central Store (like shown here), you need to move or copy the files to the central store. The files are called AdmPwd.admx and AdmPwd.adml.

Create a policy and link it to your target OUs, then edit it.

The policies should be visible in Computer Configuration | Policies | Administrative Templates | LAPS

There are only four policies. Configure these as required

“Enable local admin password management” simply turns LAPS on, so set this to Enabled

“Name of administrator account to manage” should only be used if you have disabled the “built-in” local Administrator account and replaced it with a customized one. As you can see, I have replaced mine via GPO with an account called “admin”, so you must configure this policy setting to ensure that LAPS manages the “correct” local account.

“Password settings” allows you to specify the particular complexity, length and maximum password age for the password which is used for the account managed by LAPS. I always set the password age to 1 day, so that when combined with the next policy, this means users can only have access to administrator accounts for 24 hours at a time before they have to “check them out” again. Set these items dependent on the security stance of your organization.

“Do not allow password expiration time longer than required by policy” should always be set to Enabled, so that a user cannot set the lifetime of a password they are “checking out” to longer than that specified in the policy from the previous setting.

Once these settings have propagated to the target OUs and the devices within them, you should now be able to see the attributes on the target computer objects have been set (assuming the user you are running Active Directory Users and Computers as has access to the attributes, and also that you have Advanced Features turned on in ADUC)

Now, if you run the LAPS UI application, you can search for the computer name and retrieve the local admin password.

But if the user running LAPS UI does not have the rights to see it (so they weren’t in the AD group that you delegated permission to the OU for), they will see this instead (password field showing as blank)

So now you have everything configured precisely as you want it!

Using LAPS

The idea is that users will now no longer be given administrator access to local machines based around their own administrator userid. That AD-based admin userid will be used to perform actions such as AD management, etc., but if you need local access to a workstation or server that is managed by LAPS, then you must “check out” the local admin password by looking it up. You can then set the duration of your “check out” by selecting “New expiration time” and clicking Set. However, this can be controlled centrally by setting the maximum password age in the “Password settings” GPO. In my environments, I set the maximum password age to 1 day so that users can only check an administrator account out for 24 hours at a time before it is reset automatically.

You can also set up auditing on the checking-out of admin passwords so that this information can be logged into your SIEM tool. This is the command to enable auditing (ensure you replace the OU names and target AD group names as before)

Set-AdmPwdAuditing –OrgUnit: "OU=Workers,OU=Citrix,OU=Workstations,OU=Devices,DC=james-rankin,DC=com" -AuditedPrincipals: “LAPS Users”

Once this is done, users checking out passwords using the LAPS UI will log an event to the security log of the domain controller with event id 4662, which you can despatch and monitor as appropriate to your estate.

Summary

All in all, LAPS represents a no-cost, easily-managed way of getting control of the first set of local accounts on your estate – the built-in administrator accounts. It requires no infrastructure beyond your Active Directory, is easily scopable to sets of users and reduces the potential depth of an intrusion by putting more obstacles in the way of an attacker. Given that there are many threats from “old-fashioned” ways of managing local admin passwords – such as setting them via Group Policy Preferences, which can easily be decrypted – switching to LAPS is an easy way to improve your security stance quite considerably.

Of course, an attacker could compromise an account in your LAPS groups and use LAPS itself to gain access, but if you have delegated permissions properly the scope of this will be reduced and it will be nowhere near as damaging as having a domain account compromised. Also, if you are doing monitoring correctly you should quickly be able to ascertain that a user is making use of LAPS in ways that are markedly different to their normal execution profile.

Once you’ve gotten control of local administrator accounts, it is only natural to move on to another set of accounts that are oft overlooked when it comes to security vulnerabilities – service accounts. Too often, we see service accounts that have huge privileges – often Domain Admin level – and passwords that are rarely, if ever, changed. These represent a unique threat vector because they are often critical to enterprise software and administrators are incredibly reluctant to modify them. Microsoft do provide a potential way around this – group Managed Service Accounts (gMSAs). In our next blog post we will cover how to effectively use group Managed Service accounts to securely perform administrative tasks on your Windows systems and making it harder for those pesky pentesters to get access to your passwords.