In this article, we’ll show you how to track user account lockout events on Active Directory domain controllers, determine from which computer and program the account is constantly locked. In order to find an account lockout source you can use the Windows security log, PowerShell scripts, or the MSFT Account Lockout and Management Tool (Lockoutstatus.exe)
- The referenced account is currently locked out and may not be logged on to
- How to Check if a User Account is Locked?
- Account Lockout Policies in Active Directory domain
- Logon Audit Policies for Domain Controllers
- Account Lockout Event ID 4740
- How to Find a Computer From Which an Account Was Locked with PowerShell?
- Microsoft Account Lockout and Management Tools
- How to Trace What a Process is Locking Domain Account?
The referenced account is currently locked out and may not be logged on to
The domain account security policy in most organizations requires mandatory Active Directory user account lockout if the bad password has been 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 domain security policy), the user account is automatically unlocked. Temporary AD account lockout reduces the risk of brute force attacks to 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 a User Account is Locked?
You can verify that the account is locked in the ADUC graphical console or using the Get-ADUser cmdlet from the Active Directory module for PowerShell:
Get-ADUser -Identity jsmith -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout
The account is now locked and cannot be used for authentication in the domain (Lockedout = True).
You can list all currently locked accounts in a domain using the Search-ADAccount cmdlet:
Search-ADAccount -lockedout
You can unlock the account manually by using the ADUC console and without waiting till it is unlocked automatically. Find the 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.
You can also immediately unlock your account using the following PowerShell command:
Get-ADUser -Identity jsmith | Unlock-ADAccount
You can check the account lockout time, the number of failed password attempts, the time of the last successful logon in the account properties in the ADUC console (on the Attribute Editor tab) or using PowerShell:
Get-ADUser jsmith -Properties Name, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name,@{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},@{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},@{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount
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 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;
- 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.
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 for some reason was locked. 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 which computer and program the user account in Active Directory was locked from.
Logon Audit Policies for Domain Controllers
To enable account lockout events in the domain controller logs, you need to enable the following audit policies for your domain controllers. 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
The easiest way to enable this policy is through the gpmc.msc console by editing the Default Domain Controller Policy, or by using the Default Domain Policy on the entire domain level.
Account Lockout Event ID 4740
First of all, an administrator has to find out from which computer or server occur bad password attempts and goes further account lockouts.
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 FSMO role (this particular DC is responsible for processing account locks). If authentication fails on the PDC, it responds to the first DC that authentication is not possible. If the number of unsuccessful authentications 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 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. In order not to analyze the logs on all DCs, it is easiest to look for the lockout events in the security log on the PDC domain controller. You can find the PDC 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 (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 a lockout has been carried out is specified in the field Caller Computer Name. In this case the computer name is TS01.
How to Find a Computer From Which an Account Was Locked 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. This script returns the lock 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 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}
}
Microsoft Account Lockout and Management Tools
To find the source of user account lockout, you can use the part of Microsoft Account Lockout and Management Tools— the Lockoutstatus.exe tool (you can download it here). This graphical tool checks the status of account lockout and lockout events 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).
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 (Orig Lock) are displayed.
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 quite some time (some of them may not be available).
How to Trace What a Process is Locking Domain Account?
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 account lockouts.
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 that are configured to run from a domain account;
- Saved credentials in the Credential Manager (in the Control Panel);
- Browsers;
- Mobile devices (for example, those used to access corporate mailbox);
- Programs with autologin or configured Windows auto login feature;
- Disconnected/idle RDP sessions on another computers or RDS servers (therefore, it is advisable to set limits for RDP sessions);
To perform a detailed account lockout audit on the found computer, 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 track 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
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 a mssdmn.exe process (Sharepoint component). In this case, the user needs to update password on the Sharepoint web portal.
After the analysis 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 source of account lockouts on a specific computer, just try to rename the user account name in Active Directory. This is usually the most effective method of protection against sudden locks of a particular user if you could not establish the lockout source.
14 comments
I followed the event id 4625 but it doesn’t tell me what app is causing the login attempts. also, no cellphone email, any idea?
Great solution and explanation.
Well summarized !
I find almost the similar article which provides step-wise instructions to identify the source of account lockouts : https://community.spiceworks.com/how_to/128213-identify-the-source-of-account-lockouts-in-active-directory
After filtering for EventID 4740>General [TAB]> “Additional Information: Caller Computer Name: __________” . Log onto “fill in the blank” servername> open <Task Mgr>Users> Log-off all instances of affected userID.
I can confirm that not only eventid 4625 can indicate a failed login but 4673 for example.
I searched for the locked-out loginname instead in event viewer, this is how I found the app to blame (it was Fiddler).
Anyway, the article set me to the right direction, so thanks!
Great It was a big help 🙂
In my case the culprit was: Print Spooler service on the computer the lockout originates. After restarting it (Print Spooler), the problem dissapeared.
Hello,
I am facing one of the issue. We are installing Window server 2016 with MDT and once any user logged in, it gets locked out. Do you have any comments, how to resolve this issue?
Thanks
Do you mean that the domain account is locked or local? Or you talking about a computer account in AD
Yes, Domain account is getting locked.
Try to enable local audit policies as described above and than check for EventID 4625 description. This way you can determine the process that caused the account lockout.
In my organization after password is being reset accounts are getting locked out and this issue repeats Everytime a user is changing the password.kindly advise what’s needs to be done
First, find the account lockout source computer/server as described in the article above.
You are a star. you made my day with the explanation and solution. Keep it up