In this section
Anatomy of a Sign-In Log Entry
Section 0.2 covered how authentication works — the OAuth 2.0 flow from redirect through token issuance. Section 0.4 showed the attack patterns this course defends against, and Section 0.10 set up your lab. You learn to read the output of that authentication flow: the sign-in log entry. Every field maps to a security question. By the end, you'll read a sign-in record the way a pilot reads instruments — fluently, without hesitation.
Scenario
A Defender XDR alert fires: "Unfamiliar sign-in properties." You open the sign-in log entry and see dozens of fields — UserPrincipalName, AppDisplayName, IPAddress, ConditionalAccessStatus, RiskLevelDuringSignIn, AuthenticationDetails, DeviceDetail. You need to assess this alert in under two minutes. That requires knowing which fields answer which security questions — not memorizing a schema reference, but understanding what each value means for the decision you need to make right now.
The sign-in log as your primary instrument
Every identity security operation in this course — every policy verification, every anomaly detection, every attack indicator — depends on the sign-in log. It records every authentication attempt against your Entra ID tenant: successful and failed, interactive and non-interactive, user and service principal. A typical M365 tenant with 1,000 users generates tens of thousands of sign-in events per day. The volume is not the challenge. The challenge is knowing which fields matter for security and what the values mean in context.
There are four separate sign-in log tables in Entra ID, each recording a different authentication type. SigninLogs captures interactive user sign-ins. AADNonInteractiveUserSignInLogs captures background token refreshes and SSO. AADServicePrincipalSignInLogs captures application authentication. AADManagedIdentitySignInLogs captures Azure resource authentication. This section covers the fields common to the interactive sign-in log — the table you'll query most frequently. Sections 1.2 and 1.3 cover the differences in the other tables.
Entra Admin Center
Identity → Monitoring & health → Sign-in logs
The sign-in logs viewer shows four tabs: Interactive user sign-ins, Non-interactive user sign-ins, Service principal sign-ins, and Managed identity sign-ins. Click any row to open the full record. The Activity Details pane shows Basic info, Location, Device info, Authentication Details, and Conditional Access tabs. This is the same data you'll query in KQL — the portal view helps you learn the fields before you query them at scale.
Reading a complete sign-in record
Before examining individual fields, look at what a complete sign-in record contains. This is a successful interactive sign-in to Microsoft Teams from a managed Windows device:
Every field in that record answers a security question. The next sections group them by the question they answer.
Figure 1.1 — Every sign-in log entry answers seven security questions. The fields group into identity (WHO), target (WHAT), network origin (WHERE), authentication method (HOW), result (OUTCOME), threat assessment (RISK), and endpoint (DEVICE). The Conditional Access array spans all groups — it records which policies evaluated and what each decided.
WHO — the identity fields
UserPrincipalName is the canonical identifier — the email-format string that uniquely identifies the account (p.sharma@contoso.com). Start every investigation here. UserId is the immutable GUID that persists even if the UPN changes (which happens during name changes, domain migrations, or when a user moves between tenants in a merger). For long-running investigations that span weeks, filter on UserId rather than UPN — a renamed account still has the same GUID.
UserDisplayName is the human-readable label — useful for readability in query results but not unique and not reliable for filtering. Two users can share the same DisplayName. Always filter on UPN or UserId in detection rules and investigation queries.
The UserType field distinguishes between Member (internal users provisioned in your directory) and Guest (external users invited via B2B collaboration). Guest users authenticate through their home tenant and then receive a cross-tenant token for your resources. Guest sign-ins appear in your sign-in logs but the authentication event itself happened in another tenant. This matters for Conditional Access — policies targeting guests need different conditions than policies targeting members, because the device compliance state and risk signals come from the guest's home tenant, not yours.
WHAT — the application and resource fields
AppDisplayName identifies the client application the user launched — "Microsoft Teams," "Office 365 Exchange Online," "Azure Portal," or a third-party application name. AppId is the GUID that reliably identifies the application. This distinction matters operationally: AppDisplayName can be set to anything in a custom app registration, including names designed to disguise malicious activity like "Microsoft Security Update" or "Azure Compliance Scanner." An attacker who registers a malicious application picks the name. AppId is assigned by Entra ID and cannot be spoofed. Every detection rule in EI13 filters on AppId, never AppDisplayName.
ResourceDisplayName identifies the backend resource the application requested access to — the API or service the token will authorize. A sign-in to Microsoft Teams (AppDisplayName) actually requests a token for Microsoft Graph (ResourceDisplayName). A sign-in to the Azure Portal requests a token for Azure Resource Manager. Understanding this client-app-to-resource mapping matters for Conditional Access policy scoping. You can build a CA policy that targets "Microsoft Teams" as the client app, but the actual resource the token authorizes is Graph. If you want to block Graph access entirely (not just through Teams), you target the resource, not the client.
The ClientAppUsed field identifies the authentication protocol — "Browser," "Mobile Apps and Desktop clients," "Exchange ActiveSync," "Other clients." Legacy authentication protocols (IMAP, POP3, SMTP AUTH) appear as "Exchange ActiveSync" or "Other clients." These protocols don't support MFA and are the primary target of password spray attacks. A Conditional Access policy that blocks legacy authentication filters on this field. If you see ClientAppUsed: "Other clients" with ResultType: 0 in your logs, legacy authentication succeeded in your tenant — and that is the gap password spray exploits.
WHERE — location and network origin
IPAddress is the source IP of the authentication request. For a user behind a corporate proxy, every employee behind that proxy shares the same public IP — the field shows the proxy's address, not the user's workstation. VPN exit nodes mask the true origin. Residential proxy networks — the infrastructure Midnight Blizzard used to evade geographic detection — make attacker traffic appear to originate from legitimate consumer ISPs in the same country as the target organization. IPAddress is a useful contextual signal, but treating it as a definitive location indicator leads to both false positives (legitimate travelers) and false negatives (proxy-masked attackers).
Location provides city, state, and countryOrRegion derived from IP geolocation databases. Country-level accuracy exceeds 99%. City-level accuracy is approximately 70-80% and should not be treated as precise — mobile carriers and satellite internet providers map to city-level locations that may not reflect the user's actual position. Location is most useful for two patterns: sign-ins from countries where your organization has no operations (high-confidence anomaly), and impossible travel (sign-ins from two distant locations within a timeframe shorter than possible travel time). Identity Protection uses location signals for both of these risk detections.
The NetworkLocationDetails field records whether the IP matched any named location defined in your Conditional Access configuration — trusted corporate IP ranges, VPN exit points, or country-based locations. An empty array means the sign-in came from an IP that doesn't match any named location. This field is how you measure the percentage of sign-ins originating from outside your trusted network — a key input for the device compliance requirement decision in EI4.
OUTCOME — what Entra ID decided
ResultType is the numeric error code that tells you what happened. Zero means success. Every other value indicates a specific failure, and the specific value matters more than the category. The codes you'll encounter most frequently in security work: 50126 (invalid username or password — the baseline for password spray detection), 50074 (strong authentication required — MFA was triggered as a step-up challenge), 50076 (MFA required but user hasn't completed enrollment — often indicates a CA policy gap where MFA is required but registration isn't enforced), 53003 (blocked by Conditional Access — the policy worked as designed), 500121 (MFA failed — user denied the push, timed out, or entered the wrong code), and 530032 (blocked by Security Defaults — the built-in baseline if no CA policies exist).
These codes tell you not just that a sign-in failed but why — and the "why" determines your response. A burst of 50126 errors across many accounts from a single IP range is password spray. A burst of 500121 errors for a single user is MFA fatigue. A 53003 with ConditionalAccessStatus: failure is a CA policy doing its job. The error code is the first field an analyst reads after UserPrincipalName.
Status contains both the errorCode and additionalDetails that provide human-readable context: "MFA completed in Azure AD," "Invalid username or password," "Blocked by Conditional Access." The additionalDetails string is useful for quick triage in the portal but is not structured data — don't parse it programmatically. Use ResultType for KQL filters.
ConditionalAccessStatus reveals whether Conditional Access allowed or blocked the sign-in. Three values matter: success (policies evaluated and all requirements were met — access granted), failure (a CA policy blocked the sign-in), notApplied (no CA policies matched the sign-in conditions). The third value is the dangerous one. A sign-in with ConditionalAccessStatus: notApplied means no Conditional Access policy evaluated on that authentication event. The user accessed your tenant with no policy governance at all. Section 1.5 covers how to find these gaps systematically and close them.
The SOC monitors for failed sign-ins (ResultType != 0) and ignores successful ones. But AiTM token replay produces a successful sign-in (ResultType 0) with ConditionalAccessStatus "success." Password spray succeeds with ResultType 0 against accounts using legacy authentication. The most dangerous sign-ins are the successful ones you didn't expect. Monitoring only failures misses the attacks that matter most.
HOW — authentication method
AuthenticationRequirement reveals whether the sign-in required single-factor or multi-factor authentication. A value of singleFactorAuthentication on an account that should require MFA indicates either a Conditional Access gap or a token replay (where the token carries MFA claims from the original authentication). This field is the first indicator you check for AiTM attacks — the attacker's replayed token shows singleFactorAuthentication because the token presentation itself doesn't trigger a new MFA challenge.
AuthenticationDetails is the array that reveals exactly how the user proved their identity — which methods were used, which succeeded, and in what order. This array is deep enough to warrant its own section (1.4), but the key insight here is the authenticationMethod field. Values include "Password," "Microsoft Authenticator," "FIDO2 security key," "Passkey (device-bound)," "Windows Hello for Business," "Text message," "Phone call," and critically, "Previously satisfied." When you see "Previously satisfied," no live authentication occurred — a cached token was presented. This is normal for SSO flows but is also the exact signature of token replay attacks.
RISK — Identity Protection signals
RiskLevelDuringSignIn is Identity Protection's real-time assessment of this specific sign-in event: none, low, medium, or high. RiskLevelAggregated is the user's overall risk level accumulated over time. A sign-in with RiskLevelDuringSignIn: medium and RiskLevelAggregated: high means this sign-in triggered a medium-risk detection and the user already had elevated risk from previous activity. Section 1.6 covers risk signals in depth.
DEVICE — the endpoint context
DeviceDetail is the nested object that contains everything Entra ID knows about the device that initiated the sign-in. The security-critical fields are: deviceId (the GUID if the device is Entra-registered — empty if unregistered), operatingSystem and browser (what the user agent reported — useful for profiling but can be spoofed), isCompliant (whether the device meets your Intune compliance policy — the field that CA device compliance requirements evaluate), isManaged (whether the device is enrolled in Intune), and trustType which indicates the registration state: AzureAd for Entra-joined, ServerAd for hybrid-joined (domain-joined with Entra Connect sync), Workplace for Entra-registered only, and empty for completely unregistered devices.
A sign-in from a device with isCompliant: false, isManaged: false, and empty trustType is an unmanaged, unknown device accessing your corporate data. In the AiTM case study from Section 0.7, the attacker's device had exactly this profile — an unmanaged Linux machine with a Chrome browser that no Conditional Access device compliance policy blocked because the organization hadn't deployed a compliance requirement. Section 1.7 covers building device profiles from these fields and using them to design the device compliance policies in EI4.
CORRELATION — linking multi-step sign-ins
A single interactive sign-in can produce multiple records in Log Analytics. When a user enters their password, Entra ID generates one record. When MFA challenges, another record appears. When MFA completes, a third. All share the same CorrelationId. The Entra admin center merges these into one entry and shows the final outcome. Log Analytics shows every intermediate step.
This means you need to be careful with KQL queries. A query counting sign-in events without grouping by CorrelationId will overcount. The pattern for accurate counting is to take the final record per CorrelationId:
There are also three different timestamps to understand. TimeGenerated is when Log Analytics ingested the record — this can lag up to an hour behind the actual event. CreatedDateTime is when the sign-in event started. authenticationStepDateTime inside the AuthenticationDetails array timestamps each individual authentication step. For accurate timeline reconstruction, use CreatedDateTime. For KQL query performance, filter on TimeGenerated first (it's the indexed column) and then refine with CreatedDateTime if precision matters.
Identity Security Principle
The sign-in log is not a monitoring tool you check when something goes wrong. It is the operational evidence layer that proves whether your controls are working. Every Conditional Access policy, every authentication method deployment, every risk-based decision — all of it produces measurable evidence in this log. If you can't verify a control's effectiveness in the sign-in log, the control is not operationally deployed.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.