LAPS is a fantastic free tool from Microsoft that manages Domain Member computer local account passwords. https://www.microsoft.com/en-us/download/details.aspx?id=46899

I have deployed LAPS for a number of Enterprise customers to use for managing their Domain Member Windows Server local Administrator account passwords.

In the final part of this blog series we will look at how to audit LAPS password access.

Part 1 of this blog series “Deployment Considerations”

Part 2 of this blog series “Accessing and Resetting Passwords”

Part 3 of this blog series “Monitoring”

Auditing LAPS

LAPS generated passwords are stored on the Active Directory Computer Object in the attribute ms-Mcs-AdmPwd.

By default, when a principal with the AD permission Read ms-Mcs-AdmPwd reads the attribute ms-Mcs-AdmPwd there is no log entry made on the Domain Controller. Therefore, a compromised account could dump all LAPS set passwords from AD undetected.

We can configure auditing within Active Directory. The LAPS Powershell module allows us to easily do this.

In the example below, Auditing is enabled for the Member Servers Organisational Unit.

Import-Module AdmPwd.PS
Set-AdmPwdAuditing -OrgUnit "OU=Member Servers,DC=lab,DC=home" `
-AuditedPrincipals:Everyone

All Computer Objects in the Member Server OU will now be audited for LAPS password reads.

Event ID 4662 is logged in the Domain Controller Security event log every time the password attribute (ms-Mcs-AdmPwd) is read. Which Domain Controller it is logged on depends on which Domain Controller the request is sent to by the client requesting it.

The log entries can be parsed using a combination of the event ID and the schemaIDGUID for the attribute ms-Mcs-AdmPwd (which is unique to each AD Forest).

The three key items in the event are:

• Security ID (account that read the password)
• Object Name (Distinguished Name of the computer whose password was read)
• schemaIDGUID (Identifier for the password attribute)

Finding the SchemaIDGUID

These instructions use a slightly modified version of the answer given by Mathias R Jessen on Stackoverflow.

Run the below Powershell command from a device with the Active Directory Powershell module installed to extract the schemaIDGUID for the attribute ms-Mcs-AdmPwd.

$attrSchemaParams = @{
    SearchBase = (Get-ADRootDSE).schemaNamingContext
    Filter = "ldapDisplayName -eq 'ms-Mcs-AdmPwd' -and objectClass -eq 'attributeSchema'"
    Properties = 'schemaIDGUID'
}
$LAPSschema = Get-ADObject @attrSchemaParams

$LAPSschemaPwdGUID = $LAPSschema.schemaIDGuid -as [guid]
$LAPSschemaPwdGUID

REMEMBER: This Guid is unique for each AD Forest.

Looking closer at the Event ID 4662 that was logged when we read the password, we can see the same GUID under “Properties:“.

A log monitoring tool can be configured to search for:

• Targets: Domain Controllers
• EventID: 4662
• Keywords: < Unique schemaIDGUID >

• WordPress
• LinkedIn

LAPS is a fantastic free tool from Microsoft that manages Domain Member computer local account passwords. https://www.microsoft.com/en-us/download/details.aspx?id=46899

I have deployed LAPS for a number of Enterprise customers to use for managing their Domain Member Windows Server local Administrator account passwords.

In part 3 of this blog series we will look at how to monitor LAPS operations.

Part 1 of this blog series “Deployment Considerations”

Part 2 of this blog series “Accessing and Resetting Passwords”

Part 4 of this blog series “Auditing”

The LAPS Process

LAPS is a Client Side Extension for Group Policy. LAPS is triggered each time Group Policy is refreshed on a device. This means you will not find it in Windows Services nor running as a process in Task Manager.

When LAPS is triggered, it checks the attribute ms-Mcs-AdmPwdExpirationTime on the host device’s Active Directory Computer Object. If this attribute has no value or is a date and time in the past then LAPS will attempt to set a new password.

First it will attempt to write the password to the attribute ms-Mcs-AdmPwd on the host device’s AD Computer Object. Once it confirms it has been successfully written to AD, LAPS updates the password on the host device (writes the password to the local Security Account Manager database).

• LAPS will only set a new password if a Domain Controller is accessible after a new password has been generated. This ensures that AD always has the current password.

Monitoring LAPS

LAPS logs to the Application event log with the source AdmPwd. By default, LAPS only logs errors.

The logging level is set by the registry key below:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions{D76B9641-3288-4f75-942D-087DE603E3EA}\ExtensionDebugLevel REG_DWORD

A full list of the possible log entries are in the document LAPS_TechnicalSpecification.docx which is included with the official LAPS download.

Setting the log entries to a value of 1 should suffice for most environments. Your existing monitoring solution may be able to be configured to generate alerts based on the Event Log entries from LAPS.

Logging Demonstration

The host LAB-CTXHOST has had LAPS installed. It has a GPO applied that sets LAPS to verbose logging by creating the below registry key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions{D76B9641-3288-4f75-942D-087DE603E3EA}\

ExtensionDebugLevel

Type: REG_DWORD

Value: 2

On LAB-CTXHOST using RegEdit we can see that the registry key has been created.

In Windows Event Log, we have filtered the log to only show events from the source AdmPwd.

Logging Demo: Password Change Not Required

Now we force a Group Policy update by running gpupdate from the command line.

When we refresh the event log, we see event IDs 15, 11 then 14.

Reading the events we can see that LAPS took no action because the password expiration date and time on the AD Computer Object for LAB-CTXHOST is 30 days in the future.

Logging Demo: Password Change Required

Using Powershell, we set the expiration date to be in the past. Now we run gpupdate and observe the log entries.

This time we see event IDs 15, 5, 13, 12 then 14.

Logging Demo: No Domain Controller Available

If the Domain Controller is inaccessible at the start of Group Policy processing, no LAPS log entries will appear. This is because Group Policy processing fails before the LAPS Group Policy Client Side Extension is triggered. LAPS will never reset the password under these conditions.

Logging Demo: No permission over object

During the installation of LAPS, we use the Set-AdmPwdComputerSelfPermission LAPS Powershell module cmdlet to apply the following permission to the Organisational Unit that contains the Computer Objects that are due to receive LAPS.

• Principal: SELF
• Permission: Write ms-Mcs-AdmPwd
• Applies to: Descendent Computer Objects

This allows the devices to update their passwords in Active Directory.

We have now removed this permission for LAB-CTXHOST and used the LAPS Powershell module cmdlet Reset-AdmPwdPassword to set an expiration date and time that is in the past.

After running gpupdate we see the event IDs 15, 5 and 7.

Summary

We have seen that using the Windows Event Log, we can view to a granular level which step of the LAPS process has failed. In production, logging level 1 (Errors and Warnings) should suffice and most monitoring solutions can be configured to read these logs entries and generate alerts.

• WordPress
• LinkedIn

LAPS is a fantastic free tool from Microsoft that manages Domain Member computer local account passwords. https://www.microsoft.com/en-us/download/details.aspx?id=46899

I have deployed LAPS for a number of Enterprise customers to use for managing their Domain Member Windows Server local Administrator account passwords.

In Part 1 of this blog series we will run through some of the prerequisite checks that I perform when asked to deploy LAPS.

Part 2 of this blog series “Accessing & Resetting Passwords”

Part 3 of this blog series “Monitoring”

Part 4 of this blog series “Auditing”

• There are many guides for installing LAPS freely available so I will not cover the installation steps in this blog series.
• I highly recommend this guide for installing LAPS by Prajwal Desai: https://www.prajwaldesai.com/how-to-install-and-deploy-microsoft-laps-software/

This post is written assuming that we have already read the installation instructions for LAPS. The list does not have to be done sequentially. Although this post is written with Server deployments in mind, the same considerations apply to Workstation deployments.

1. Nominate a management host

Nominate a device on which we will install the LAPS management tools. I normally do this on a management server which will eventually be used to run the LAPS GUI and Powershell module from by administrators. The device must have at least .NET 4.0 and Powershell 2.0.

This can of course be installed on workstations too. In the real world though many enterprises have management servers from which most admin tasks are done.

2. Nominate a test server

This is for testing the LAPS Client Side Extension and GPO. Recommended to be a Virtual Machine on which snapshots/checkpoints can be taken. Should be a non-critical server that we can reboot multiple times.

3. List the Distinguished Names of all Organisational Units that contain the target Member Servers

Typically customers will create an Organisational Unit branch called “Servers” under which they will store all of their server computer accounts. Sometimes there are servers elsewhere so it’s always good to check so that we can target all Servers with a GPO. Get all the servers not in the expected Organisational Unit branch.

In the code snippet, change the “*OU=Servers..” etc. to be the distinguished name of the OU under which the majority of the server computer accounts are.

$computers = Get-adcomputer -filter * -Properties *
$computers | ?{$_.operatingsystem -like "*Server*" -and `
$_.distinguishedname -notlike "*OU=Servers,DC=Domain,DC=com*"}

4. Identify accounts with ‘All Extended Rights’ permission

LAPS passwords are stored on the Active Directory computer object. To view the passwords a user must have the ‘All extended rights’ permission.

By default only SYSTEM and Domain Admins have this permission. It is rare that other users will have been added, however, we should check for anyone who already has this permission so that we do not inadvertently grant unauthorised users access to the new local admin passwords.

In step 3, we created a list of Organisational Units that contain all the Windows Servers that we will target with LAPS. We will now produce a list of users that have the ‘All Extended rights’ permission over these Organisational Units.

The LAPS Powershell module that is installed when you do a Full install of the LAPS client comes with a useful function to do this: Find-AdmPwdExtendedRights

The below script feeds the list of OUs ‘ListOfOU.txt’ in to to the function and creates a list of permission holders per OU.

Import-Module AdmPwd.PS
$list = Get-content ".ListOfOU.txt"
foreach($_ in $list){Find-AdmPwdExtendedRights -id "$_" `
-SchemaNotUpdated | select ObjectDN, `
@{Name=’ExtendedRightHolders’;Expression={[string]::join(“;”, `
($_.ExtendedRightHolders))}}}

If any objects other than SYSTEM or Domain Admins appear in the ExtendedRightHolders column then these questions need to be answered:

a) do those objects still require the All Extended Rights permission?

b) are they authorised to be able to view passwords?

5. List of Security Principals that will have access to the LAPS passwords

An important discussion that needs to be had is “Who do you want to have access to local admin passwords?”

Too many organisations have nested Active Directory Security Groups that have inadvertently given junior IT staff Domain Admin rights. This is an ideal time to review this within your organisation or with your customer.

You can grant additional security groups the “All Extended Rights” attribute so that they do not need to have Domain Admin rights.

6. Reboot Schedule

Many Enterprises do not use SCCM to manage their Servers. Another way to deploy the LAPS installer is using Group Policy Software Installation. A draw back of this is that the client machine needs to restart in order for LAPS to install during startup.

To minimise disruption, it may be beneficial to apply the Group Policy at the start of the monthly Windows Security updates schedule and take advantage of the already agreed reboot schedules for servers.

7. Active Directory Replication

One part of deploying LAPS is extending the Active Directory Schema to add the password and password expiration date attributes to computer objects. This relies on AD replication being functional.

We can save ourselves a lot of headache during a Change Request window if we check AD replication health prior to the deployment

repadmin /replsummary

In the green box is the largest time since the last replication for all links on the listed outbound (top) or inbound (bottom) server. If any of these are in multiples of hours then there may be a replication problem.

In the pink box; if there are any failures then there is definitely a replication problem.

We must resolve issues with AD replication before we start implementing LAPS.

8. Identify Read Only Domain Controllers

The two attributes that are added when LAPS extends the Active Directory schema are:

By default the ms-Mcs-AdmPwd attribute is on the Filtered Attribute Set for Read Only Domain Controllers. This means that it is not replicated to RODCs. IT will not be able to retrieve LAPS passwords from the RODC.

There is logic to this, RODCs are typically located in branch locations classed as insecure. They may be behind a locked door but that door could be cupboard on the ground floor and is accessed by many non-IT staff. It must be assumed that that the RODC may one day be stolen and so we want to minimise the impact should this occur.

Do we really want the RODC to store all of the local admin passwords for all of the Servers on the network?

Nevertheless, there may be a need to replicate this attribute to RODCs. Russell Smith has an excellent blog post on how to do this: https://www.petri.com/modify-the-read-only-domain-controller-filtered-attribute-set-using-adsi-edit

To identify if any RODCs exist in the domain, run the below command:

Get-ADDomainController -Filter {IsReadOnly -eq $true}

9. Schema Admin Rights

To be able to extent the Active Directory Schema we need Schema Admin Rights. In a tightly controlled environment we need to get the request for these rights in early. No Schema Admin, no LAPS.

11. Name of Local Administrator account

Some organisations have multiple local admin accounts on a server.

• You can only manage one account per server per policy.
• One device can only be managed by one policy.

We should look to reduce the number of local admin accounts in use on the estate in favour of Domain User and Service Accounts with Role Based Access Control. A single local admin account can meet the needs of the majority of estates.

In LAPS you can just choose to manage the Built-in Local Administrator account regardless of what it is has been renamed to by leaving the Group Policy setting as Not Configured. This is easiest.

If however you need to manage non-Built-in Local Admin accounts then you will need to ensure that all target clients have the desired admin account present and named correctly. If the name is not the same then it will not be managed by LAPS.

In this scenario we need list all members of the local Administrators groups on all servers and verify that the admin account is present. This can be done remotely using Powershell. Jeffery Hicks has written a script that can do this: https://jdhitsolutions.com/blog/powershell/4908/get-local-group-members-with-powershell/

12. Be Familiar With the Microsoft Documentation

Bundled with the official LAPS installer download are two very useful documents that answer many questions that a customer might have.

• WordPress
• LinkedIn