Implementing Modern Security Tools – Part 2 – Microsoft LAPS

In part 1 of this series I covered the newest tool on the block, Azure AD Password Protection, a tool which allows you to have greater control over account password complexity and account lock outs. In part 2 we will have a talk about a tool that is so often overlooked but offers great security for administrator accounts, that being Microsoft LAPS.

1. Implementing Modern Security Tools – Part 1 – Azure AD Password Protection
2. Implementing Modern Security Tools – Part 2 – Microsoft LAPS
3. Implementing Modern Security Tools – Part 3 – Conditional Access
4. Implementing Modern Security Tools – Part 4 – Password Reset

What Is Microsoft LAPS?

Microsoft Local Administrator Password Solution has been around since 2015 and does one important job within your environment, it randomises the local administrator account password at intervals defined within a group policy object.

Once the password is rolled over it is then stored in active directory for retrieval. By default members of the domain administrators security group can read this attribute and of course this can be delegated, for your IT helpdesk engineers for example.

For some of you reading that last paragraph you might think to yourself, why would you want random admin passwords across your entire estate? If that question did pass through your mind then you need think about the process of how your local administrator passwords are set.

The Local Admin Security Issue

Depnding on your new machine build process you either manually or automatically build machines, join them to your domain and potentially have a local administrator password which is known to the members of a group (IT help desk for example) for accessing the machine if the machine account becomes out of sync or for other administrative tasks. In once sense having the password standardised has been seen by orginisations as an easy thing to do, providing access to their IT staff for quick troubleshooting, however easy isn’t always the best thing to do.

In today’s security conscious mindset with ransomware and malware threats, this offers the potential for a huge exposure. Once a password is key logged or password hash is harvested, there is very little to stop an attack spreading across your entire network unabated in a scenario where passwords are common across the environment.

You might argue the case that you disable local administrator accounts as part of your OS deployment. In this case you have a good security practice to start with, however is it better to protect against the potential that an account could be re-activated temporarily and forgotten about, than provide no protection at all. Don’t forget that there are always exceptions to the rule, so it is easier to protect against the possibility than deal with the aftermath.

Visualising The Security Threat

The below simulates an attack in a standardised local admin password environment, where the local administrator account is used for help desk purposes;

1. Malware is injected into a local user account profile
2. The end user contacts the help desk for remote support
3. The help desk engineer logs in using local administrative rights
4. The password hash is captured or key logged credentials are obtained
5. Malware starts to spread to other devices with the same local account details present
6. Further malware distribution occurs with varying elevated accounts exposed

At its worst case this potentially means that an attack not only impacts on your end user environment, but also your server environment.

Implementing Microsoft LAPS

So now we have identified the risk and the need to change the local administrator password in a controlled automated method, lets talk about how long it would take to roll out such a solution. Well the short answer for this is, minutes.

Back in November of 2016 I wrote a comprehensive guide on how to implement the full solution. The original post is available from the link below, however I have included the content below rather than referring you to the original post.

Original Installation Post
https://msendpointmgr.com/2016/11/11/automating-management-of-local-administrator-passwords-microsoft-laps/

Deploying Microsoft LAPS

First of all you will need to download the installer from the following URL – https://www.microsoft.com/en-us/download/details.aspx?id=46899. In the below section we will run through the entire installation and configuration process;

Management Server Installation

A single installer is used for both the server and client installs, the only real difference being that the management tools need to be installed on the management server. Run the LAPS.x86 or LAPS.x64 installer as per your system architecture, then run through the following;

Launch the installer

At the custom setup screen select the management tools and select run from my computer and then click Next

Click on the Finish button to finalise the install

Active Direct Schema Modification

In order for computers to write back their local administrator passwords and expiry date/time, a schema update is required. The update adds the following two values:

ms-Mcs-AdmPwd – Stores the password in clear text
ms-Mcs-AdmPwdExpirationTime – Stores the time to reset the password

To add these values, launch a PowerShell session on your management server and perform the following actions;

Type – Import-Module AdmPwd.PS to import the required LAPS module

Type – Update-AdmPwdADSchema

Note: If you have an RODC installed in the environment and you need to replicate the value of the attribute ms-Mcs-AdmPwd to the RODC, you will need to change the 10th bit of the searchFlags attribute value for ms-Mcs-AdmPwd schema objet to 0 (substract 512 from the current value of the searchFlags attribute). For more information on Adding Attributes to or Removing attributes from the RODC Filtered Attribute Set, please refer to https://technet.microsoft.com/en-us/library/cc754794(v=WS.10).aspx.

Active Directory Rights

Computer Rights

In order for computer accounts to write values to the ms-Mcs-AdmPwdExpirationTime and ms-Mcs-AdmPwd attributes in Active Directory, the following PowerShell command needs to be run (note if closed the previous PowerShell window you will need to run Import-Module AdmPwd.ps again)

Set-AdmPwdComputerSelfPermission -OrgUnit "name of the OU to delegate permissions"

User Rights

By default members of the Domain Admins group will have rights to view the local administrator passwords stored in Active Directory, however what happens if you want your desktop support team to view them?. To facilitate this you will need to delegate rights.

To do so use the following PS command:

Set-AdmPwdReadPasswordPermission -OrgUnit "name of the OU to delegate permissions" -AllowedPrincipals "users or groups"

Going another step further you can also delegate rights to allow groups or individuals to force a password change. To do so use the following PS command:

Set-AdmPwdResetPasswordPermission -OrgUnit "name of the OU to delegate permissions" -AllowedPrincipals "users or groups"

Group Policy ConfigurationFirst of all you will need to copy the LAPS ADMX and ADML files to your central store. The two files are located in the %WINDIR%\PolicyDefinitions folder on the management server.Now follow the below;

1. Open Group Policy Manager and either create or modify a GPO that you wish to apply the LAPS settings
2. Expand Computer Configuration\Policies\Administrative Templates\LAPS

Configure your Password Settings, Name of the Local Admin Account and Enable Password Management, as per the below examples:

Deploying the LAPS client

Deploying the client is a simple process. Using the same MSI installation files you can deploy the client to your x86 and x64 clients via GPO, SCCM or other third party application deployment systems. Simply use the /quiet switch for client deployments.

Check its working..Active Directory Users & Computers

Opening the Active Directory Users & Computers console and viewing the Attribute Editor of a machine located within the OU that you earlier deployed your LAPS enabled GPO to, should result in values being available as per the below screenshot;

LAPS Admin GUI

On the management server that earlier installed LAPS on, you will have the LAPS GUI. This will allow you to both look up details from computers but also set a new expiration date for the existing local admin password;

Additonal Considersations

When re-imaging machines the ms-MCS-AdmPwdExpirationTime attribute held against the machine in active directory is not changed, hence there can be a disconnect between the maximum password duration set in the applied GPO.

There is a PowerShell script that can take care of resetting the attribute, which is included below, however I would like to suggest that the default 30 days is lowered to 1 day. If you consider that the account should only be used as a temporary log on account, then providing an IT engineer with a password that only lasts for 24 hours further goes to improve your security outlook.

#Get NetBIOS domain name
$Info=new-object -com ADSystemInfo
$t=$info.GetType()

$domainName=$t.InvokeMember("DomainShortName","GetProperty",$null,$info,$null)
$computerName=$env:computerName

#translate domain\computername to distinguishedName
$translator = new-object -com NameTranslate
$t = $translator.gettype()
$t.InvokeMember(“Init”,”InvokeMethod”,$null,$translator,(3,$null)) #resolve via GC
$t.InvokeMember(“Set”,”InvokeMethod”,$null,$translator,(3,”$domainName\$ComputerName`$”))
$computerDN=$t.InvokeMember(“Get”,”InvokeMethod”,$null,$translator,1)

#connect to computer object
$computerObject= new-object System.DirectoryServices.DirectoryEntry("LDAP://$computerDN")

#clear password expiration time
($computerObject.'ms-Mcs-AdmPwdExpirationTime').Clear()

$computerObject.CommitChanges()

Script source – https://blogs.msdn.microsoft.com/laps/2015/05/06/laps-and-machine-reinstalls/

Conclusion

So in part 1 & 2 you should now have a baseline to help secure your environment with improved password complexities and lockout options, along with securing the local administrator account. In part 3 we will go through how to further secure your environment through the use of conditional access.

Once again, thanks for reading!