Finding the Source of Account Lockouts in Active Directory domain

In this article, we’ll describe how to monitor the events of repeated locks of user accounts on Active Directory domain controllers and determine from which computer and program a lock is being performed. We’ll show some examples of using PowerShell scripts and Windows security events to identify the source of account lockouts.

An account security policy in most organizations requires mandatory Active Directory user account lockout if the bad password has been entered n times. Usually, the account is locks by the domain controller after several attempts to enter the wrong password for a several minutes (5-30), during which the user can’t log in. After some time (set by security policies), the user account is automatically unlocked. Temporary AD account lockout reduces the risk of brute force attacks.

In the event that the user account in the domain locks, a warning appears when try to log in to Windows:

Account Lockout Policies in Active Directory domain

The account lockout policies are usually set in the Default Domain Policy for the entire domain. The necessary policies can be found in Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy. These are the following policies:

• Account lockout threshold is the number of attempts to enter the bad password till the account is locked out
• Account lockout duration for how long the account will be locked (after this time the lock will be removed automatically)
• Reset account lockout counter after is the time to reset the counter of the failed authorization attempts

Tip. You can unlock the account manually by using the ADUC console and without waiting till it is unlocked automatically. Find user account, right click and select Properties. Go to the Account tab and check the box Unlock account. This account is currently locked out on this Active Directory Domain Controller. Click OK.

The situations when the user forgets the password and causes the account lockout themselves occur quite often. But in some cases, the account lockout happens without any obvious reason. I.e. user declares that he never made a mistake when entering a password, but his account for some reason was blocked. The administrator can unlock the account manually by the user request, but after a while the situation may repeat.

In order to solve the user’s problem, the administrator needs to find from which computer and which program the user account in Active Directory was locked.

Finding the computer from which the account was locked

First of all, an administrator has to find out from which computer or server occur bad password attempts and goes further account lockout.

If the domain controller closest to the user determines that the user is trying to log in with invalid credentials, it redirects the authentication request to the DC with the PDC emulator role (this DC is responsible for processing account locks). If authentication was not performed on the PDC too, it also responds to the first DC that the user can not be authenticated.

In this case, events 4740 are recorded to the Security log of both domain controllers. The event contains the DNS name (IP address) of the computer from which the initial request for authorization of the user came. Logically, the first thing to check is the security logs on the PDC controller. You can find the PDC in the domain as follows:

(Get-AdDomain).PDCEmulator

The event of locking a domain account can be found in the Security log of the DC. Filter the security log by event with Event ID 4740. You should see a list of the latest account lockout events. From the topmost, scroll through all the events and find an event that indicates that the account of the user you are looking for (the username is listed in the Account Name value) is locked (A user account was locked out).

Open this event. Name of the computer from which a lockout has been carried out is shown in the field Caller Computer Name. In this case the computer name is TS01.

You can use the following PowerShell script to find the source of a specific user’s lock on the PDC. This script will returns the lock time and the computer name:
$Usr = ‘username1’
$Pdc = (Get-AdDomain).PDCEmulator
$ParamsEvn = @{
‘Computername’ = $Pdc
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
}
$Evnts = Get-WinEvent @ParamsEvn
$Evnts | foreach {$_.Properties[1].value + ' ' + $_.TimeCreated}

Similarly, you can query all of the domain controllers in Active Directory from PowerShell:
$Usr = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % {
$ParamsEvn = @{
‘Computername’ = $Pdc
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
}
$Evnts = Get-WinEvent @ParamsEvn
$Evnts | foreach {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

Note. If there are several domain controllers, the lockout event has to be searched in the logs for each of them. You can subscribe to the events on other DCs. This task becomes easier with Microsoft Account Lockout and Management Tools (you can download it here). With this tool, you can specify several domain controllers at once to monitor the event logs, look for the bad password count for a certain user (badPwdCount and LastBadPasswordAttempt attributes are not replicated between domain controllers). 

How to find out a program that causes the account lockout

So, we have found from which computer or server the account was locked out. Now it would be great to know what program or process are the source of the lockout.

Often, users start complaining about locking their domain accounts after changing their password. This suggests that the old (incorrect) password is saved in a certain program, script, or service that periodically tries to authenticate on a DC with a bad password. Consider the most common locations in which the user could save the old password:

• Mapped network drives (via net use)
• Windows Task Scheduler jobs
• Windows services
• Saved credentials in the Credential Manager (in the Control Panel)
• Browsers
• Mobile devices (e. g., those used to access the corporate mail service)
• Programs with autologin
• Disconnected/idle sessions on another computers or RDS servers

To perform a detailed lockout audit on the found computer, a number of local Windows audit policies should be enabled. To do it, open a group policy editor (gpedit.msc) on a local computer (on which you want to track the lock source) and enable the following policies in section Computer Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

Wait till an account is locked out again and find the events with the Event ID 4625 in the Security log. In our case, this event looks like this:

As you can see from the description, the source of the account lockout is a process mssdmn.exe (Sharepoint component). In this case, the user needs to update password on the Sharepoint web portal.

After the analysis is over and the reason is detected and eliminated, don’t forget to disable the audit policies.

In the event that you could not find out the reason for blocking an account on a specific computer, in order to avoid permanent locking of accounts, it is worth trying to rename the user account name in AD. This is usually the most effective method of protecting against sudden locks of a particular user.