A+ Lab 5 — Password Reset: Account, Lockout, or Policy?
This lab trains one of the most common help desk workflows: “I can’t log in.” Your job is to avoid blind resets and determine whether the real issue is the wrong account, an account lockout, or a password policy requirement.
User reports: “My password isn’t working and I need to get back in right away.”
Priority: Medium to High • Scope: Single user account • Goal: determine whether the issue is the username/account, lockout state, or policy/reset requirement.
⏱ 20–30 minutes • 📊 Beginner / early A+ • Goal: identify → verify → reset properly → confirm access.
What a Real Tech Should Ask First
- What username or account are they trying to use?
- Did they recently change their password?
- Are they getting “incorrect password,” “account locked,” or “must change password”?
- Is the account local, Microsoft, or domain-based?
Print mode auto-shows all steps and hides the hero image + progress UI.
What You Need
- A Windows PC, VM, or demo environment
- A local or test user account you can safely manage
- Identify the correct account
- Recognize a lockout vs bad password
- Reset or unlock only when appropriate
Don’t immediately reset the password. First verify the account being used, the error shown, and whether policy or lockout is the real cause.
Real-World Translation
Password and login tickets happen constantly in offices, schools, clinics, warehouses, and remote environments.
A real support tech follows a clean chain: account → status/lockout → policy/reset → verify sign-in.
Break / Diagnose / Fix
Create a safe account problem you can diagnose.
Option A — Wrong password attempts
- Use a test account.
- Enter the wrong password several times.
- Observe whether the account becomes locked or continues to reject the password.
Option B — Forced password change scenario
In a safe lab environment, simulate a situation where the user must change the password at next sign-in.
Option C — Wrong account format
Try signing in with the wrong username, old username format, or wrong local/domain context.
Confirm the symptom
You should see one of these patterns: bad password, account lockout, or password policy/change prompt.
Isolate whether the issue is identity, lockout, or password rules.
Check in this order
- Confirm the exact username/account the user should be using.
- Ask what error message they see.
- Determine whether the account is local, Microsoft, or domain-based.
- Check whether the account is locked out, disabled, expired, or forced to change password.
- Only then perform a reset or unlock if appropriate.
What healthy vs broken looks like
- Correct account → username format matches the actual account context
- Wrong account → correct password still fails because user is signing into the wrong identity
- Lockout → too many failed attempts caused access to be temporarily blocked
- Policy issue → password expired, must be changed, or reset does not meet complexity rules
Look for clues
- Did the user recently change their password on another device?
- Are they typing an old cached password?
- Does Caps Lock or keyboard layout appear to be wrong?
- Is there a domain prefix or local account selector involved?
Example logic: 1. Confirm username 2. Confirm exact error 3. Check account status 4. Unlock or reset only if needed 5. Verify successful login
Correct the access problem and confirm the user can actually sign in.
Possible fixes
- Guide the user to the correct account or sign-in format.
- Unlock the account if a lockout occurred.
- Reset the password if identity is verified and reset is appropriate.
- Make sure the new password meets policy requirements.
- Advise the user to sign in and update saved credentials if needed.
Verify
- Confirm the user can sign in successfully
- Confirm the account is no longer locked
- Confirm the password change was accepted
- Confirm the original user symptom is resolved
A reset is not the finish line. The real proof is a successful login with the correct account and no policy errors.
Expected output / success signs
- User authenticates successfully
- No lockout or expiration warning remains
- Password accepted under policy rules
- User confirms access restored
Write the ticket note
Use: Symptom → Checks → Actions → Result
What This Skill Maps To
- User account troubleshooting
- Password reset workflow
- Account lockout recognition
- Policy / complexity awareness
- Ticket documentation discipline
Self-Check Quiz (Unlock Next Lab)
Score ≥ 75% to unlock the next lab link. Your score is saved on this browser.
1) Before resetting a password, what should a technician verify first?
2) Which situation best describes an account lockout?
3) Which is a policy-related password issue?
4) Which ticket note is strongest?
Next Lab
Tip: update the next lab link when the page exists.