Configure and Deploy Microsoft LAPS

IT Security is essentially a risk mitigation game. There is no such thing as a totally secure system, certainly nothing you can ‘set and forget’ and so we are left to decide what we can do, to best protect our systems.

We don’t want an unauthorised person to use our computer, so we use a password. We know passwords can be guessed, or cracked, so we choose more difficult passwords. More powerful attackers can crack more difficult passwords, so we use 2 Factor Authentication.

The list goes on and on and on, but with each risk we can look for a mitigation that works in our environment, knowing that there is nothing we can do to fully protect ourselves but we can make things as difficult as possible for a would be attacker, in the hopes that he or she may look for some lower hanging fruit elsewhere.

With that in mind we are going to look at managing the Local Administrator password for your client computers to help prevent lateral movement through your network.

LAPS, Local Administrator Password Solution was published by Microsoft in May 2015 as part of MSA 3062591.

“Microsoft is offering the Local Administrator Password Solution (LAPS) that provides a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain. Domain administrators using the solution can determine which users, such as helpdesk administrators, are authorized to read passwords “

In this LAB setup I have a Small Business Server 2011, and two guest clients running Windows 7 and Windows 10.

Download the LAPS from here: https://www.microsoft.com/en-us/download/details.aspx?id=46899

You will need the LAPS MSI for your OS Architecture, I would also recommend you download the operations guide to familiarise yourself with how this works.

Installing LAPS

Once you have downloaded the LAPs installer, copy the file over to your Server.

Before we do anything else we need to create a new PowerShell Config file, because by default PowerShell on SBS 2011 is stuck on version 2.0 for Exchange 2010 Compatibility and wont run .NET 4 code, which we need in order to run the Update-AdmPwdADSchema command on the Server, on a newer OS you can skip this.

On your desktop create a file called, PowerShell.exe.Config and open it up in notepad.

Type the following:

Now, copy this file to c:\windows\system32\WindowsPowerShell\v1.0\

Run the installer and install all the Management components.

Modify the Schema

Launch an Elevated PowerShell Window, type in:

Import-Module ADMPwd.PS
Update-AdmPwdADSchema

You should see the following:

Everything being well we can move on to updating user rights.

Updating ‘Extended Rights’

If you are following along at home, we are at step 2.2.1 on Microsoft s LAPS Setup Guide.

We need to go into ADSI Edit for this next step and remove ‘All Extended Rights’ from Groups or Users we do not want to be able to read the password for the computers.

Before we go head first into that, let’s take a moment to review who has those rights currently.

Assuming you have a default SBS OU Structure, the OU our computers will reside in will be:

OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=domain,DC=local

The command you need to enter here is:

 

Find-AdmPwdExtendedrights -identity SBSComputers | Format-Table

In my LAB the only returned object was the Domain Admins group, we also get the same result on the SBSServers OU.

In my LAB this means there are no users or groups to remove rights from, so we can skip to Step 2.2.2 where we can add the relevant permissions to the Computer Accounts to update their own passwords.

Set-AdmPwdComputerSelfPermission -OrgUnit SBSComputers

Repeat this for any OU that Computers may also reside in.

Next we can add User Rights to anyone who will need to read the passwords for the computers.

As the Domain Admins already have permissions, we can setup an additional group to also have access to this information.

Run the following in PowerShell:

Import-Module ActiveDirectory
New-ADGroup PwdAdmin -GroupScope DomainLocal

Then we apply Permissions to the Group:

Set-AdmPwdReadPasswordPermission -OrgUnit SBSComputers -AllowedPrincipals PwdAdmin
Set-AdmPwdResetPasswordPermission -OrgUnit SBSComputers -AllowedPrincipals PwdAdmin

Now we can move on to Step 3, editing the Group Policy.

Group Policy

I created a new GPO Called ‘LAPS – Password Control’, which is linked to the SBSComputers OU.

Open up the Group Policy Editor, expand Computer Configuration, Policies, Admin Templates and find LAPS.

We have four settings to configure here.

Password Settings

You have the option of setting different complexity requirements, I’m setting this to enabled and leaving it on the most complex option.

Name of Administrator Account to Manage

This one is a little different, and obviously will vary depending on your environment.

If you use the built in Local Admin account ‘Administrator’ DO NOT configure this policy setting.

If you use a custom named local administrator account DO configure this setting.

If you have multiple Local Admin accounts, now is probably a good time to review that and remove them. You can also manage the Local Administrator group membership using a Restricted Groups GPO setting.

Do Not Allow Password Expiration Time Longer Than Required by Policy

Set this to ‘Enabled’.

Enabled Local Admin Password Management

Set this to Enabled to turn LAPS ‘On’, Disabled to turn LAPS ‘Off’

Our LAPS GPO is now configured.

Deployment

If you have both x64 and x86 type clients in your network, you can use two GPOs with WMI Filters to control the software deployment.

WMI Filter examples:

Select * from Win32_OperatingSystem where OSArchitecture = "32-bit"
Select * from Win32_OperatingSystem where OSArchitecture = "64-bit"

I used to be a big fan of Active Directory Software Deployment, MSI files were the best way to push out software on reboot and it was very effeicient. As times have changed i have found it to be less reliable, along with startup scripts.

Following some advice i picked up from here i have moved most operations of this type to scheduled task.

What we can do is create a Scheduled Task, via Group Policy Preferences, to run our LAPS MSI file and update group policy.

You can do this procedure twice, one policy per architechture.

Inside a new GPO, expand Preferences, and Expand Windows Settings, then Files.

Right click the details pane, click New > File.

Source File:

Enter a UNC path where the LAPS MSI file is stored, that will be accessible to your client computers.

Destination File:

c:\users\public\LAPS.x64.msi

This will copy the file to your client computer when the GPO is applied.

(i had a bit of a think about this after posting, copying the file to the public folder is pretty easy, and for testing is fine, but, given the task to install is going to run as system it might be a risk to do so in production so make sure you put this installer somewhere that a user running with normal privileges and permissions cannot replace it with something else) 

Next, switch to Control Panel Settings, and Scheduled Tasks.

Right click the Details Pane, click New > Scheduled Task (Vista or Later)

On later versions of Server this will Say Windows 7 or later etc.

Enter a name for your Task.

‘Install LAPs’

Under Security Options, click Change User or Group, enter SYSTEM and click OK.

Choose Run whether user is logged in or not, and run with highest privileges.

Switch to the Triggers tab.

Click new.

Configure the trigger to suit your requirements.

I am setting it to run at startup with a small delay.

On the actions tab, configure two actions.

Command: msiexec.exe

Arguments: /i c:\users\public\LAPS.x64.msi /qn

Command: gpupdate.exe

Arguments: /force

Under settings, select the first two boxes.

Close down the GPO Editor. You can then apply your x64 WMI Filter to this GPO (repeat the procedure for LAPS.x86.msi and the x86 WMI Filter)

These policies will now deploy the LAPS tool to your client computers.

Now how do we view these passwords?

View Passwords

We have the choice of using the LAPS UI ‘fat client’ or the LAPS PowerShell for this.

In the UI simply enter the hostname of the Computer in question and click Search.

The password will be shown to you in plaintext.

The PowerShell way,

Get-AdmPwdPassword -ComputerName Windows7Pro

Or save a little function…

param(
    [string]$computer
)
Import-Moule ADMPWD.ps
$password = (Get-ADMPwdPassword -computer $computer).Password
Write-Output "Password: $password"

If you recall earlier, we left the Domain Admins with extended rights, and also added a new group that we gave the rights to view passwords to.

If you have an Office Manager or onsite IT Tech who also needs to see these passwords, but not be a Domain Admin, add them to the PwdAdmin group.

Of course this would be their ‘Admin’ account not their day to day account.

You can also go ahead and run the MSI file again on their workstation to install the LAPS UI tool or the PowerShell module.