In this post, I’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
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: The referenced account is currently locked out and may not be logged on to ….
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.
In order to protect your domain user accounts from password brute-force attack, it is recommended to use strong user passwords in AD (use a password length of at least 8 characters and enable password complexity requirements). This is configured in the Password Policy section with the Password must meet complexity requirements and Minimum password length policies.
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 with the following powershell command:
(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”).
In a large AD environment, a large number of events are written to the security log on the on domain controllers, which are gradually overwritten by newer ones. Therefore, it is advisable to increase the maximum log size on DCs and to start the for the lockout source as soon as possible.
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.
The badPwdCount and LastBadPasswordAttempt attributes are not replicated between domain controllers.
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. Below are 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.
