How To Resolve Active Directory Account Lockouts With PowerShell

How do you track and resolve a locked Active Directory account? Find out what takes place, how to find specific events, and how to parse events.

Active Directory (AD) is a wonderful service. You can log on from anywhere on the network using the same username and password. It couldn't be easier -- that is, until you forget to close a remote desktop session, or a worm spreads across the network, or you forget you're running a scheduled task as your user account, or... Well, you get the point. AD is an extremely useful product; this is why its adoption rate is so high. The problem is when an account begins to lock out for no reason whatsoever. Or so you think.

AD Account Lockout Policies

Many organizations have (or should have) account lockout policies. This policy is a security measure to prevent unauthorized parties from trying to guess the password continuously or brute force a password. Account lockout policies are commonplace in Active Directory and consist of a simple approach to combating a major security issue. Attempt the wrong password a certain number of times, and the account is unusable until an administrator manually re-enables it again. The intention is true, but in some instances, the implementation is not.

In some situations, especially when a password is changed, an account can suddenly start getting locked out consistently for no apparent reason. A user calls the help desk, the help desk re-enables the account, and a little bit later, the account is locked out again. It's a frustrating experience for both the user and the help desk. Sometimes the problem is exacerbated by the unknown origin of the lockouts. Somewhere, somehow there's a person, a script, or a process continually trying the same wrong password over and over again, but no one knows where.

So how do you track down these annoying lockouts? One way is by using a PowerShell script. But first, let's go over what happens when an account is locked out.

Resolving A Locked AD Account

In a Windows Server 2008 or later environment, there is a short back and forth between the client system, the client system's domain controller, and the domain controller holding the Primary Domain Controller (PDC) emulator role. This occurs as follows:

1. Whenever a user account authentication is attempted, the credentials are sent up to the appropriate domain controller for the client system's subnet. 
2. If the password is wrong, the client system's domain controller forwards the request to the domain controller holding the PDC emulator role. This is because the client system's domain controller might not have the most current password, and as a design feature of Active Directory, the domain controller holding the PDC emulator role always will. 
3. The PDC emulator tries the password again, and if it is still found to be wrong, the PDC emulator increments the badPwdCount attribute on the user account.
4. An event ID 4740 is generated on the PDC emulator with the client system IP address that initiated the original request and with the user account.
5. The PDC emulator then informs the client system's domain controller that the password is, in fact, wrong.
6. The client system's domain controller then notifies the client system that the password was wrong.

Where would be the best place to find the source? The answer is at the PDC emulator. The reason for that is because every account lockout is recorded there in the security event log. The PDC emulator is a central place that can be queried for all account lockout events.

Using PowerShell To Track Down The Source Of AD Account Lockouts

To query the PDC emulator, we'll use PowerShell's Get-WinEvent cmdlet. This is an extremely useful cmdlet for quickly parsing through one or more event logs on a server. We're looking for an event ID of 4740. First, we need to find the domain controller that holds the PDC emulator role. One way to do this is by using the Get-AdDomain cmdlet.

Once we know the PDC emulator, then it's just a matter of querying its security event log for event ID 4740.

I have an account called abertram that is locked out. Let's see how to track down the culprit.

We've got the PDC emulator now, so let's query its security log with a PowerShell script.

## Define the username that’s locked out
$Username = ‘abertram’

## Find the domain controller PDCe role
$Pdce = (Get-AdDomain).PDCEmulator

## Build the parameters to pass to Get-WinEvent
$GweParams = @{
     ‘Computername’ = $Pdce
     ‘LogName’ = ‘Security’
     ‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}

## Query the security event log
$Events = Get-WinEvent @GweParams

This gives us the lockout event.

But we don't have the originating client system yet. To get that, we'll have to dig a little deeper. The actual username is buried in each event's Properties value. To find the username in each event, we can simply use this line.

$Events[0].Properties[0].Value

This finds the username in the first event and in the first instance of the Properties value. Luckily, the client system is just in the second instance of Properties.

$Events[0].Properties[1].Value

Once you know where the client system name is located, it's just a matter of inserting it into a loop, and we've found the culprit.

Now you're armed and ready to go the next time the help desk rings you with that incessant AD user account that keeps getting locked out.