Microsoft Local Administrator Password Solution – Part 3 – Monitoring

LAPS is a fantastic free tool from Microsoft that manages Domain Member computer local account passwords.

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

0Silent mode; log errors only
When no error occurs, no information is logged about CSE activity
This is a default value
1Log errors and warnings
2Verbose mode, log everything

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}\



Value: 2

LAPS Verbose logging

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.

Application event log filter

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.

Event ID 15: Start of processing LAPS
Event ID 11: LAPS logic
Event ID 14: End of processing LAPS

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.

Event ID 15: Start of processing LAPS
Event ID 5: LAPS has generated a new password and validated it against the GPO controlled password requirements.
Event ID 13: New password successfully written to Active Directory.
Event ID 12: New password successfully updated on the local administrator account.
Event ID 14: End of processing LAPS

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.

Event ID 15: Begin processing LAPS
Event ID 5: LAPS has generated a new password and validated it against the GPO controlled password requirements.
Event ID 7: LAPS fails to write the password to AD


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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s