Do the users in your organization ever forget their passwords? Surely not! Has an Active Directory user locked out their account? No way! All sarcasm aside, maybe there’s a worm slithering around on your network trying every AD user account it can find until they lock out. Let’s see what we can do with PowerShell to track these lockouts down.

Has your network ever been infected with malware that attempts to authenticate with as many domain user accounts as possible? I hope not but I’ve seen it happen a few times. Users and worms are just two of the reasons one or more AD accounts can get locked out. Depending on your password policy, lockouts may be a daily occurrence or only happen occasionally.

Regardless of the reason or situation, accounts lockouts affect your users. Since they depend on their Active Directory domain account for nearly everything, they’ll immediately notice when it is locked out. The account can be re-enabled by your helpdesk but what if it happens again? …and again. …and again. Figuring out the root cause of this problem is important.

One way to do this is to use PowerShell and the ActiveDirectory module. By using the Search-AdAccount cmdlet inside of the Active Directory module, you can easily track down all of the accounts that are currently locked out across your domain.

Finding Locked Out Accounts

To search for locked out accounts, you can run the Search-AdAccount command using the LockedOut parameter. This will return all users currently locked out granted you have the rights to see that.

Search-AdAccount -LockedOut

This command is great but what if you have an account that is continually getting locked out and you need to figure out from which system it’s coming from? This is a common task whenever you have a malware infection somewhere on your network or perhaps when you have a forgetful admin that forgot to log out of a remote desktop session. That’s never happened, right?

To find the source of an Active Directory lockout, you’ll first need to ensure you’re querying the right domain controller. In this case, this will be the domain controller with the PDC emulator role.

Find the PDCe Role Holder

All password authentication will come to this DC holding the PDCe role so it is always the best place to check. To find the domain controller with the PDCe role, you can check the PDCEmulator property returned from the Get-ADDomain cmdlet.

$pdce = (Get-ADDomain).PDCEmulator

Scouring the Event Log for Lockouts

One you have the DC holding the PDCe role, you’ll then need to query the security event log (security logs) of this DC for event ID 4740. Event ID 4740 is the event that’s registered every time an account is locked oout. Do this with the Get-WinEvent cmdlet.

Get-WinEvent -ComputerName $pdce -FilterHashTable @{'LogName' ='Security';'Id' = 4740}

Parsing the Username and Location

This will return all of the lockout events but doesn’t immediately show the usernames and computers that the lockout was performed on. To find the username, you’ll need to dive in a little deeper on a property that Get-WinEvent returns called Properties .

$filter = @{'LogName' = 'Security';'Id' = 4740} $events = Get-WinEvent -ComputerName $pdce -FilterHashTable $filter $events | Select-Object @{'Name' ='UserName'; Expression={$_.Properties[0]}}, @{'Name' ='ComputerName';Expression={$_.Properties[1]}}

You can see that I’ve moved the hashtable filter to prevent code wrap and, more importantly, used Select-Object ‘s calculated properties to pull the username and computer name from the Properties property. In each of these events, the username that was locked out is always the first element in the Properties array while the second element is always the computer name where the lockout was performed on.

Summary

By now, you should be able to quickly pinpoint all of the accounts that are currently locked out in your domain as well as see a history of all account lockouts. Now it’s time to have a stern talking to Joe about leaving those RDP sessions open…