Filed under Windows
Tagged as Windows Active Directory Account Lockout Credential Manager SYSTEM Context
A good domain security policy is to expire passwords every 30-180 days. Another good security practice is to lockout an account after 3-5 failed logon attempts. This keeps an attacker from quickly trying to “brute force” a user’s password.
This can also create a scenario where a cached credential causes a user account to be repeatedly locked after a password change. In this article I will explore simple steps to troubleshoot and fix this problem.
To find the cause we first need to find the source of the bad logon attempts. Once we know the source we can look closely at that machine and find the cause of the bad logons.
Finding the Source
The first step is to find the source of the failed login attempts. Lockouts are logged in the Security log on the domain controller with the PDC Emulator FSMO role, because account lockout is processed on this server. If the source is a Windows computer the name of that computer should be in the log message also.
If you don’t know the domain controller that is assigned the PDC role use this NetDom command:
Now that we know the PDC we need to search the Event Viewer for Event ID 4740. This can be done through the Event Viewer or PowerShell (at the time of this writing PowerShell Core cannot run the Get-EventLog cmdlet).
The PowerShell command to use is
To retrieve all lockout events use this command:
To search for a specific user’s lockout events modify the command to add
-Message "*username*" (replace “username” with the actual user’s username e.g.,
Before we continue, log into the “Caller Computer Name” computer. In the example above this is KFROG-SERVER.
Finding the Solution
Now we know the source of our failed logons, but why is this machine attempting to login with a bad password?
Things to check:
- Locked or disconnected sessions.
- Solution: log the user out of this session.
- Scheduled Tasks with stored credentials.
- Solution: update task run as credentials.
- Drives that have been mapped with the “Connect using different credentials” option.
- Solution: disconnect the shared drive.
- Windows Services that have been configured to run under a user account.
- Solution: update the service run as credentials.
- Phones or Tablets attempting to authenticate for email or other services.
- Solution: update the stored password.
- Web browsers with stored credentials for internal services.
- Solution: update credentials or clear all stored passwords in browser.
- Credentials stored in the Windows Credential Manager. Be sure to check for hidden SYSTEM credentials! See the section below for instructions.
- Solution: delete or update all stored credentials. This can be done via Control Panel -> User Accounts -> Credential Manager.
Hidden SYSTEM Context Credentials
Credentials can be stored under the SYSTEM user context. This means there may be credentials saved on the system that will not show in any normal user’s Credential Manager. To view these credentials we need to open the Credential Manager in the SYSTEM context.
Used these steps to open the Credential Manager as the SYSTEM user:
- Download PsTools from Microsoft. Unzip and save the tools to a location on the source computer.
- Using psexec.exe open a command prompt (cmd.exe) as the System account.
psexec -i -s -d cmd.exe
- In the new DOS prompt open the credential manager.
- Remove or Edit the stored credential.
The information in this article should be enough to resolve nearly all mystery account lockouts. Please don’t hesitate to send feedback if you feel anything here is incorrect or I missed something!
Thank you for reading!
- Kriss Milne’s Blog Post