Unlock a Colleague’s Account Without Sharing Passwords

TL;DR — If a colleague is locked out, do not ask for or share passwords. Use your admin dashboard or identity provider (the company login system, such as Microsoft Entra ID, Google Workspace, Okta, or your app’s own admin area) to unlock the account, clear failed sign-in lockouts, and send a password reset or magic-link sign-in email to the user. Reading time: ~5 min

Goal

When you finish, your colleague will be able to sign in to their own account again using their own password, a reset link, or their normal single sign-on (SSO, company login) flow, and no password will have been shared with anyone.

Prerequisites

• An admin account for the affected application, or admin access to your identity provider
• Permission to manage users: look for roles such as Admin, User Admin, Help Desk Admin, or equivalent
• The colleague’s exact login identifier: usually their work email address
• A way to contact the colleague directly so they can complete a reset or sign-in test
• If your company uses SSO, know which system handles login: Microsoft Entra ID, Google Workspace, Okta, or another provider
• If your app sends reset emails, access to the user’s correct email address and awareness that mail delivery can take 1-5 minutes

Steps

Step 1: Confirm where the lockout is happening

Open the sign-in page your colleague uses and ask them to read the exact error text. Then check one of these places:

• In your application’s admin area: Admin/Admin Console → Users → [search for user email]
• In your identity provider’s dashboard (examples):
  • Microsoft Entra ID: Microsoft Entra admin center → Users → All users → [user]
  • Google Admin: Admin console → Directory → Users → [user]
  • Okta: Admin Console → Directory → People → [user]

What you should see when this succeeds: you can identify whether the account is locked in the app itself, in the company login provider, or both.

Step 2: Unlock the account in the application admin dashboard

In your application’s admin area, go to:

Admin/Admin Console → Users → [search for user email] → Security/Authentication

Look for one of these exact actions and click it if present:

• Unlock account
• Clear lockout
• Reset failed login attempts
• Re-enable sign-in

If the app asks for confirmation, choose:

Confirm or Unlock

What you should see when this succeeds: the user status changes from Locked, Disabled after failed attempts, or similar to Active or Unlocked.

Step 3: If your company uses SSO, unlock the user in the identity provider too

If the app signs users in through the company login page, unlock the user there as well.

Use the matching menu path below:

• Microsoft Entra ID: Microsoft Entra admin center → Users → All users → [user] → Authentication methods / Sign-in logs / Account settings Then use the available action such as Require password change, Revoke sessions, or the tenant’s Smart lockout recovery process if shown.

• Google Workspace: Admin console → Directory → Users → [user] → Security Then use the available action such as Reset password, Turn off login challenge if your policy allows it, or confirm the account is not Suspended.

• Okta: Admin Console → Directory → People → [user] → More Actions Then click one of:

  • Unlock Account
  • Reset Password
  • Clear User Sessions

What you should see when this succeeds: the identity provider no longer shows the user as locked out, suspended, or blocked by failed sign-in attempts.

Step 4: Send a password reset or passwordless sign-in link to the colleague

Do not create a temporary password and send it over chat or email. Use the built-in reset flow.

In the application admin area or identity provider, click one of these exact actions if available:

• Send password reset email
• Send reset link
• Generate magic link
• Reset password followed by Send email to user

If there is a checkbox for delivery, use:

Email the reset instructions to the user

If your system only supports a manual reset and shows a one-time link, send only the link to the colleague through your normal work chat or email. Do not open the link yourself.

What you should see when this succeeds: a confirmation message such as Password reset email sent or Magic link sent appears.

Step 5: Clear active sessions only if the user still cannot sign in

If the account is unlocked but the user still gets bounced back to the login page or sees repeated failures, clear old sessions (saved sign-in state in the browser or provider).

Use the available action in one of these places:

• App admin area: Users → [user] → Sessions → Revoke all sessions
• Microsoft Entra ID: Users → [user] → Revoke sessions
• Okta: Directory → People → [user] → More Actions → Clear User Sessions
• Google Workspace: use the app’s own session revoke option if available; Google’s exact controls vary by product

⚠️ Revoking sessions signs the user out on other devices. If they are in the middle of work on another signed-in device, tell them first.

What you should see when this succeeds: the system confirms that current sessions or refresh tokens (longer-lived sign-in tokens) were revoked.

Step 6: Have the colleague sign in themselves

Ask the colleague to do exactly this:

1. Open a private/incognito browser window.
2. Go to the normal sign-in page.
3. Enter their own work email.
4. Use either:
   • their existing password if the account was only locked, or
   • the reset link or magic link you sent in Step 4
5. Complete MFA (multi-factor authentication, such as an authenticator app or text code) if prompted.

What you should see when this succeeds: the colleague reaches the application home page or dashboard without a lockout message.

Verify it works

Use these checks to confirm the fix end to end:

1. In the admin dashboard, the user status shows Active, Unlocked, or equivalent.
2. The colleague can sign in from a private/incognito window and reach the app’s main page.
3. If your system has sign-in logs, open:
   • App admin area: Users → [user] → Login history / Audit log
   • Identity provider: Users → [user] → Sign-in logs / System log

You should see a recent successful event such as:

Status: Success
User: colleague@company.com
Action: Sign in

1. If sessions were revoked, the new session timestamp should be newer than the revoke time.

Common pitfalls

Unlocking the app account but not the SSO account

Mistake: You click Unlock account in the application, but the user signs in through Microsoft, Google, or Okta and is still locked there.

Symptom: The user still sees account locked, too many attempts, or gets sent back to the company login page with an error.

Fix: Repeat the unlock in the identity provider dashboard using Step 3.

Sending a temporary password over chat or email

Mistake: An admin resets the password and sends the new password to the colleague.

Symptom: The user can sign in briefly, but the process creates security risk and often breaks audit expectations.

Fix: Use Send password reset email, Send reset link, or Generate magic link instead.

The user is actually suspended or disabled, not locked

Mistake: You look only for Unlock and miss that the account status is Suspended, Disabled, or Blocked.

Symptom: There is no unlock button, or unlock succeeds but sign-in still fails immediately.

Fix: In the user record, change the status back to Active or Unsuspended, then retry the sign-in.

Old browser sessions keep looping back to login

Mistake: The account is fixed, but the browser still holds stale cookies (saved sign-in data).

Symptom: The user enters the right credentials and returns to the login page again.

Fix: Have the user open a private/incognito window, or clear sessions in Step 5 and try again.

Reset email goes to the wrong address or is delayed

Mistake: The user’s email address in the account record is outdated, or the reset email is still in transit.

Symptom: The admin sees email sent, but the colleague never receives it.

Fix: Confirm the exact email on the user profile, resend once, then ask the colleague to check spam/junk and any mail quarantine tool your company uses.

MFA is the real blocker

Mistake: The password reset works, but the user lost their phone or authenticator app and cannot complete MFA.

Symptom: Sign-in reaches the MFA prompt and stops there.

Fix: In the identity provider or app admin area, use the user’s security settings to Reset MFA, Require re-enrollment, or add a temporary approved method according to your company policy.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.