Conditional Access blocks service account unexpectedly

Field Summary

Conditional Access blocks service account unexpectedly is a Conditional Access ticket where the visible symptom can be misleading. When this Microsoft 365 workflow fails, separate account access, web-versus-desktop behavior, token state, licensing, Conditional Access, and service health before changing the client. The fastest path is to identify which layer changed and prove it with logs or a repeatable test.

Common Symptoms

• Web app works while desktop or mobile client fails
• Issue follows one user, device, policy group, or mailbox
• Repeated auth prompts, stale data, sync delay, or access denied appears after a change

Fast Triage

1. Test the web app first.
2. Check affected user/device count and recent password, MFA, license, or policy changes.
3. Capture timestamp, app, error, username, device, and public IP for sign-in issues.
4. Check Microsoft 365 service health if multiple users are affected.

Likely Causes

• Stale token or cached credential
• Conditional Access or MFA mismatch
• License/mailbox/service assignment problem
• Client cache or profile corruption
• Tenant service incident or policy change

Useful Commands

Get-Mailbox user@domain.com
Get-CASMailbox user@domain.com
Get-EXOMailboxStatistics user@domain.com

Tier 1 Fix Path

1. Restart the affected app and confirm the signed-in account.
2. Test the same workflow in a private browser or web app.
3. Clear only the local cache or credential tied to the affected app when device-specific.
4. Avoid profile rebuilds or MFA resets until logs support them.

Tier 2 / Admin Investigation

1. Review Entra sign-in logs, CA result, authentication methods, license state, and service health.
2. Use message trace for mail-flow symptoms and client sync status for sync symptoms.
3. Compare policy/license/mailbox state with a working user in the same group.
4. Check audit/admin history for recent policy or license changes.

Advanced Remediation

Use profile rebuilds, session revocation, mailbox permission changes, or policy reassignment only when the evidence points there.

Verification

• The affected workflow succeeds from the user side.
• The relevant portal/log shows a clean result at the same timestamp.
• The result survives app restart, reconnect, policy refresh, or reboot when relevant.
• No broad bypass or unrelated change was introduced.

Ticket Notes to Capture

• Affected user/device/site/customer
• Exact symptom, error, timestamp, and screenshot or log excerpt
• Scope tested and working comparison used
• Relevant logs/portals checked
• Root cause or most likely layer
• Fix applied and verification result

Escalate When

• Multiple users, sites, or business-critical workflows are affected
• Logs point to vendor, server, security, or policy ownership outside your access
• A disruptive remediation is required
• The same symptom returns after a verified fix

Prevention

Add the final root cause, detection signal, and validation step to the client runbook. If a change caused the issue, add a post-change check that would catch it next time.