Possible Causes of User Lockout in Active Directory
This situation exists in companies that have an Account Lockout policy when a certain number of incorrect passwords are entered, this is correct from a cybersecurity point of view as it helps protect against bruteforce attacks.
Some of the main causes for blocking are:
- Constant mapping of drives with old credentials
- Mobile devices using corporate services with old credentials
- Service accounts using cached passwords that were changed during maintenance
- Scheduled tasks with outdated passwords
- Programs using cached passwords that were changed
- Disconnected terminal server sessions
- Problems with Active Directory replication
- Improperly configured domain policy settings
- Malicious activity, such as a password bruteforce attack.
Where to Configure Account Lockout Policy
Open the Group Policy editor and create a new policy, name it e.g. Account Lockout Policy, right click it and select "Edit".
- Set the time until the lockout counter resets to 30 minutes
- The lockout threshold is 5 login errors
- Duration of account lockout - 30 minutes.
Close, apply the policy and run gpupdate /force on the target machine
How to Find Out Why the Account was Locked
Now that the policy is enabled, we need to figure out what is causing the account lockout, and from which computer or device it is coming. In order to answer this question, you need to configure a special audit policy to keep track of the relevant events from which you will be able to determine the cause of the lockout. This type of auditing is not configured by default.
Open the Group Policy Editor(gpmc.exe) again, create an Audit Policy, open it, and follow:
Computer Configuration -> Policies -> Windows Configuration -> Security Settings -> Local Policy -> Audit Policy
We need to enable logon auditing, this policy generates events 4771 and 4624. Let's set it to "Success and Failure".
We also need to set the login event audit policy to "Success and Failure" as well as "Account Management Audit" to see events 4740.
Force a policy update and run gpupdate /force on the target machine.
What events to track in the security log
An incorrect credential entry generates event 4740, on all domain controllers. With Kerberos failure codes:
- - 6 - User name does not exist
- - 12 - Login time limit
- - 18 - Account deactivated, disabled or expired
- - 23 - Expired user password
- - 24 - Preauthentication failed (wrong password)
- - 32 - Ticket expired
- - 37 - Computer time was not synchronized with domain time
NTLM error codes:
- - 3221225572 - C0000064 - This user name does not exist
- - 3221225578 - C000006A - Correct username, but incorrect password
- - 3221226036 - С0000234 - This user account is blocked
- - 3221225586 - C0000072 - Account Deactivated
- - 3221225583 - C000006E - User attempting to log on outside of specified time period
- - 3221225584 - С0000070 - Workstation limitation
- - 3221225875 - С0000193 - Account expired
- - 3221225585 - 0000071 - Password expired
- - 3221226020 - C0000224 - User must change password next time login
How to Investigate the Account Lockout Cause
Open the Event Log and go to “Security” this is where the EventIDs are collected which may help in determining the reason for the lockout. There are a lot of events, so filter them out with "Filter Current Log", this will allow us to select only the events we want. In the “Logged” field specify the time period, in the Event ID field specify 4740 and click "Ok"
Use the search (Find) to find the name of the needed account, in filtered records. Finally, events should be filtered by the specified login with the code 4740, where we can find the reason for locking. For example the field “Caller Computer Name” contains the name of the computer from which the failed logons that cause blocking are originated. Then you need to go to the target computer and inspect the event logs there to determine why this machine is trying to logged in with invalid credentials.
There are other reasons for the lockout that can be found in events 4740 such as the name of the Exchange server in the “Caller Computer Name” - this means that the problem is with Outlook, the mobile mail client or its calendar. To investigate this lockout, you need to look at the IIS logs on the Exchange server. Or you can also use the Get-ActiveSyncDeviceStatistics command in PowerShell to see the problem with mobile devices.
Microsoft ALTools
Microsoft has their own tool to help you troubleshoot account lockout issues - Microsoft Account Lockout and Management Tool (AlTools.exe). Download Account Lockout Status (LockoutStatus.exe) from Official Microsoft Download Center
This tool displays information about a locked account with its user state and lockout time on each domain controller and allows you to unlock it by right-clicking on the corresponding account.
Run LockoutStatus.exe > File > Select target > Enter account name and domain > OK
It will show you all the lockout related statuses for that account.
EventCombMT Tool
The EventCombMT Tool collects specific events from several different servers into one central location.
Run EventCombMT.exe > Right-click Select to search > Select Get DCs in Domain > Select domain controllers to search. - Click Searches > Built In Searches > Account Lockouts.
Other Causes of User Account Lockouts
If the lockout problem is caused by Google Workspaces services (Gmail, Gdrive...) then the logs will show that the failed logons are coming from the WORKSTATION computer.
Also details about the lock can be seen in the event 4771. There you can find the Kerberos codes described above and the IP address of the device from which the failed logons are coming.
If the “Caller Computer Name” of event 4770 and Client Address 4771 are empty, this means you are most likely being bruteforced!
To find out the source of the failed logons in this case, you need to enable “netlogon” debugging and look at its logs. Netlogon is a Windows Server process that authenticates users and other services in the domain. Enable Netlogon logging: Start > Run > type:
After restarting the Netlogon service, the corresponding activity can be recorded in %windir%/debug/netlogon.log.
You can also parse the Netlogon logs using a script:
Warning! Remember to switch Netlogon off after you have logged events, as system performance can be a bit slow due to the debugging process and it will use extra disk space. Disable Netlogon logging:
Start > Run > type:
In the logs you can find the IPs of the computers which are not shown in the event logs, it may be terminal servers or RDP workstations which are under password bruteforce attack.
Let's go back to the security event log. Another useful event with the event code 4776 is also where you can find the workstation you are trying to log on to.
If the IP address in your logs is unknown, you can look up the mac address on the DHCP server or on your network equipment and find out the manufacturer of the mac address with special services, which can be easily found on the Internet. This is useful when failed logons are coming from some smartphone or tablet.
Another useful thing would be to look into event 4625, there you can find the process that is causing the account lockout. Use Process Hacker or Process Monitor to see the credentials of active processes.
Windows Task Scheduler may be the problem of locking - there may be a task configured to run using an account whose password has changed.
There may be stored credentials on the local machine, which can be found like this:
Start > Run > rundll32 keymgr.dll, KRShowKeyMgr > OK.
Or Netplwiz:
Start> Run > type: netplwiz > OK Click the Advanced tab, and then click Password Management.
A terminal server session with outdated credentials can cause a lockout. To disable an RDP session, run the following commands at the command line (Win+R > "cmd"), replacing "server_ip", "name" and "password" with the required credentials
This allows you to logon to a remote server without using RDP.
Replace "name" with the server name. Here you get the session id.
This ends the active session on the remote server.
Account blocking can be caused by AD replication when a password update has not been replicated to all domain controllers. To force replication, run the following command on your DC: