How to Find the Source of Account Lockouts in Active Directory

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 referenced account is currently locked out and may not be logged on to

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:

How to Check if an AD User Account is Locked Out?

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

Or:

Get-ADUser jsmith -Properties Name,Lockedout, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name, Lockedout,@{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},@{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},@{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

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

Account Lockout Policies in Active Directory Domain

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:

• Account lockout threshold – after how many failed password attempts an account must be 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 – the time to reset the counter of the failed authorization attempts.

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.

Account Lockout Event IDs 4740 and 4625

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:

• Audit Account Lockout
• Audit Logon
• Audit Logoff

Then go to the Account Management section and enable the policy:

• Audit User Account Management: Success

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:

(Get-AdDomain).PDCEmulator

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”).

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:

Account Logon

• Audit Kerberos Authentication Service: Success, Failure
• Audit Kerberos Service Ticket Operations: Success, Failure

Logon/Logoff

• Audit Special Logon: Success, Failure

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:

nltest /dbflag:2080ffffff

Restart the Netlogon service

net stop netlogon && net start netlogon

Search the netlogon.log file for events:

• 0xc000006a – An invalid attempt to login has been made by the following user;
• 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

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.

Get the Source (Computer) of Account Lockouts with PowerShell

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 {$_.Properties[1].value + ' ' + $_.TimeCreated}

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 {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

Track AD Lockout Events with the Account Lockout and Management Tools

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.exetool, specify the name of the locked account (Target User Name) and the domain name (Target Domain Name).

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).

How to Find a Program Which Locks User Domain Account?

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:

• Mapped network drives (via net use);
• Windows Task Scheduler jobs;
• Shortcuts with configured RunAs mode (used to run a program on behalf of another user);
• Windows services that are configured to run under a domain account;
• Saved credentials in the Credential Manager (in the Control Panel);
  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.
• Mobile devices (for example, those used to access corporate mailbox);
• Saved (cached) passwords in programs with automatic login feature or configured Windows auto-login;
• Disconnected/idle RDP sessions on other computers or RDS farms/hosts (always set timeouts for RDP sessions);
• Saved passwords in Windows Wi-Fi network profiles (if you use WPA2-Enterprise 802.1x authentication in a wireless network).

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:

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

Then update the Group Policy settings on the client:

gpupdate /force

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.