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 >
Tech Highs and Headaches 
Hi!
To extract the schemaIDGUID for the attribute ms-Mcs-AdmPwd…
Replace : $LAPSschemaPwdGUID = $pwmEventLogSchema.schemaIDGuid -as [guid]
by : $LAPSschemaPwdGUID = $LAPSschema.schemaIDGuid -as [guid]
Thanks !
LikeLike
Hi!
To extract the schemaIDGUID for the attribute ms-Mcs-AdmPwd…
Replace : $LAPSschemaPwdGUID = $pwmEventLogSchema.schemaIDGuid -as [guid]
by : $LAPSschemaPwdGUID = $LAPSschema.schemaIDGuid -as [guid]
Thanks !
LikeLike
Appreciate you taking the time to reach out. Great spot and thanks for letting me know!
I’ve updated the post.
All the best,
LikeLike
Great job! was very useful. I could see the events when the user retrieves the password from LAPS tool or PowerShell, but does not work when the users directly reads the password from the RSAT tool installed on their machine. Is there an option to disable the display of password attribute in RSAT?
LikeLike
Hi, thanks for the message.
The display of the password attribute is determined by the view Extended Attributes permission. So any user with this can retrieve that attribute using any tool that can inspect AD objects. For RSAT, it ‘should’ be retrieving the attributes from a DC in the site of the device it is being run from. That DC ‘should’ then log an audit entry.
I say ‘should’ because I am rebuilding my lab in order to be able to confirm this behaviour. I will let you know the outcome.
In the interim, how many DCs do you have? Is it possible that the RSAT console is reading from a DC that has not yet had its audit log checked?
LikeLike
Good article
LikeLike
Many thanks!
LikeLike
Hello,
Do you have to run the Set-AdmPwdAuditing on all of your DCs? Also, I see events for schemaIDGUID for the attribute ms-Mcs-AdmPwd, however I do not see them constantly. The ones I see shows the admin, but not the computer that the admin was pulling the local password for. Is that what you would expect?
LikeLike
Hi,
The set-admpwdauditing cmdlet only needs to be run against one Domain Controller. AD will replicate the change across all other DCs.
When you access the stored password, you are doing so in the user context. So it is recorded as your user account accessing it rather than the computer you are using.
LikeLike
Thank you for the reply. I was using Get-Win event to pull the events and it was providing the ObjectName as a number. When I went to the DC and looked at the event in event viewer I see the human readable name.
In testing this I had an admin use the the thick client to read the password and looked for schemaIDGUID as you mention in the article. I was able to find an event. However, when I read the LAPS password using the Powershell command as below, I don’t get any events. Shouldn’t that work?
Get-AdmPwdPassword -Computername test_computer
LikeLike
It should still log it because it is still reading the attribute.
LikeLike