Deploying Local Admin Password Solution (LAPS 6.2)

To understand the need for LAPS we must first understand the risk associated with password reuse. Quite simply, using a single password for local administrator accounts across workstations and/or servers may be convenient for maintenance and troubleshooting, but it enables a potential attacker to have nearly free reign across Windows systems after compromising one computer.

Look no further than mimikatz and it’s inclusion in the NotPetya malware for a real-world example of stealing administrative credentials out of memory. If an attacker breaches one system in this manner and we’re only using one password for local admin accounts, our entire Windows network could be compromised just like that.

Let’s not forget the other, less malicious reasons that reusing a single local admin password is a bad idea. Users can lose the ability to log in with their domain accounts for any number of reasons, and machines can lose their association with the domain, requiring a local admin account to repair. If we need to share the local admin password with a remote end-user or a help desk tech and all of our local admin passwords are the same, we just gave someone the password for every workstation in the company - and possibly every server. That’s not smart security.

The free LAPS software and group policy settings mitigate this risk by randomizing local admin passwords and changing them automatically on a schedule that we set. At any given time, every machine that is managed by LAPS will have a different and random password that is stored in AD and retrievable by an administrator as needed.

The setup is about as straightforward as it gets:

• Download the LAPS software from Microsoft, here. There are 32 and 64 bit versions depending on the OS of the clients you'll be installing it on. There are two components to the LAPS software; the AdmPwd GPO extension that is installed on the clients whose passwords you'll be randomizing, and the management tools that are installed on the machine you'll be managing LAPS from.
• I'm installing the management tools on the domain controller in my lab, so I've copied the MSI installer to that machine and launched it.
• On the Welcome screen, click Next.
• Accept the End User License Agreement and click Next.
• The default installer selection will install the AdmPwd GPO Extension and not the management tools. We want to reverse this and install just the management tools at this stage. If you're installing the management tools on a non-domain controller, you can include the GPO Extension if you want that system's local admin password to be managed by LAPS. Click Next after you've selected the appropriate options.
• Click Install.
• Click Finish.
• With the management tools installed, it's time to extend our AD schema to include the necessary attributes for LAPS passwords. This is done by running PowerShell as an administrator. Start by importing the AdmPwd.ps module.
• Then, run the command to update the schema.
• Next, we need to give our machines rights within AD to update the new password and expiration timestamp attributes. This is also done in PowerShell by pointing the command to the OU(s) containing your computer objects.
• In addition to allowing our machines to update their own password attributes, we may want to allow a set of users or groups to force a password expiration. I've created an AD group for password administrators and will apply that permission to that.

With the management tools installed and Active Directory primed, it's time to build a couple of GPOs. I'm going to deploy the LAPS MSI to client machines in my lab using group policy, but any deployment method should do just fine. By default the MSI will load the AdmPwd GPO Extension, which is all we need on the client machines.

• To deploy LAPS with a GPO, I created a new policy named Install LAPS, and created a new Assigned Software Installation, pointing to the LAPS MSI on a network share that I setup. I made sure that Domain Computers has Read access to the network share so my client machines can retrieve the installer.
• Next, I've created a new GPO named Configure LAPS. There are four options that we care about under Computer Configuration > Policies > Administrative Templates > LAPS. I'm generally selecting the defaults for each option for this lab setup.
• Password Settings should be changed to Enabled. Configure the Complexity, Length, and Age as desired. I would recommend setting the values to match your overall user password policy.
• Name of administrator account to manage can be changed if desired, however I'm leaving it set to Not Configured so it will manage the default "Administrator" account for me. If you have a custom local administrator account on your machines (which is highly recommended in production environments as the BUILTIN\Administrator account is easy for an attacker to attempt brute-forcing, even if you've renamed it), set the setting to Enabled and provide the name of the administrator account that you want LAPS to manage.
• Do not allow password expiration time longer than required by policy should be set to Enabled unless you have a reason that local admin passwords should not adhere to the configured domain password expiration setting.
• Lastly, Enable local admin password management is the master On/Off switch for LAPS. Set it to Enabled.
• Now it's time to apply our new GPOs to the container with our computer objects.

With the GPOs applied, we can now test to ensure that LAPS is being installed and configured on client machines. On my client VM I ran gpupdate /force from an administrative command prompt to force a group policy update, and then rebooted. Under Control Panel > Programs and Features I can see that LAPS was installed successfully. At this point I've found that it takes an additional group policy update before the updated password attribute will propagate to Active Directory. This'll happen automatically or you can force it with another gpupdate /force on the client machine.

To view the local admin passwords set by LAPS we have two options.

• The first is searching through the Attribute Editor for the particular computer object (or via ADSIEdit).
  
  
  
• The second and preferred option is to use the LAPS UI program that is installed as a part of the management tools.
  
  

At this point we're effectively done with the setup. As your computers in the selected OU(s) receive the new policy and eventually reboot, they'll install the LAPS client and begin populating AD with the local admin password info.

The last thing we want to do before wrapping up is to validate that only the users we want have the ability to see these new attributes within AD. After all, this is all for naught if a clever user discovers read access to all of the local admin account passwords. Thankfully, Microsoft has thought of this and provided a PowerShell cmdlet for identifying the accounts and groups that have access to the AdmPwd extended rights.

• Run the Find-AdmPwdExtendedRights cmdlet at an administrative PowerShell window, providing the identity of the OU containing your managed computers.
  
  
  
  By default this only contains SYSTEM and Domain Admins, which I'm OK with. If you've modified container permissions in AD to delegate access or for a different reason you may have users or groups with visibility of the password attributes that have no need to see that information.
  
• To prevent a user or group from seeing the password attributes or to enable a user or group to see that information, turn on Advanced Features for the Active Directory Users & Computers snap-in (View > Advanced Features), then right-click on the OU containing your computer objects and select Properties. Select the Security tab and then click the Advanced button.
  
  
  
• Find the principal name that you want to modify (if you're removing permission) and click Edit.
  
  
  
• The permission to modify is called All Extended Rights. Uncheck the checkbox to remove this permission from the selected principal. Microsoft cautions that this will remove ALL extended rights, not just those pertaining to LAPS, so ensure that this permission isn't needed otherwise.
  
  
  
• For my lab with default permissions I do not have any users or groups with access that shouldn't have it, so I'll add my password administrators AD group and enable the All Extended Rights permission.
  
  
  
  I can now apply the PwdAdmins role to my help desk team, for example, in order to grant them the ability to see local admin passwords and force expiry as needed.

And that's it. With a few minutes of work we've automated local admin password changes across our domain computers, and made it quite a bit harder for an attacker to pivot through our network with stolen local admin credentials.