Collect the user-facing identifiers
Ask for the expanded error details, not only the headline. Preserve the full code and identifiers exactly as displayed. Record whether the failure occurred in a browser, desktop client, mobile client, command-line tool, or background process.
- AADSTS or numeric error code
- Correlation ID and request ID
- UTC timestamp and local timezone
- User or service identity and tenant
- Application the user opened and resource it attempted to access
- Device, network, and client context
Find the matching event
In Microsoft Entra sign-in logs, start with the correlation ID when available. Otherwise narrow by user, status, application, and a tight time range. Check the interactive and non-interactive views when the client may have refreshed a token or called a dependent resource in the background.
The application and resource are different fields. A Teams sign-in can request Exchange, SharePoint, or another dependent resource. Investigating only the application name can send the case toward the wrong policy.
Read the tabs as separate evidence
| Area | Question it answers | Common mistake |
|---|---|---|
| Basic info | Which identity, app, resource, client and location were evaluated? | Assuming the display name proves the tenant or object |
| Authentication Details | Which authentication steps and requirements were attempted? | Treating an incomplete MFA interaction as a password failure |
| Device Info | Which device claims were presented? | Equating “managed” with the exact compliance or join requirement |
| Conditional Access | Which policies were evaluated and what was each result? | Assuming a global CA status identifies the failing policy |
| Troubleshooting | What event-specific interpretation is available? | Changing policy before confirming scope and grant controls |
Classify the failure layer
- Identity: wrong tenant, account state, credential, federation, or risk state.
- Application: redirect URI, service principal, assignment, consent, or client configuration.
- Authentication: MFA method, authentication strength, interruption, or token acquisition.
- Authorization: the identity authenticated but lacks access to the requested resource.
- Conditional Access: a matching policy required controls that were not satisfied or explicitly blocked access.
- Device: the event lacks or fails the join, compliance, platform, or client claim expected by policy.
The AADSTS code suggests a layer, but the matching event decides the case. For example, AADSTS53003 points to Conditional Access, yet the policy tab is still needed to identify the policy, target resource, and unsatisfied grant.
Change one control with a rollback path
Do not disable multiple policies or reset every authentication method to make the symptom disappear. Use a safe test identity, report-only analysis, the Conditional Access What If tool, or a narrowly scoped exclusion according to your organization’s emergency-access process. Record the original policy state and the exact retest event.
A successful retest is not enough by itself. Confirm the new sign-in event used the intended identity, resource, device, and authentication path, and that the required policy reported the expected result.