Unlocking an account may restore access without explaining why it locked. If the problem returns, repeating the unlock isn't enough.
Trace the authentication attempts around the event. Record what happened, identify possible sources, and use evidence to narrow the cause before changing unrelated settings.
This turns a familiar support issue into an IAM learning opportunity. You can explore the reasoning safely with a disposable lab account rather than creating repeated failures against an employee account or production tenant just to obtain an example.
Record the event before changing everything
Start with the account, the reported time, the system where the user noticed the problem, and the exact message.
Ask whether the problem began after a password change, a device change, or another relevant event. These are hypotheses to investigate, not automatic explanations.
In Windows auditing, Microsoft documents event 4740 for account lockout. Available evidence depends on the environment and configured auditing.
Do not assume one event contains the entire cause. It is a useful point in a timeline that may require other records and systems to interpret.
Look for another source of authentication attempts
The user's current browser is not necessarily the only place where the account is being used.
In a fictional lab, a scheduled task or application might still be attempting authentication with an old credential. The user can type the correct password while another process continues to fail.
That possibility explains why “the user says the password is correct” does not end the investigation.
Identify the source supported by the evidence. Avoid clearing credentials everywhere or disabling controls merely because those actions appeared in a forum answer.
Distinguish directory behavior from cloud behavior
A hybrid environment may contain more than one system making authentication or lockout decisions.
Microsoft documents smart lockout separately from on-premises AD behavior. Do not treat every account-lockout message as proof that the same counter or policy was responsible.
For your explanation, identify where the failed attempt was evaluated and which system recorded the state change.
You do not need to memorize every threshold. You need to know which configuration and documentation apply to the system you are investigating.
Reproduce the lockout only in an isolated test environment
Use a disposable account and a controlled scenario. Prepare these safeguards:
- Bounded test: Define the intended sequence and keep attempts consistent with the lab's policy.
- Evidence: Enable the needed auditing and record relevant timestamps.
- Correction: Remove the identified source of repeated failures.
- Observation: Verify whether the condition returns during the stated observation period.
- Recovery: Keep management accounts separate so the test doesn't lock you out of the evidence.
Don't perform repeated login attempts against real employees or production systems to create a portfolio story.
The purpose is a cause-and-effect investigation. State what your evidence supports and how long you observed the result; don't inflate a small test into an elaborate outage.
A recovery path belongs in the setup, before the failure you intend to study.
Explain what the investigation taught you
Your portfolio note should separate the symptom, the evidence, the hypothesis, the correction, and the verification.
For example: “Unlocking the account restored access briefly. The timeline showed another test process continued to fail authentication. Correcting that process stopped the repeated lockouts in the lab.”
Only write that conclusion when your records support it. A single successful login afterward does not prove that every source was fixed.
What a locked account reveals about authentication architecture explores how this kind of investigation exposes dependencies you might otherwise miss.
The practical project guidance in The Six-Figure IAM Career Playbook helps turn familiar support issues into evidence for an identity career. The $9 book connects that work with role selection and positioning.
A lockout is not just a user inconvenience. It is evidence that something in the authentication path deserves a closer look.