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
| Value | Meaning |
| 0 | Silent mode; log errors only When no error occurs, no information is logged about CSE activity This is a default value |
| 1 | Log errors and warnings |
| 2 | Verbose 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}\
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.
Tech Highs and Headaches 