PowerShell: Filter by User when Querying the Security Event Log with Get-WinEvent and the FilterHashTable Parameter

I recently ran across something interesting that I thought I would share. The help for the FilterHashTable parameter of Get-WinEvent says that you can filter by UserID using an Active Directory user account’s SID or domain account name:

filterhashtable-data1a

Notice that the help also says the data key can be used for unnamed fields in classic event logs. I often hear the question wanting to know what the valid key pairs are for the hash table. As you can see, they’re listed in the help.

First, we’ll start out by determining which domain controller in our Active Directory domain holds the PDC emulator FSMO role since information for all account lockouts that occur in a domain are stored in the security event log of the PDC emulator. Don’t over-complicate locating the PDC emulator. If you have the Active Directory PowerShell module installed which installs as part of RSAT (Remote Server Administration Tools), PDCEmulator is one of the properties that is returned by default by the Get-ADDomain cmdlet:

filterhashtable-data8a

Now, we’ll query the security event log on the PDC emulator for all account lockout events:

filterhashtable-data2a

We’re looking for lockout events for a user with the userid of ‘afuller’ so let’s grab the SID for his user account:

filterhashtable-data3a

As the help stated, we’ll add the userid key and the user’s SID to our hash table:

filterhashtable-data4a

As shown in the previous set of results, a message is received stating no events exist that match the specified criteria.

Usually, this is where most people will simply pipe to Where-Object because they can’t figure out how to filter left by user. The UserID key doesn’t work as expected in this scenario, so an alternate method is to use the data key in the hash table instead of the userid key and specify the user’s SID as the value:

filterhashtable-data5a

You can also use the data key to filter by userid:

filterhashtable-data6a

Now we can add a couple of custom properties to determine what device is causing the account lockout:

filterhashtable-data7a

The moral of the story here is there are hidden gems in the built in help so don’t underestimate its content.

µ

3 Comments

  1. Grammar Cop

    It’s ‘Moral’, not morale 😉

    Reply
  2. Jimmy

    That’s awesome! UserID not working has been driving me crazy. I didn’t think to use data.
    I was looking for a way to log the time’s I logged into my computer and this was the last piece I was missing. Thank you!

    $yesterday = (Get-Date) – (New-TimeSpan -Day 1)
    Get-WinEvent -Computer DESKTOP1 -FilterHashtable @{Logname=’Security’;ID=4624;Data=’jdoe’} | Where-Object {$_.TimeCreated -ge $yesterday} | select @{Name=’User’;Expression={$_.Properties[5].Value}} , TimeCreated

    Reply
  3. B

    This tells you what machine the user was locked out by, but not what machine he was on when he was locked out. Is there a way to find out what machine was hitting “PC01” in this example to get locked out in a large environment? My scenario is a user is getting locked out by a mailbox server, but he is not using it to log in. He is on another device in the company that continues to hit it with the incorrect credentials. We need to find that device.

    Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: