In this article, we’ll show you how to track user account lockout events on Active Directory domain controllers, and find out from which computer, device, and program the account is constantly locked out. You can use the Windows Security logs, PowerShell scripts, or the Account Lockout and Management tool (Lockoutstatus.exe) to find the source of user account lockouts in AD.
The Active Directory domain account security policy in most organizations requires that a user account be locked out if a bad password is entered several times in a row. Usually, the account is locked by the domain controller for several minutes (5-30), during which the user can’t log in to the AD domain. After some time (set by the domain security policy), the user account is automatically unlocked. Temporary AD account lockout reduces the risk of brute-force attacks against AD user accounts.
If the user account in the domain is locked out, a warning appears when trying to log in to Windows:
The referenced account is currently locked out and may not be logged on to.
You can check if the account is locked using the ADUC graphical console or with the Get-ADUser cmdlet from the Active Directory module for PowerShell:
Get-ADUser -Identity jsmith -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout
The user account is now locked ( Lockedout = True ) and cannot be used for authentication in the domain. Also in the output of the command, you can see information about the last time the user’s password was changed in the domain and the time the account was locked out.
You can list all currently locked accounts in a domain using the Search-ADAccount cmdlet:
Search-ADAccount -UsersOnly -lockedout
You can manually unlock an account using the ADUC console without waiting till it is unlocked automatically. Find the user account in AD (use the search option in AD snap-in), 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.
You can also immediately unlock a user account with the following PowerShell command:
Get-ADUser -Identity jsmith | Unlock-ADAccount
You can check the account lockout time, the number of failed password logon attempts, and the time of the last successful logon in the account properties in the ADUC console (on the Attribute Editor tab) or using PowerShell:
The account lockout policies are usually set in the Default Domain Policy for the entire domain using the gpmc.msc snap-in. The policies we are interested in are located in the Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy. These are the following policies:
To protect against password brute-force attacks, it is recommended to use strong user passwords in AD (use a password length of at least 8 characters and enable complexity requirements). This is configured in the Password Policy section in the Password must meet complexity requirements and Minimum password length options.
The cases when the user forgets the password and causes the account lockout themselves occur quite often. If the user has recently changed the password and forgot it, you can reset it. 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 was locked out for some reason. The administrator can unlock the account manually at the user’s request, but after a while, the situation may repeat.
In order to solve the user’s problem, the administrator needs to find which computer and program the user account in Active Directory was locked from.
First of all, an administrator has to find out from which computer or device occur bad password attempts and goes further account lockouts.
To enable account lockout events in the domain controller logs, you need to enable the following audit policies for your DCs. Go to the GPO section Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff and enable the following policies:
Then go to the Account Management section and enable the policy:
The easiest way to enable this policy is through the gpmc.msc console by editing the Default Domain Controller Policy.
If the user enters an incorrect password, then the domain controller closest to the user (LogonServer) redirects the authentication request to the DC with the PDC emulator FSMO role (this particular DC is responsible for processing account locks). If authentication fails on the PDC as well, it responds to the first DC that authentication failed. If the number of failed authentication attempts exceeds the value set for the domain in the Account lockout threshold policy, the user account is temporarily locked.
In this case, an event with EventID 4740 is recorded in the Security log of both domain controllers. The event contains the DNS name (IP address) of the computer from which the initial request for user authentication came. In order not to parse the logs on all DCs, it is easiest to look for the lockout events in the security log on the PDC. You can find the Primary domain controller in your domain as follows:
The domain account lockout events can be found in the Security log on the domain controller (Event Viewer -> Windows Logs). Filter the security log by the EventID 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 is locked (the username is listed in the Account Name value and the event description “A user account was locked out”).
Note. In a large AD environment, many events are written to the security log on the domain controllers, which newer ones gradually overwrite. Therefore, it is advisable to increase the maximum log size on DCs and to start looking for the lockout source as soon as possible.
Open this event. The name of the computer (server) from which the account lockout event was logged is specified in the Caller Computer Name field. In this case, the computer’s name is DACZCZL5-Z.
If the Computer Name field contains an unknown computer/device name that doesn’t resolve on your network via DNS (a non-domain computer, or a non-Windows device that supports Kerberos authentication), you can get the IP address of this device. To do this, you must enable the following audit settings in the Default Domain Controller Policy. Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Configuration and enable the following audit options:
Open the Event Viewer -> Security log and enable the filter on Event IDs 4740 and 4741. Notice that now before the user lockout event (4740) occurs, the event 4771 ( Kerberos Authentication Failed ) from the Kerberos Authentication Service appears. It contains the name of the user who tried to authenticate and the IP address of the device (field Network Information -> Client Address) from which the auth request came.
If the remote device uses NTLM domain authentication, you should look for EventID 4625 (NTLM Authentication Failed) on DCs (it is only contained on the domain controller through which NTLM authentication was attempted).
Open the last event with EventID 4625 for your user (Account name). Here you can see that when trying to perform NTLM authentication (Authentication Package: NTLM , Logon Process: NtLmSsp ), the account was locked out ( Failure Reason: Account locked out , Status: 0xC0000234 ). The event description contains both the computer name (Workstation Name) and its IP address (Source Network Address).
If you cannot find the user lockout source in the Event Viewer log, you can enable debug logging for the netlogon on the domain controller. Run the command:
Restart the Netlogon service
net stop netlogon && net start netlogon
Search the netlogon.log file for events:
You can find the lockout events for the user a.baker in the netlogon.log file using the command:
type C:\Windows\debug\netlogon.log | findstr a.baker| findstr /i "0xC000006A"
In this example, you can see that the user a.baker is locked out from the DESKTOP-12361B device.
Be sure to disable advanced netlogon logging on the DC after debugging is complete:You can use the following PowerShell script to find the source of a specific user’s account lockout on the PDC event logs. The following script searches for events with an Event ID 4740 in the Security Event Log on PDC and returns the lockout time and the name of the computer from which it occurred:
$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
Similarly, you can query all of the domain controllers in Active Directory using 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
>
You can use the graphical Lockoutstatus.exe tool from Microsoft Account Lockout and Management Tools pack to find the source of user account lockouts (you can download it here). This utility checks the account lockout status on all domain controllers.
Run the Lockoutstatus.exe tool, specify the name of the locked account (Target User Name) and the domain name (Target Domain Name).
Microsoft Account Lockout and Management Tool" width="374" height="339" />
The list that appears will contain the list of DCs and account status (Locked or Non Locked). Additionally, the lock time and the computer from which this account is locked out are displayed (Orig Lock).
You can unlock the user account, or change a password directly from the Lockoutstatus window.
The main drawback of the LockoutStatus tool is that it queries all domain controllers for a rather long time (some of them may not be available).
So, we have found from which computer or device the account was locked out. Now it would be great to know what exactly program or process is making failed login attempts and is the source of the account lockout events.
Often, users start complaining about locking their domain accounts after changing their passwords. In most cases, this means that the old (incorrect) password is saved in a certain program, script, or service that periodically tries to authenticate on a DC with the bad old password. Let’s look at the most common places where a user might have saved an old password:
Sometimes user passwords can be stored in the SYSTEM context. You can list them if you open the command prompt as LocalSystem (using the psexec tool) and run the command rundll32 keymgr.dll,KRShowKeyMgr to show saved passwords for NT AUTHORITY\SYSTEM.
To perform a detailed account lockout audit on a computer you found in DC logs, you must enable a number of local Windows audit policies. To do it, open a local Group Policy Editor ( gpedit.msc ) on a computer (on which you want to find the lockout source) and enable the following policies in the section Computer Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy:
Wait for the next account lockout and find the events with the Event ID 4625 in the Security log. In our case, this event looks like this:
An account failed to log on. Failure Reason: Account locked out.
As you can see from the event description, the source of the account lockout is the mssdmn.exe process (Sharepoint component). In this case, the user needs to update the password on the Sharepoint web portal.
After the troubleshooting is over and the lockout reason is detected and eliminated, don’t forget to disable local audit policies.
If you still couldn’t find the account lockout source on a specific computer, just try to rename the user account in Active Directory change the user’s SAMaccountName and UPN in the AD). This is usually the most effective method of protection against sudden locks of a specific user if you could not establish the lockout source.
