🔧 Recipe · Troubleshooting & Diagnostics

Investigate a User's Sign-In Failures and Remediate Access Issues

Diagnose Microsoft 365 sign-in failures, identify root cause from sign-in logs, and apply the appropriate remediation (password reset, MFA reset, or session revocation)

Complexity

Intermediate

Impact

user-access + security + troubleshooting + identity

Context

Why This Matters

When a user reports they can't sign in to Microsoft 365, the fastest path to resolution is a structured investigation: locate the account, review recent sign-in telemetry, identify the failure signature, and apply a targeted fix. Jumping straight to a password reset without reading the logs often masks the real issue (MFA gap, Conditional Access block, legacy auth attempt, risky sign-in lockout, or a disabled account).

This recipe walks through the standard triage flow used by the Dex CoAdmin troubleshooting skill. The example scenario — a user blocked by error AADSTS53003 ("MFA required but not completed") because they have no MFA method registered — is one of the most common patterns, but the same investigation pattern applies to account lockouts, Conditional Access blocks, expired passwords, and risky sign-in quarantines.

Run this recipe when:

A user submits a "can't log in" ticket
A helpdesk escalation mentions MFA prompts failing
You see a spike in failed sign-ins for a specific account in the Entra dashboard
Security flags risky sign-in activity on an account

Expected Outcomes

After completing this recipe you will have:

Confirmed the target user's account state (accountEnabled, UPN, object ID)
A summary of the last 25–50 sign-in attempts with error codes, failure reasons, apps, IPs, locations, and risk signals
An identified root cause (MFA gap, bad password, Conditional Access block, risky sign-in, legacy auth, disabled account, etc.)
An appropriate remediation applied — typically one or more of: password reset with forced change, MFA method reset, session revocation, or account re-enablement
Verification that the fix worked (new successful sign-in or the user confirming access)
An audit trail of every action taken (Graph API calls, approval records, before/after state)

Risks & Considerations

Before you remediate:

Verify identity. Never reset a password or revoke sessions based on an email request alone. Confirm the requester is the real user (callback to their known mobile, manager confirmation, or a verified ticket system).
Read the logs first. Resetting a password won't fix a Conditional Access block, a disabled account, or a missing license. Misdiagnosis wastes time and can alarm the user unnecessarily.
Check for compromise indicators. Sign-ins from unusual countries, impossible travel, or high risk levels may indicate a compromised account. Escalate to security rather than just resetting the password — a malicious actor may still hold the recovery channels.
Communicate the temporary password out-of-band. Send via SMS, voice call, or an authenticated chat channel — never via the user's own mailbox (they can't read it) and never plaintext in a ticket.

Compliance considerations:

Password resets and session revocations are logged in the Entra audit log and are discoverable. Include a business justification in ticket notes.
Some regulated environments (PCI, HIPAA) require a second approver for privileged account password resets. Check your policy before running the recipe against an admin account.
Do not disable MFA as a "fix" — reset the methods and have the user re-register. Disabling MFA creates a standing security gap.

Required Permissions

Permission	Why It's Needed
User.Read.All	Resolve the target user's identity, object ID, and account state
User.ReadWrite.All	Reset the user's password and force change on next sign-in
AuditLog.Read.All	Read the sign-in logs to identify failure patterns and error codes
UserAuthenticationMethod.ReadWrite.All	Inspect and reset the user's MFA methods when MFA is the root cause
Directory.AccessAsUser.All	Revoke the user's active sign-in sessions via revokeSignInSessions

The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.

For IT Admins

Paste into Dex Pro

{user} can't log in to Microsoft 365. Investigate recent sign-in failures, identify the likely cause, and apply the appropriate fix (e.g., reset password, reset MFA, or revoke sessions), then confirm access is restored.

Try in Dex Pro

For End Users

How an employee would ask Dex for help

I can't sign in to my work account — it keeps failing.

Try in Dex Playground

Investigate and remediate via Microsoft Entra admin center

Step 1 — Locate the user

Open the Microsoft Entra admin center.
Navigate to Identity > Users > All users.
Search for the user by display name or UPN (e.g., Ford Russel or ford_russel8@contoso.com).
Click the user to open their profile. Confirm Account enabled is Yes and note the Object ID.

Step 2 — Review sign-in logs

On the user's profile page, click Sign-in logs in the left navigation (or go to Monitoring & health > Sign-in logs and filter by user).
Set the time window to Last 7 days.
Review the Status column — click any row with a red "Failure" entry.
In the detail pane, read the Basic info tab: note the Sign-in error code and Failure reason. Common codes:
- 50053 — Account locked
- 50055 — Password expired
- 50057 — Account disabled
- 53003 — MFA required but not completed / Conditional Access block
- 50126 — Invalid username or password
- 50074 — MFA claim missing
Check the Conditional Access tab to see if a policy blocked the sign-in.
Check the Authentication Details tab to see which MFA methods were attempted.

Step 3 — Inspect authentication methods

Back on the user's profile, click Authentication methods.
Review registered methods. If only Password is listed (no Authenticator, phone, or FIDO key) and MFA is required by policy, that's the root cause.

Step 4 — Apply remediation

Based on the error code, choose one of the following:

MFA gap / error 53003: Click Reset password at the top of the profile. Note the temporary password. On next sign-in, the user will be prompted to register an MFA method.
Account disabled / error 50057: Toggle Account enabled to Yes and click Save.
Stale or compromised sessions: Click Revoke sessions at the top of the profile to invalidate all refresh tokens.
MFA method broken (lost phone): On Authentication methods, click Require re-register multifactor authentication and delete any stale methods.

Step 5 — Communicate and verify

Call or SMS the user with the temporary password (never email it to their own mailbox).
Ask the user to sign in to portal.office.com and complete the new-password + MFA-registration flow.
Return to Sign-in logs after 5 minutes and confirm a new Success entry for the user.

Investigate and remediate via Microsoft Graph

1. Resolve the user

Find the user's object ID. Prefer a direct UPN lookup when you have it; otherwise search by display name.

GET https://graph.microsoft.com/v1.0/users?$filter=userPrincipalName eq 'ford_russel8@contoso.com'&$select=id,displayName,userPrincipalName,accountEnabled

Response:

{
  "value": [{
    "id": "88abf85c-4710-4fdb-b622-48ba4fb89635",
    "displayName": "Ford Russel",
    "userPrincipalName": "ford_russel8@contoso.com",
    "accountEnabled": true
  }]
}

If accountEnabled is false, skip ahead to step 5 (re-enable).

2. Pull recent sign-in logs

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=userId eq '{userId}'&$top=50&$orderby=createdDateTime desc

Scan the response for entries where status.errorCode != 0. Key fields:

status.errorCode and status.failureReason — the root cause code
appDisplayName / clientAppUsed — which app the user was hitting (legacy protocols like IMAP4/POP3 often indicate a modern-auth gap)
ipAddress, location — geography (flag impossible travel)
riskLevel, riskState — Identity Protection signals
conditionalAccessStatus — was a CA policy enforced?

3. Inspect authentication methods (if MFA-related)

GET https://graph.microsoft.com/v1.0/users/{userId}/authentication/methods

If the response contains only a password method and your tenant requires MFA, the user cannot complete MFA and the password reset path will fix it.

4. Reset the password (most common fix)

PATCH https://graph.microsoft.com/v1.0/users/{userId}
Content-Type: application/json

{
  "passwordProfile": {
    "forceChangePasswordNextSignIn": true,
    "password": "TyBLa@aMkVnTG#CS"
  }
}

Returns 204 No Content on success. Communicate the temporary password to the user out-of-band.

5. Re-enable the account (if disabled)

PATCH https://graph.microsoft.com/v1.0/users/{userId}

{ "accountEnabled": true }

6. Revoke active sessions

Forces a fresh sign-in everywhere, clearing any poisoned refresh tokens.

POST https://graph.microsoft.com/v1.0/users/{userId}/revokeSignInSessions

7. Verify

After the user signs in, re-run the sign-in log query from step 2 and confirm a new entry with status.errorCode == 0.

Investigate and remediate via Microsoft Graph PowerShell

The downloadable script below wraps the full workflow. You can also run the steps interactively:

Connect

Connect-MgGraph -Scopes "User.ReadWrite.All","AuditLog.Read.All","UserAuthenticationMethod.ReadWrite.All","Directory.AccessAsUser.All"

Resolve the user

$upn = "ford_russel8@contoso.com"
$user = Get-MgUser -UserId $upn -Property Id,DisplayName,UserPrincipalName,AccountEnabled
$user | Format-List

Pull and triage sign-in logs

$since = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
$filter = "userId eq '$($user.Id)' and createdDateTime ge $since"
$signIns = Get-MgAuditLogSignIn -Filter $filter -Top 50

# Surface failures
$failures = $signIns | Where-Object { $_.Status.ErrorCode -ne 0 }
$failures | Select-Object CreatedDateTime, AppDisplayName, @{n='ErrorCode';e={$_.Status.ErrorCode}}, @{n='Reason';e={$_.Status.FailureReason}}, IpAddress | Format-Table -AutoSize

Inspect MFA methods

Get-MgUserAuthenticationMethod -UserId $user.Id |
    Select-Object Id, @{n='Type';e={$_.AdditionalProperties['@odata.type']}}

Apply remediation

# Generate a 16-char temporary password
Add-Type -AssemblyName System.Web
$tempPwd = [System.Web.Security.Membership]::GeneratePassword(16,3)

# Reset password with forced change
Update-MgUser -UserId $user.Id -PasswordProfile @{
    ForceChangePasswordNextSignIn = $true
    Password = $tempPwd
}

# Revoke all sessions
Revoke-MgUserSignInSession -UserId $user.Id

Write-Host "Temp password (deliver out-of-band): $tempPwd"

Next steps

More Troubleshooting & Diagnostics recipes

Browse the rest of this category in the Dex Cookbook.

Automate this with Dex Pro

Let the autonomous IT engineer run this task under your policies.

Start free

Point Dex at a tenant and try it for 30 days, no credit card.