Why Accounts Get Locked Out
Understanding the root cause prevents the account from locking again minutes after you unlock it.Failed Interactive Login Attempts
Failed Interactive Login Attempts
A user mistyping their password repeatedly is the most straightforward cause. The domain lockout policy (typically 5–10 failed attempts) triggers the lockout. Confirm by asking the user whether they recently changed their password and then tried to log in from memory.
Mobile Device with Stale Credentials
Mobile Device with Stale Credentials
A smartphone or tablet configured for corporate email (Exchange ActiveSync, Outlook Mobile) will keep retrying with the old password after a password change, silently burning through the failed-attempt threshold in seconds. The device does not warn the user — the account simply locks.
Mapped Network Drives
Mapped Network Drives
Mapped drives saved with explicit credentials (
net use with /savecred, or drives mapped via Group Policy with embedded credentials) will authenticate on every reconnect attempt, including at logon. If the password has changed and the saved credential has not been updated, each reconnect is a failed authentication.Scheduled Tasks Running as the User
Scheduled Tasks Running as the User
If a Windows Scheduled Task is configured to run under a user account and that account’s password has changed without updating the task, the task runner will generate failed authentications every time the task fires.
Windows Credential Manager
Windows Credential Manager
Saved credentials in Windows Credential Manager (
control keymgr.dll) can hold an outdated password for a server, SharePoint site, or Teams/Skype resource, causing repeated background failures.Step-by-Step Resolution
1
Unlock the Account in Active Directory Users and Computers
The first priority is restoring access to the user. Investigation comes next.
- Open Active Directory Users and Computers (ADUC) — press
Windows + Rand rundsa.msc. - Locate the user account. Use Find (
Ctrl + F) and search by username or display name if you do not know the OU. - Right-click the account and select Properties.
- Go to the Account tab.
- Tick Unlock account (the checkbox reads “Account is locked out” when locked) and click Apply → OK.
2
Identify the Lockout Source Using Event Viewer
Event ID 4740 is logged on the Domain Controller (DC) that processed the lockout. It identifies both the source machine and the caller’s computer name, giving you a precise starting point.On the Domain Controller (or via Remote Event Viewer):Query lockout events via PowerShell:Replace
- Open Event Viewer → expand Windows Logs → click Security.
- In the right pane, click Filter Current Log.
- In the Event IDs field, enter
4740and click OK. - Find the most recent event for the affected username.
- In the event details, note the value of Caller Computer Name — this is the machine sending bad credentials.
The lockout event is written on the PDC Emulator FSMO role holder, not necessarily the DC the user authenticated against. Run the query below to confirm which DC holds the PDC Emulator role.
"jsmith" with the actual SAM account name.3
Investigate the Source Machine
Once you have the Caller Computer Name from Event ID 4740, connect to that machine and look for what is sending the bad credentials.Check for failed logon attempts (Event ID 4625) on the source machine:Logon Type codes to watch for:
4
Clear Stale Saved Credentials
If the source machine belongs to the affected user, open Windows Credential Manager to remove any outdated stored passwords.
- Press
Windows + R, typecontrol keymgr.dll, and press Enter. - Click Windows Credentials.
- Expand any entry referencing your domain, server, SharePoint, or Outlook/Teams.
- Click Remove for any entry associated with the user’s credentials.
- When prompted to re-authenticate, supply the current password.
5
Check and Update Mapped Network Drives
- Open File Explorer and look for drives showing a red X (disconnected).
- Right-click the disconnected drive and select Disconnect.
- Reconnect the drive by browsing to the network path and providing updated credentials.
- To make the fix persistent, re-map with a logon script or update the Group Policy Preference that manages the drive.
6
Check Scheduled Tasks for Outdated Credentials
Open Task Scheduler (
taskschd.msc) on the source machine and look for tasks running under the affected user account.- In the left pane, browse to Task Scheduler Library.
- In the central pane, check the Run As column for the affected username.
- Double-click the task → go to the General tab → click Change User or Password.
- Re-enter the current password and click OK.
7
Check Mobile Devices and ActiveSync
If the lockout source points back to a server (e.g., your Exchange server), the originating device is almost certainly a mobile phone or tablet.
- In the Exchange Admin Center (EAC) or via PowerShell, check ActiveSync devices registered to the user:
- Ask the user to update the corporate account password on their mobile email client, or temporarily block the device using
Remove-MobileDeviceif the password update does not resolve the issue.
On Microsoft 365 / Exchange Online, you can view and wipe ActiveSync devices from Microsoft 365 Admin Center → Users → [User] → Mail → Manage email apps.
8
Confirm Resolution
After addressing the root cause, verify the account remains unlocked over the next 15–30 minutes.If
BadLogonCount continues to climb after you have cleared credentials and updated mapped drives, escalate — there may be an additional source you have not identified yet.Escalation
Escalate to a senior AD administrator or the Security team if:- The account continues to lock out every few minutes despite clearing all known credential sources.
- Event ID 4740 shows the source machine as a server you cannot identify — this may indicate a compromised service account or brute-force attack.
- Multiple user accounts are locking out simultaneously — this can indicate a domain-wide password-spray attack.
- You discover an unknown service or scheduled task using the account’s credentials.