Microsoft Entra ID Sign-In Telemetry Reference
Microsoft Entra ID (formerly Azure AD) writes all sign-in activity to a family of Log Analytics tables that Sentinel ingests. Every record in every table carries OperationName = "Sign-in activity" regardless of the action involved. Because there is no per-operation discriminator, the tables cannot be modeled as discrete events the way Windows Security events are. Detections instead filter on field values within each table to distinguish success from failure, legacy from modern auth, and risky from compliant sessions.
Sign-In Log Tables#
| Table | Covers | Elastic dataset |
|---|---|---|
| SigninLogs | Interactive user sign-ins: browser-based flows, native clients, and ROPC (Resource Owner Password Credential) flows where a human enters credentials. The primary detection surface for credential attacks and impossible-travel scenarios. | azure.signinlogs |
| AADNonInteractiveUserSignInLogs | Non-interactive user sign-ins: token refreshes, mail clients using cached tokens, and client-credential flows on behalf of a user. High volume; typically filtered to failures or anomalous patterns before alerting. | azure.signinlogs (same dataset, azure.signinlogs.properties.is_interactive distinguishes) |
| AADServicePrincipalSignInLogs | Application and service principal sign-ins using client secrets or certificates. Detections focus on new or unexpected service principals acquiring tokens, and credential stuffing against application registrations. | azure.signinlogs |
| AADManagedIdentitySignInLogs | Sign-ins by Azure managed identities (system-assigned and user-assigned). Normally benign baseline traffic; anomalies (unexpected resource access, new managed identities) are the main detection signal. | azure.signinlogs |
CombinedSignInLogs is a Sentinel workspace function that unions all four tables into a single queryable surface. Rules targeting CombinedSignInLogs attribute to all four underlying tables.
Why There Are No Per-Operation Event Pages#
Each record in the sign-in tables carries OperationName = "Sign-in activity" without exception. The Entra audit pipeline does not emit separate operation names for "password auth", "MFA challenge", "token refresh", and so on. The result type, authentication method, and policy state are instead distributed across numeric and enumerated fields within each record.
Detections in the Sigma and Sentinel corpora that target sign-in logs pivot on these fields rather than on an operation name. The Azure AD Coverage matrix lists contributing rules under the "SigninLogs" section of that page.
Key Detection Fields#
| Field | Type | Detection Use |
|---|---|---|
| ResultType | int (stored as string) | Sign-in outcome code. 0 is success; all other values are failures or interruptions. See the error code table below. |
| ResultDescription | string | Human-readable reason phrase paired with ResultType. Useful for display; filter on ResultType for reliable matching. |
| ClientAppUsed | string | Authentication client reported by the service. Legacy authentication clients report values such as Other clients, IMAP, POP3, SMTP, Mapi, AutoDiscover, and Exchange ActiveSync. Modern clients report Browser or Mobile Apps and Desktop Clients. Rules that hunt legacy auth filter on these string values because legacy protocols bypass MFA. |
| AuthenticationRequirement | string | multiFactorAuthentication or singleFactorAuthentication. Indicates what the policy required for the session, not whether MFA succeeded. Combine with ResultType to distinguish MFA-required failures from single-factor successes. |
| ConditionalAccessStatus | string | Whether a Conditional Access policy applied: success, failure, notApplied, or notEnabled. Failures correspond to ResultType 53003. |
| RiskState | string | Identity Protection risk assessment at sign-in time: atRisk, confirmedSafe, remediated, dismissed, confirmedCompromised, or none. Populated only when Identity Protection is licensed (Entra ID P2). |
| RiskLevelDuringSignIn | string | Identity Protection risk level at sign-in: none, low, medium, high, or hidden. hidden means the user or tenant is not scoped for Identity Protection. Rules may alert when this is high and ResultType is 0 (a risky sign-in that succeeded). |
| RiskDetail | string | Reason the risk level was assigned, e.g. userPassedMFADrivenByRiskBasedPolicy, adminConfirmedSigninCompromised. Useful for triage context. |
| IPAddress | string | Source IP of the sign-in request. Primary field for impossible-travel rules and TI enrichment. Anonymous proxy and Tor exit node detection pivots here. |
| Location | dynamic (JSON) | Nested object containing city, state, countryOrRegion, and geoCoordinates. In KQL: Location.countryOrRegion. Sentinel rules for impossible-travel expand geoCoordinates for distance calculations. |
| AppDisplayName | string | The application being signed into, as registered in the tenant. Examples: Microsoft Teams, Azure Portal, Office 365 Exchange Online. Rules hunt unexpected apps acquiring tokens for sensitive resources. |
| ResourceDisplayName | string | The OAuth resource (API) being accessed. Distinct from AppDisplayName when a first-party client accesses a resource. For example, a Teams client (AppDisplayName) accessing Office 365 Exchange Online (ResourceDisplayName). |
| UserPrincipalName | string | UPN of the signing-in user. Join key for correlating sign-in failures with Azure AD object changes (password resets, account enables/disables in AuditLogs). |
| DeviceDetail | dynamic (JSON) | Device compliance, join type, and browser. DeviceDetail.isCompliant and DeviceDetail.isManaged are common Conditional Access gate fields. Unmanaged devices signing in to sensitive apps are a detection signal. |
| AuthenticationDetails | dynamic (JSON array) | Per-factor breakdown of the authentication steps. Each element carries authenticationMethod, authenticationStepResultDetail, and succeeded. Use this to determine which factor failed when ResultType indicates an MFA failure. |
| MfaDetail | dynamic (JSON) | Method used for MFA: authMethod (e.g. Phone App Notification, OATH software token) and authDetail. Populated only for interactive sign-ins that invoked MFA. |
| HomeTenantId | string (GUID) | Tenant that owns the account. Differs from the resource tenant in B2B (cross-tenant) scenarios. Rules for external-user access filter on a mismatch between HomeTenantId and the workspace tenant. |
| CrossTenantAccessType | string | How the cross-tenant access was brokered: b2bCollaboration, b2bDirectConnect, microsoftSupport, serviceProvider, or none. Relevant for tenant-to-tenant lateral movement scenarios. |
ResultType Error Codes#
The most detection-relevant codes are listed here. The full list is maintained in the Microsoft Entra authentication and authorization error codes reference.
| Code | Meaning | Detection Context |
|---|---|---|
| 0 | Success | Sign-in completed. Combine with RiskLevelDuringSignIn = "high" or ConditionalAccessStatus = "failure" override to find risky successful sign-ins. |
| 50126 | Invalid credentials: bad username or password | Primary brute-force and password spray signal. Aggregate counts by UserPrincipalName, IPAddress, or AppDisplayName over short windows. Spray patterns show many distinct accounts failing from a single IP; stuffing shows repeated failures against one account. |
| 50053 | Account locked out (Smart Lockout triggered) | Entra Smart Lockout engaged after repeated failures. A burst of 50126 records followed by 50053 on the same account confirms a lockout event. Smart Lockout thresholds are configurable and may vary between familiar and unfamiliar locations. |
| 50057 | Account disabled | Sign-in attempted against a disabled account. In an attack sequence, an adversary may attempt credentials for an account that was disabled after initial compromise; or this may indicate a misconfigured service account. |
| 50074 | MFA required, strong auth challenge sent but not completed | User prompted for MFA but did not complete the challenge (timeout, declined). A high rate of 50074 for a single user may indicate MFA fatigue (adversary repeatedly triggering push notifications hoping the user approves). Correlate with subsequent 0 (success) records from the same session. |
| 50076 | MFA required but not satisfied for the resource | Resource policy requires MFA and the client did not present a valid MFA claim. Appears in legacy-auth flows that bypass the MFA prompt. Useful for identifying MFA bypass attempts alongside ClientAppUsed values for legacy protocols. |
| 500121 | Authentication failed during strong authentication request | MFA challenge presented but the response was incorrect or expired. Distinct from 50074 (no response) in that the user or tool attempted but failed the second factor. |
| 53003 | Blocked by Conditional Access | A Conditional Access policy returned a block decision. ConditionalAccessStatus is failure. The specific policy and reason are available in ConditionalAccessPolicies (dynamic array). Repeated 53003 from the same user may indicate policy evasion attempts (switching apps, devices, or locations). |
| 53004 | Account locked by Conditional Access | Tenant-level block applied via Conditional Access. Distinct from Smart Lockout (50053). |
| 70044 | Session expired or session token not yet valid | Token replay or clock-skew issue. Occasional occurrences are benign; sustained patterns against service principals may indicate replay attacks. |
| 700016 | Application not found in the directory | Client ID not registered in the tenant. Common indicator of reconnaissance (probing for registered apps) or misconfigured automation. |
| 90095 | Admin consent required | Application requested permissions beyond what the user can consent to. Appears during OAuth consent phishing when a victim is redirected to an app requesting broad permissions. |
Legacy Authentication Detection#
Legacy authentication protocols (IMAP, POP3, SMTP, Exchange ActiveSync, MAPI over HTTP, AutoDiscover) do not support modern MFA flows. An adversary who obtains a password can authenticate using these protocols even when MFA is enforced on browser-based sign-ins.
Filter for legacy-auth sign-ins using ClientAppUsed:
SigninLogs
| where ClientAppUsed in ("IMAP", "POP3", "SMTP", "Mapi", "AutoDiscover",
"Exchange ActiveSync", "Other clients")
| where ResultType == "0"
Microsoft's recommended path to eliminate legacy auth is to block it via Conditional Access using the "Other clients" platform condition. Rules that detect legacy-auth successes after a tenant's block policy date are high-priority findings.
Relationship to the Microsoft Catalog#
Entra ID sign-in telemetry is non-Windows cloud telemetry. It does not produce Windows events and is not cataloged as event pages on this site. The /microsoft/ hub covers Windows events from the Microsoft-Windows-Security-Auditing and related providers, which record on-premises Kerberos and NTLM authentication separately.
For detection rules targeting sign-in logs, see:
- Azure AD Coverage matrix: Rules from Sigma, Elastic, Splunk, Sentinel, and Chronicle grouped by audit category; the SigninLogs section lists rules that filter on sign-in tables directly.
- /search: Full-text search across non-Windows rule corpus; query
provider:SigninLogsorprovider:AADNonInteractiveUserSignInLogsto find specific coverage.
References#
- Microsoft: SigninLogs table schema
- Microsoft: AADNonInteractiveUserSignInLogs table schema
- Microsoft: AADServicePrincipalSignInLogs table schema
- Microsoft: AADManagedIdentitySignInLogs table schema
- Microsoft: Entra authentication and authorization error codes
- Microsoft: Sign-in log activity details
- Microsoft: Block legacy authentication with Conditional Access