Skip to content

Guide

How to Troubleshoot an Account Lockout Properly

Illustration of an opening padlock beside a user account record and its sign in history

Short answer

Verify the identity of the caller, unlock the account in Active Directory, then find the cause before you close. Most repeat lockouts come from a saved password somewhere the user has forgotten about: a phone still collecting mail, a mapped drive, a scheduled task, or a second machine left signed in. The sign in history on the account tells you which device kept trying.

A lockout is the most common ticket on any service desk, and it is the one most often closed badly. The account is locked, you unlock it, the user gets back in, everybody is happy. Then it locks again at lunchtime, and the ticket comes back with a tired person on the other end of it.

How to work a lockout so it does not come back

  1. Verify who you are speaking to before you touch anything. This is the step an attacker is counting on you to skip.
  2. Look at the account and confirm it is genuinely locked rather than disabled or expired. Those three states look identical to the user and need different fixes.
  3. Unlock it, and only reset the password if it is also expired or genuinely forgotten.
  4. Read the failed sign in history. Note the source device and how close together the attempts were.
  5. Ask the user about that device by name. A phone still set up with the old password is the single most common answer, followed by a computer they left signed in somewhere else.
  6. Have them update or sign out of that device while you are still on the call, then watch for one more failure before you close.

Where repeat lockouts actually come from

  • A phone or tablet still collecting company mail with an old password.
  • A mapped network drive that reconnects with saved credentials at sign in.
  • A saved credential in the Windows credential store, often for a share or a printer.
  • A scheduled task or service configured to run as the user.
  • A second computer, or a remote session, still signed in with the previous password.
  • Somebody genuinely mistyping it, which is worth ruling in rather than assuming.

Write the cause in the closeout, not just the action. A note that says the account was unlocked tells the next technician nothing. A note that says the account was unlocked and a phone still holding the previous password was updated on the call tells them the ticket is finished, and tells them where to look first if it is not.

Common questions

Why does an account keep locking out after being unlocked?
Because something is still presenting the old password. A mail app on a phone, a mapped network drive, a saved credential in Windows, a scheduled task or a second computer left signed in will all retry on their own schedule and lock the account again within minutes. Unlocking without finding that source produces the same ticket tomorrow.
How do you find what is locking an account?
Read the failed sign in events on the account. They name the source device and the time, which usually points straight at the phone or the second machine that is still holding the old password. If several failures come from one hostname the user does not recognise, that is the thing to chase.
Should you reset the password when you unlock an account?
Only if the password is also expired or the user cannot remember it. An unlock and a reset are different actions, and resetting unnecessarily forces the user to update every device that holds the old one, which creates the very problem you were trying to avoid.
How do you verify identity on a lockout call?
Ask for something the account record can confirm and an impersonator would not have, following whatever your organization has agreed. Never ask for the existing password, and never accept an email from an address you have not checked. Skipping this step is how a help desk hands an account to an attacker.

Related guides