9.4 Investigating & Resolving Authentication Issues
Key Takeaways
- Entra sign-in logs categorize sign-ins as interactive, non-interactive, service principal, and managed identity, each surfacing different failure data
- The sign-in diagnostic in the Entra admin center walks an administrator through a specific failed sign-in and maps the error code to a root cause and remediation
- AADSTS error codes describe failure reasons conceptually — for example, 50053 (account locked), 53003 (Conditional Access block), 50097 (device auth required) — and should be interpreted via the diagnostic, not memorized
- Common MFA/SSPR failures trace to registration gaps, a method not enabled in the Authentication Methods Policy, or a Conditional Access policy requiring MFA the user cannot satisfy
- Hybrid password failures often trace to password hash sync not running or password writeback not enabled
Quick Answer: Start every authentication investigation in the Entra sign-in logs (Entra admin center → Monitoring → Sign-in logs) or with the Sign-in diagnostic (Diagnose and solve problems → Sign-in diagnostics). The logs tell you what happened, the diagnostic maps the error code to a root cause and a fix. Most failures fall into four buckets: Conditional Access blocks, MFA/registration gaps, account lockout/smart lockout, and hybrid sync/writeback issues.
Entra Sign-In Logs
The sign-in logs are the primary investigative tool. They are split into four tabs:
| Log Type | What It Captures | Typical Use |
|---|---|---|
| Interactive user sign-ins | A user signed in interactively (browser prompt, MFA challenge) | Most user-reported "I can't sign in" cases |
| Non-interactive user sign-ins | Sign-ins without a user prompt (token reuse, client credentials on behalf of user) | Silent auth failures in desktop/mobile clients |
| Service principal sign-ins | Apps and service principals signing in (client credentials flow) | App auth failures, broken integrations |
| Managed identity sign-ins | Azure resource managed identity token requests | Azure resource auth failures |
Each entry shows the user, app, IP, location, client app, status (Success/Failure), the conditional access policies applied, and the error code on failure. Filter by user, app, or status to narrow quickly.
The Sign-In Diagnostic
For a single failed sign-in, the Sign-in diagnostic (Diagnose and solve problems → Sign-in diagnostics, or click Diagnostic on a log row) walks through the failure step by step: it identifies the error code, the conditional access policies that applied, the authentication method challenges that fired, and the device/risk signals. The diagnostic ends with a root cause and a recommended remediation — this is the fastest path from "user X failed" to "here is the fix."
Common AADSTS Error Codes (Conceptual)
Entra sign-in failures return an AADSTS error code. You do not need to memorize the full catalog — the diagnostic interprets them — but recognizing the common patterns speeds triage:
- Account lockout / smart lockout (e.g., 50053) — too many bad attempts; the attacker is locked, the genuine user may still sign in. Confirm in the logs that the failed attempts come from a different IP than the user's normal location.
- Conditional Access block (e.g., 53003) — a CA policy blocked the sign-in. The diagnostic shows which policy fired and which grant/session controls were not satisfied (MFA, compliant device, approved app, named location).
- External challenge / MFA not satisfied (e.g., 50158) — an additional challenge (MFA, terms of use, claim provider) was required and not completed. Often a registration gap or a method not enabled.
- Device authentication required (e.g., 50097) — the sign-in needed a device claim (Entra joined, compliant, or hybrid) and none was provided. Check the device state and Intune compliance.
- Invalid credentials (e.g., 50126) — wrong password. If widespread, suspect password hash sync issues in a hybrid tenant.
Interpret codes through the diagnostic, not in isolation — the same code can have different root causes depending on the conditional access and risk context.
Diagnosing MFA and SSPR Failures
MFA and SSPR failures usually trace to one of three causes:
- Registration gap — the user has not registered a method (or the required number of methods). Check Protection → Authentication methods → Registration and the user's
User authentication methodsblade. Fix by driving the user toaka.ms/mfasetup. - Method not enabled in policy — the user registered, say, SMS, but SMS is disabled in the Authentication Methods Policy for MFA. Check the policy and either enable the method or migrate the user to an allowed method.
- Conditional Access requires MFA the user cannot satisfy — a CA policy requires MFA but the user's registered methods do not satisfy it (e.g., policy requires an Authenticator push but the user only has SMS). Revisit the policy or the user's registration.
For SSPR specifically, also verify: SSPR is enabled for the user's group, the user registered enough methods, and (for hybrid) password writeback is enabled in Entra Connect.
Diagnosing Hybrid Sync Password Issues
For hybrid users, password failures often trace to sync:
- Password hash sync not running — open Entra Connect Sync Service Manager → Operations; confirm the last PHS delta sync succeeded. If PHS is enabled but never ran, the cloud credential does not match on-prem.
- Password writeback not enabled — in Entra Connect, the optional feature Password writeback must be selected. Without it, SSPR resets only the cloud password and the user's on-prem sign-in still fails.
- Recent on-prem password change not synced — run a full PHS sync or wait for the next cycle (default 30 minutes).
- Account locked on-prem — on-prem AD account lockout is independent of Entra smart lockout; check the on-prem AD account state.
Troubleshooting Table
| Symptom | Likely Cause | Resolution |
|---|---|---|
| User blocked at sign-in, error 53003 | Conditional Access policy blocked the sign-in | Review the fired policy in the diagnostic; satisfy the required grant control (MFA, compliant device, approved app) or adjust the policy |
| User cannot complete MFA, error 50158 | MFA challenge not satisfied — registration gap or method disabled | Check Registration tab; ensure method enabled in Authentication Methods Policy; drive user to aka.ms/mfasetup |
| Hybrid user reset password via SSPR but on-prem sign-in still fails | Password writeback not enabled or Connect sync not running | Enable Password writeback in Entra Connect; confirm sync service is running; force a PHS delta sync |
| Widespread "invalid password" after on-prem password change | Password hash sync not run | Run a full or delta PHS sync in Connect Service Manager |
| Account repeatedly locked, user says they are not trying to sign in | Attacker spraying passwords; smart lockout engaging the attacker | Review sign-in logs for unfamiliar IPs; block or quarantine the source; require MFA via Conditional Access; consider temporary account lock policy |
| Service principal sign-in failure in logs | App secret/certificate expired or wrong endpoint | Rotate the app credential in Entra → App registrations → Certificates & secrets; update the app's configuration |
Investigation Workflow
A repeatable workflow for any authentication issue:
- Identify the user, app, and time from the support ticket.
- Open Monitoring → Sign-in logs, filter by user and time, locate the failure.
- Click Diagnose on the failure row to run the sign-in diagnostic.
- Read the root cause and remediation the diagnostic returns.
- Cross-check against the conditional access policies, the Authentication Methods Policy registration tab, and (for hybrid) Entra Connect sync status.
- Apply the fix and ask the user to retry; confirm the next sign-in log shows Success.
This workflow resolves the vast majority of authentication issues without escalating to Microsoft support.
A user reports they cannot sign in and the sign-in log shows error 53003. What is the most likely cause and where do you look first to confirm it?
A hybrid user resets their password through SSPR successfully, but their on-premises AD sign-in still fails with the old password. What is the most likely cause?