Microsoft Local Administrator Password Solution – Part 4 – Auditing

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
Auditing applied to OU

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.

Powershell retrieval of the password triggers event ID 4662 on the Domain Controller

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
Powershell script output

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:“.

Unique schemaIDGUID

A log monitoring tool can be configured to search for:

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

9 thoughts on “Microsoft Local Administrator Password Solution – Part 4 – Auditing

  1. Hi!

    To extract the schemaIDGUID for the attribute ms-Mcs-AdmPwd…

    Replace : $LAPSschemaPwdGUID = $pwmEventLogSchema.schemaIDGuid -as [guid]
    by : $LAPSschemaPwdGUID = $LAPSschema.schemaIDGuid -as [guid]

    Thanks !

    Like

  2. Hi!

    To extract the schemaIDGUID for the attribute ms-Mcs-AdmPwd…

    Replace : $LAPSschemaPwdGUID = $pwmEventLogSchema.schemaIDGuid -as [guid]
    by : $LAPSschemaPwdGUID = $LAPSschema.schemaIDGuid -as [guid]

    Thanks !

    Like

  3. 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?

    Like

    1. 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?

      Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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