account locked" but user didn't mistype: what to check

TL;DR

Believe the user and look for the real source: check the lockout event (4740 in AD, system log in Okta) for the caller machine, then hunt the stale credential on that device (saved Wi-Fi, mapped drives, phone mail, scheduled tasks). The user is usually right that they did not mistype; something else is authenticating as them.

The error

The referenced account is currently locked out. (User: "I typed it right!")

Steps

1. Find the lockout source: AD event 4740 on a DC (Caller Machine Name) or Okta system log (client IP and user agent). Expected: one device identified. This is the investigation, not the user's keyboard.
2. On that device, check the usual suspects in order: saved Wi-Fi password, mapped network drives with stored credentials, Outlook or phone mail with an old password, scheduled tasks or services running as the user. Expected: one of them has the old password.
3. Fix the stale credential and unlock the account. Expected: no relock. Unlocking before fixing the source guarantees a repeat ticket.
4. Check the failure timestamps: evenly spaced attempts 24/7 suggest a script or service, not a human. Expected: pattern identified. Bursts from many IPs suggest an attack, not a typo.
5. If no device is found, check for cached credentials on shared machines and RDS sessions. Expected: source found. Shared PCs with "remember me" are a classic.

When to use

• User disputes the lockout cause
• Repeat lockouts with no user action

When not to use

• User admits to typos (just unlock and move on)
• Clear brute-force pattern (treat as security incident)

Compatibility

• Active Directory (event 4740) and Okta (system log)

Variants

Lockouts only happen at night

A scheduled task or backup job with an old password. Check Task Scheduler on the user's machines.

Lockouts from a foreign country

Possible credential stuffing. Check whether the password was in a breach and treat as an incident.

Why it happens

Modern users authenticate from many places: laptop, phone, tablet, Wi-Fi, VPN, mail. Any one of them with an old saved password keeps knocking with the wrong key, and the user never sees it happen.

Edge cases

• Biometric unlock (Windows Hello, Touch ID) can mask a changed password until the cached credential is used somewhere new.
• After a password change, tell users to update Wi-Fi and mail on ALL devices proactively.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOcdzuuFeUVdTBEFceYlEw

Resolved from the public thread: https://vectle.com/posts/pstOcdzuuFeUVdTBEFceYlEw

Thread query: "account locked" but user didn't mistype: what to check

TL;DR: Believe the user and look for the real source: check the lockout event (4740 in AD, system log in Okta) for the caller machine, then hunt the stale credential on that device (saved Wi-Fi, mapped drives, phone mail, scheduled tasks). The user is usually right that they did not mistype; something else is authenticating as them.