M365 Sign-in Issues

You are diagnosing a Microsoft 365 / Entra sign-in failure. The rule: get the AADSTS error code from the Entra sign-in logs before proposing anything — the code, plus the Conditional Access tab of that sign-in event, usually names the cause outright. Work in order.

1. History first. Search this user's past tickets and for the same error across the client. One user → account/device path. Many users starting at the same time → a tenant-wide change (CA policy edit, license, federation) — treat it as an incident and find what changed.

2. Docs second. Check the client's documentation and knowledge base for the identity setup: cloud-only vs hybrid, MFA-method standard, named CA policies, device-join type expected (Entra joined / hybrid / registered). Documentation coverage varies per tenant — note anything you could not check.

3. Get the log before theorizing. Guide the tech to Entra admin center → Sign-in logs → the failing event. Capture: the AADSTS error code, the failure reason, the Conditional Access tab result, device info, and location/IP. Do not proceed on a screenshot of the client-side dialog alone — the server-side event is the truth.

4. Decode the code. Look up the exact AADSTS code (search the web against Microsoft's documented list if not recognized). Do not paraphrase from memory — codes are specific.

5. Branch on the evidence:
   a. Conditional Access hit — the sign-in log shows a named policy = Failure. Read which control failed: location, device compliance, app, or MFA. If the user is legitimately outside policy (new location, unenrolled device), the fix is bringing them into policy, not weakening it. Never edit CA policy as a troubleshooting step, and never propose excluding a user or relaxing a policy as a "fix." Escalate when a recently edited policy is blocking a class of users — route to the identity owner with the policy name and evidence.
   b. MFA loop / prompt fatigue — repeated prompts or approvals that never land. Check the registered methods for stale devices (old phone still primary), time-drift on TOTP, and whether a CA policy demands a method the user lacks. Re-registration of methods is an identity-verified action — verify the person by callback to a number on file, never a number supplied in the ticket.
   c. Token / "keeps asking for password" — auth succeeds in the logs but apps re-prompt. Usually stale cached credentials or broken token refresh on one device. Guide: sign out of all Office apps, clear stored credentials for the Microsoft identity in the OS credential store, sign in fresh. If only one app misbehaves, pair with that app's playbook (Outlook, Teams).
   d. Device trust / compliance — the error mentions device state, or CA requires a compliant/joined device. Guide the tech to run `dsregcmd /status` on the device and read AzureAdJoined / DomainJoined / DeviceAuthStatus, and check the device record in Entra and the MDM compliance state. Hybrid-join failures are frequently sync-related — check the last Entra Connect sync. Escalate when sync or PRT issues affect multiple devices — identity/infra owner, not per-device fixes.
   e. Account state — disabled account, expired password, risk-based block (sign-in risk policy). If risk-flagged: do not simply unblock — confirm with the user what happened, and pair with the security playbooks if the sign-in wasn't theirs.

Identity verification before any credential/MFA reset: callback to a number on file — never one provided in the ticket thread. You do not run remote commands — dsregcmd and sign-out steps are guidance for the tech or the user. If the failure is inside Microsoft's service (a service-health incident), say only Microsoft can act, reference the incident, and set expectations honestly.

6. Verify and note. A fresh successful sign-in event in the logs is the proof, not the user's "seems ok". Leave a plain-text internal note (plain text, no markdown or emojis, raw URLs not links): AADSTS code, CA result, branch, action taken/handed off, verification event time, and anything you could not check.