Skip to main content
Account lockouts are one of the most common helpdesk tickets in organisations using Active Directory. They are frustrating for end users and time-consuming to diagnose if you do not know where to look. Most lockouts stem from a predictable set of causes — stale saved credentials, mobile devices using an old password, or mapped drives that have not been updated after a password change — and all of them leave an auditable trail you can follow.

Why Accounts Get Locked Out

Understanding the root cause prevents the account from locking again minutes after you unlock it.
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.
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 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.
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.
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.
  1. Open Active Directory Users and Computers (ADUC) — press Windows + R and run dsa.msc.
  2. Locate the user account. Use Find (Ctrl + F) and search by username or display name if you do not know the OU.
  3. Right-click the account and select Properties.
  4. Go to the Account tab.
  5. Tick Unlock account (the checkbox reads “Account is locked out” when locked) and click Apply → OK.
You can also unlock an account directly from PowerShell without opening the GUI, which is faster when working remotely:
Unlocking the account before identifying the root cause means it will likely lock again within minutes if stale credentials are still active. Proceed immediately to the next steps.
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):
  1. Open Event Viewer → expand Windows Logs → click Security.
  2. In the right pane, click Filter Current Log.
  3. In the Event IDs field, enter 4740 and click OK.
  4. Find the most recent event for the affected username.
  5. 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.
Query lockout events via PowerShell:
Replace "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.
  1. Press Windows + R, type control keymgr.dll, and press Enter.
  2. Click Windows Credentials.
  3. Expand any entry referencing your domain, server, SharePoint, or Outlook/Teams.
  4. Click Remove for any entry associated with the user’s credentials.
  5. When prompted to re-authenticate, supply the current password.
Look specifically for entries beginning with MicrosoftOffice, Domain:, or LegacyGeneric: — these are common culprits after a password reset.
5

Check and Update Mapped Network Drives

  1. Open File Explorer and look for drives showing a red X (disconnected).
  2. Right-click the disconnected drive and select Disconnect.
  3. Reconnect the drive by browsing to the network path and providing updated credentials.
  4. 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.
  1. In the left pane, browse to Task Scheduler Library.
  2. In the central pane, check the Run As column for the affected username.
  3. Double-click the task → go to the General tab → click Change User or Password.
  4. 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.
  1. In the Exchange Admin Center (EAC) or via PowerShell, check ActiveSync devices registered to the user:
  1. Ask the user to update the corporate account password on their mobile email client, or temporarily block the device using Remove-MobileDevice if 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.
Include the username, the Caller Computer Name from the 4740 event, timestamps, and the steps you have already taken in your escalation ticket.