Lesson 21 — Microsoft Entra Sign-in Diagnostics
A failed sign-in is not always a bad password.
The user may have authenticated successfully and then been blocked by Conditional Access, device compliance, authentication strength, sign-in risk, token issuance or an application-specific requirement. Microsoft Entra Sign-in Diagnostics helps administrators move beyond the user-facing error and examine the evidence recorded for the authentication request.
This lesson explains how to locate the correct sign-in event, run the diagnostic, interpret every major tab and follow a repeatable investigation workflow from the user and application through authentication, policy, device, risk and token results.
What you will learn
This lesson provides a practical workflow for diagnosing Microsoft Entra sign-in failures and unexpected access decisions.
Learning objectives
After completing this lesson, you should be able to investigate Microsoft Entra sign-in problems methodically.
- Locate the correct sign-in event.
- Choose the correct sign-in log category.
- Run Microsoft Entra Sign-in Diagnostics.
- Interpret basic information, location, device and authentication details.
- Determine how Conditional Access affected the request.
- Use failure reasons, error codes, request IDs and correlation IDs.
- Distinguish authentication success from application access success.
- Document a defensible troubleshooting conclusion.
The problem this solves
Users often report only that they “cannot sign in.” That description does not reveal where the authentication flow failed.
The real cause may be credentials, MFA, device state, risk, Conditional Access, token issuance, consent, licensing or the application itself.
What is Microsoft Entra Sign-in Diagnostics?
Sign-in Diagnostics is a guided troubleshooting capability in Microsoft Entra ID. It analyses a selected sign-in event and highlights likely reasons for the outcome, relevant policy decisions and recommended investigation areas.
The diagnostic accelerates troubleshooting, but it does not replace reading the underlying sign-in record.
Where to find the sign-in logs
In the Microsoft Entra admin center, browse to:
You can also open a user and review sign-ins associated with that identity.
Start with precise evidence
Collect the affected username, application, approximate time, timezone, device, network location and the exact message shown to the user.
A screenshot containing the error code, request ID, correlation ID and timestamp can dramatically reduce investigation time.
Choose the correct sign-in category
| Category | What it represents | Typical investigation |
|---|---|---|
| Interactive user sign-ins | A user actively provides an authentication factor. | Browser, desktop application or prompt-driven sign-in. |
| Non-interactive user sign-ins | A client silently obtains or refreshes tokens for a user. | Background token refresh, mobile or desktop client activity. |
| Service principal sign-ins | An application identity authenticates without a user. | Client secret, certificate or workload application failure. |
| Managed identity sign-ins | An Azure resource authenticates using its managed identity. | Azure resource access to Key Vault, Storage or another service. |
Searching only interactive sign-ins can miss the event that actually failed.
Filter the event list
- Search by user principal name.
- Filter by application.
- Set the correct date and time range.
- Filter status to Failure when appropriate.
- Add Conditional Access, client application or resource filters.
- Check nearby successful and interrupted events for context.
Match the correct event
Several log entries may represent one user-visible attempt.
Confirm the timestamp, application, resource, client, IP address, device and correlation information before drawing conclusions.
The investigation sequence
Basic information
The basic information tab establishes the identity, application, resource, sign-in time, status, IP address, client and identifiers associated with the request.
Record the sign-in identifier, request ID and correlation ID when escalating a case.
Status and failure reason
The status tells you whether the recorded sign-in succeeded, failed or was interrupted. The failure reason and additional details explain the recorded outcome more precisely.
Do not assume every failure means the password was wrong.
Authentication Details
The Authentication Details tab shows the authentication steps recorded for the request.
| Field or result | Question it helps answer |
|---|---|
| Authentication requirement | Was single-factor or multifactor authentication required? |
| Authentication method | Which passwordless, password or MFA method was used? |
| Step result | Did the authentication step succeed, fail or get skipped? |
| Requirement satisfied by claim | Was MFA already satisfied by an earlier token or session? |
| Authentication strength | Did the method satisfy the strength required by policy? |
| Authentication context | Did an application request a specific protected context? |
Why did MFA not prompt?
MFA may have been satisfied earlier and represented by a claim in the token. A remembered session, compliant authentication method or federated claim can also affect the experience.
Review the authentication details rather than relying on whether the user remembers seeing a prompt.
Why did MFA succeed but access fail?
MFA is only one possible grant requirement.
The sign-in may still fail because of device compliance, authentication strength, terms of use, sign-in risk, session controls or a block policy.
Conditional Access evaluation
The Conditional Access tab shows which policies were evaluated and the result for each policy.
| Result | Meaning | Investigation action |
|---|---|---|
| Success | The policy applied and its controls were satisfied. | Confirm which grant and session controls were met. |
| Failure | The policy applied and blocked access or a required control was not satisfied. | Open the policy result and identify the failed condition or grant control. |
| Not applied | The request did not meet the policy assignments or conditions. | Check user, application, platform, location, client and filter scope. |
| Report-only | The policy was evaluated without enforcement. | Use the result to predict what enforcement would have done. |
Policy inclusion and exclusion
A policy may be skipped because the user, workload, application or condition falls outside its assignments.
Check group membership, exclusions, target resources, device platform, client application, location and filters.
What If vs actual evidence
The Conditional Access What If tool models policy evaluation using selected inputs.
The sign-in log records what Microsoft Entra evaluated for the real request. Use the actual event as the primary evidence.
Device information
Device-related controls depend on the device evidence available during the sign-in.
- Device ID
- Microsoft Entra joined, registered or hybrid joined state
- Compliance state
- Operating system and browser
- Managed-device signals
- Device filter evaluation
A blank device ID does not automatically mean the device object is missing. The authentication flow or client may not have presented device information.
Location and network
Review the IP address, geolocation, autonomous system and named-location evaluation.
VPNs, proxies, secure web gateways and mobile carriers can make the observed IP differ from the user's physical location.
Risk information
Check sign-in risk, user risk and risk detections when Identity Protection contributes to the decision.
A risk-based policy may require MFA, secure password change or block access.
Error codes, request IDs and correlation IDs
| Evidence | Purpose |
|---|---|
| AADSTS or numeric error code | Identifies the authentication or token-service condition recorded by Microsoft Entra. |
| Failure reason | Provides a readable description of the immediate outcome. |
| Additional details | May contain a recommended corrective action. |
| Request ID | Identifies the individual request for support and correlation. |
| Correlation ID | Links related operations across the authentication flow. |
| Timestamp | Anchors the event in time and prevents correlation with the wrong attempt. |
Always record identifiers together with the UTC timestamp and tenant information when escalating to Microsoft or an application owner.
Success does not always mean access
A successful Microsoft Entra authentication means the identity request completed successfully at that stage.
The application can still reject the token, require additional authorisation, fail during its own session creation or encounter a service-side error.
Interrupted sign-ins
An interrupted sign-in may require additional user action, such as MFA registration, consent, password change, terms of use or another challenge.
Read the status and additional details to determine what must happen next.
Agent Foskett investigation: “The password is correct, but Teams will not open”
Common troubleshooting scenarios
| User report | Evidence to inspect first |
|---|---|
| “MFA never appeared.” | Authentication requirement, method details and whether MFA was satisfied by a claim. |
| “MFA worked, but I was still blocked.” | Conditional Access grant controls, device state, authentication strength and risk. |
| “The device is compliant in Intune.” | Device ID and compliance claim presented in this specific sign-in. |
| “The policy should not apply to me.” | Policy assignments, nested group membership, application target and exclusions. |
| “The log says success, but the app failed.” | Resource, token audience, application logs, consent, roles and service health. |
| “There is no failed interactive sign-in.” | Non-interactive, service principal or managed identity logs. |
Operational investigation checklist
- Capture the exact time and timezone.
- Confirm the user, application and resource.
- Check all relevant sign-in categories.
- Read status, error code and additional details.
- Review every authentication step.
- Open the Conditional Access policy results.
- Validate device and network evidence.
- Check risk and session controls.
- Compare nearby successful attempts.
- Preserve IDs before escalating.
When to escalate
Escalate when the sign-in record indicates a service-side condition, the application rejects a valid token, the diagnostic cannot explain the outcome or the behaviour cannot be reproduced safely.
Provide timestamps, tenant ID, user, application, resource, error code, request ID, correlation ID and sanitised screenshots.
Common mistakes
| Mistake | Impact | Better practice |
|---|---|---|
| Resetting the password immediately | The real policy or device problem remains unresolved. | Read the sign-in event before changing credentials. |
| Looking only at interactive sign-ins | Background token or workload failures are missed. | Check the sign-in category that matches the authentication flow. |
| Reading only the final status | The stage that failed remains unknown. | Review authentication, Conditional Access, device, risk and token evidence. |
| Assuming no MFA prompt means no MFA | Existing MFA claims and sessions are misunderstood. | Use Authentication Details as the evidence. |
| Assuming compliance in Intune proves the sign-in was compliant | The actual request may lack a device claim. | Inspect the device information on that sign-in. |
| Ignoring timestamps and identifiers | The wrong event is analysed or escalation lacks evidence. | Capture UTC time, request ID and correlation ID. |
Key takeaways
- Sign-in Diagnostics accelerates troubleshooting, but the underlying sign-in event remains the primary evidence.
- A failed sign-in does not automatically mean the password was wrong.
- Choose the sign-in category that matches the authentication flow.
- Authentication Details explains which methods and requirements were satisfied.
- Conditional Access results show which policies applied, failed, succeeded or were skipped.
- Device compliance must be evidenced in the specific sign-in request.
- Error codes, request IDs, correlation IDs and timestamps are essential for escalation.
- A successful authentication can still be followed by an application-side access failure.
- The most reliable workflow follows the user, application, authentication, policy, device, location, risk and token evidence in order.
Related Agent Foskett resources
Continue learning
Microsoft Entra Sign-in Diagnostics and Authentication Troubleshooting
Microsoft Entra Sign-in Diagnostics helps administrators troubleshoot failed, interrupted and unexpected authentication outcomes by analysing sign-in records, authentication steps, Conditional Access policies, device information, location, risk and token details.
Microsoft Entra Academy Lesson 21 — Sign-in Diagnostics
This Agent Foskett lesson explains how to locate the correct Microsoft Entra sign-in event, choose the appropriate sign-in category, interpret Authentication Details and Conditional Access results, investigate device and risk evidence, use AADSTS error codes and preserve request and correlation identifiers for escalation.
