Reference

Sign-in log reading reference

Based on the article: Reading Microsoft Entra sign-in logs like an engineer · 6 min read

Every Entra ID problem ends up in the sign-in logs, and most wrong conclusions start there too: a "failure" that was just a prompt, a Conditional Access "Success" that enforced nothing, an IP that geolocates to the wrong country. In this post I'll explain the four log types, the fields that matter, how to trace one failed sign-in to its root cause, how to query the logs in Log Analytics, and the most common misreads.

How it works

You find the logs under Entra ID › Monitoring & health › Sign-in logs; Reports Reader is the least privileged role that can read them, and any user can see their own at https://mysignins.microsoft.com. Entries are system-generated and can't be edited or deleted. There are four tabs:

Log type	What it records	Typical examples
Interactive user sign-ins	The user provided an authentication factor: a password, an MFA response, a biometric, a QR code.	Browser sign-in to Microsoft 365, MFA challenge, Windows Hello for Business unlock requesting a token.
Non-interactive user sign-ins	A client or OS component obtained a token on the user's behalf without prompting.	Refresh token redeemed for an access token, authorization code redemption, SSO on an Entra joined PC, a second Office app on a phone using the same session.
Service principal sign-ins	An application authenticated with its own certificate or secret.	Automation scripts, SaaS integrations.
Managed identity sign-ins	An Azure resource authenticated with a secret Azure manages.	A Function App calling Key Vault.

Non-interactive entries are aggregated: when the application, user, IP address, status and resource ID match, the portal shows one row with a count in the # sign-ins column over a 1, 6 or 24 hour window. Expand the row to see each timestamp. For confidential clients the IP shown comes from the original token issuance, not the refresh request.

The fields that matter

Microsoft frames every sign-in as who (user), how (client application) and what (resource). Around those sit the fields you'll actually use:

Field	How to read it
Status, Sign-in error code, Failure reason, Additional details	Status is Success, Failure or Interrupted. The code is the `AADSTS` number; the additional details often contain the fix.
Correlation ID	Groups requests from the same sign-in session. Supplied by the client, so accuracy isn't guaranteed, but it's the key for joining interactive and non-interactive rows.
Request ID	Identifies one token request. The same Request ID can appear on an Interrupted row and then on the final Success or Failure row.
Client app	Browser, Mobile apps and desktop clients, or a legacy protocol such as Exchange ActiveSync, IMAP, POP, SMTP or MAPI.
Authentication requirement	`singleFactorAuthentication` or `multiFactorAuthentication`. If primary authentication failed before MFA was evaluated, it reads single-factor even though MFA would have been required.
Authentication details tab	The sequence of methods, whether each succeeded, and policies applied. "Satisfied by claim in the token" means no prompt was needed. Can be incomplete for a short while after the event.
Conditional Access tab	Every policy with its result: Success (evaluated for this user and app, even if nothing was enforced), Failure (controls not satisfied or block), Not applied, Disabled; plus a Report-only tab.
Device info tab	Device ID, browser, OS, and whether the device is compliant, managed or Microsoft Entra hybrid joined. Empty when the client sent no device state.
Token issuer type / Incoming token type	`AzureAD`, `ADFederationServices`, `AzureADBackupAuth`, `ADFederationServicesMFAAdapter` or `NPSExtension`; the incoming token type shows, for example, a primary refresh token or a SAML assertion.

Step-by-step: trace one failure end to end

Isolate it. Filter by the user, set Status to Failure and narrow the date. If the user says "it just keeps prompting", look at Interrupted entries too.
Read Basic info. Note the error code, failure reason and additional details, then copy the Request ID and Correlation ID. Look the code up at https://login.microsoftonline.com/error?code=<code> if the reason isn't clear.
Check Conditional Access. A policy with Failure explains a 53003 or device error. A Report-only entry explains nothing yet, but shows what will break when you enable it.
Check Authentication details. Did the password step succeed and MFA fail, or did it never reach MFA? Which method was attempted?
Check Device info and Location. No device ID on a hybrid joined laptop points at a PRT or registration problem; an unexpected country is often a VPN egress, so treat location as best effort.
Follow the Correlation ID into the non-interactive tab. A failed interactive sign-in is often preceded by a silent token refresh failure that explains the prompt.
Use the Sign-in Diagnostic from the Basic info tab, and keep the Request ID, Correlation ID, timestamp and user ready if you open a support case.

Export, retention and KQL

The admin center keeps sign-ins for 7 days on Entra ID Free and 30 days on P1 and P2, and upgrading isn't retroactive. For longer, go to Entra ID › Monitoring & health › Diagnostic settings (Security Administrator) and send the categories you need to a Log Analytics workspace, a storage account, an event hub or a partner solution. SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs and ManagedIdentitySignInLogs land in the SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs tables; add AuditLogs, RiskyUsers and UserRiskEvents while you're there. Query from Monitoring & health › Log Analytics or from the workspace.

In SigninLogs, ResultType is the error code as a string and 0 means success; Status, DeviceDetail and ConditionalAccessPolicies are dynamic columns you expand with dot notation. CreatedDateTime is when Entra ID processed the sign-in, TimeGenerated when the record was ingested.

kusto

// Failures for one user in the last 24 hours, grouped by code and app
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "sara@contoso.com" and ResultType != "0"
| summarize Count = count(), Reason = take_any(ResultDescription) by ResultType, AppDisplayName
| order by Count desc

// Everything that shares one session, interactive and non-interactive
union SigninLogs, AADNonInteractiveUserSignInLogs
| where CorrelationId == "aaaa0000-bb11-2222-33cc-444444dddddd"
| project TimeGenerated, Type, AppDisplayName, ResourceDisplayName, ResultType,
          ConditionalAccessStatus, AuthenticationRequirement, IPAddress
| order by TimeGenerated asc

// Portal-style view: the final outcome per correlation ID
SigninLogs
| where TimeGenerated > ago(7d)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            FinalStatus = arg_max(TimeGenerated, ResultType, ConditionalAccessStatus), Count = count()
  by CorrelationId, UserPrincipalName

The last query matters because the portal merges every request in a session into one line, while Log Analytics stores each request: a user who fails an MFA prompt and then passes it produces one successful row in the portal and several rows in the workspace with the same Correlation ID. Programmatic access through Microsoft Graph (Get-MgAuditLogSignIn, AuditLog.Read.All) requires a P1 or P2 licence.

Tips & gotchas: common misreads