Active Directory account locking out after password reset

Several end-users account locking out after recently resetting their domain password.

Our domain policy is lockout Threshold 3 attempts. They are getting locked out after 1 try. Once the user logs in, any network or domain resources they try to get to prompt them for their credentials because they are locked out. Their domain account shows locked in AD as well.

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 lockout for no reason whatsoever. Or so you think.

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 Get-AdDomain cmdlet.

Write-Host -Object 'Enter a samaccountname'
$Input = Read-Host -Prompt 'Username :'
If ($Input) {
    ## Define the username that’s locked out
    $Username = "$($Input)".Trim();

    ## 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;

    $Events |  ?{$_.Message -match "locked out"} | select -Property TimeCreated, @{l='Account Name';e={$_.Properties[0].Value}} , @{l='Computer Name';e={$_.Properties[1].Value}} | FT
}