EI1 Module Summary

Module summary

EI1 built the telemetry foundation that every subsequent module depends on. Here is what you now know:

The sign-in log is your primary instrument (EI1.1). Every security-relevant field maps to a specific question: WHO (UserPrincipalName), WHAT (AppDisplayName), WHERE (IPAddress, Location), HOW (DeviceDetail, AuthenticationDetails), OUTCOME (ResultType, ConditionalAccessStatus), and RISK (RiskLevelDuringSignIn, RiskEventTypes_V2). ResultType 0 is success. ResultType 53003 is CA blocked. ResultType 50126 is invalid password.

Four sign-in log tables cover four authentication types (EI1.2-EI1.3). SigninLogs for interactive user authentication. AADNonInteractiveUserSignInLogs for background token refresh. AADServicePrincipalSignInLogs for application credentials. AADManagedIdentitySignInLogs for Azure-managed workloads. Complete identity monitoring requires all four tables. Most organizations only monitor the first.

AuthenticationDetails reveals the actual method used (EI1.4). Phishing-resistant methods (FIDO2, passkeys, WHfB, CBA) cryptographically verify the domain and cannot be proxied through AiTM. Phishing-capable methods (password + push, SMS, OATH) can be intercepted. MFA satisfied by "claim in the token" means no active challenge occurred on this sign-in. The authentication strength classification query measures your organization's exposure to AiTM.

ConditionalAccessPolicies records every policy evaluation (EI1.5). "success" means the policy matched and controls were satisfied. "failure" means the policy blocked access. "notApplied" means the policy did not match this sign-in. ConditionalAccessStatus == "notApplied" at the sign-in level means ZERO policies evaluated — the most dangerous gap in your architecture. The gap-finding query is the most important verification query in this course.

Risk signals from Identity Protection provide real-time threat assessment (EI1.6). Sign-in risk measures this specific authentication attempt. User risk measures the account's overall compromise likelihood. Real-time detections (anomalous token, unfamiliar features) are available during authentication for CA enforcement. Offline detections (leaked credentials, password spray) raise user risk after the fact. Risk detections without risk-based CA policies are signals without enforcement.

Device and location context enable trust assessment (EI1.7). Compliant device + expected country + known IP = high trust. Unregistered device + unexpected country + risk signal = investigate. IP geolocation is a useful signal but not forensic evidence of physical location.

KQL is the operational language for identity security (EI1.8-EI1.10). where filters, project selects, extend transforms, summarize aggregates, parse_json and mv-expand handle arrays, let defines variables, join and union combine tables. Cross-table correlation reveals attack patterns that single-table queries miss: risky sign-in → audit log admin action → non-interactive token replay.

Baselines make anomaly detection possible (EI1.11). Five baseline dimensions: geographic, temporal, device, application, and IP. The composite baseline query produces a per-user behavioral profile. Baseline-driven detection catches anomalies that static threshold rules miss.

The query library is your first operational artifact (EI1.12). Daily triage queries (run every morning), weekly monitoring queries (run every Monday), investigation queries (run on demand), and baseline queries (run monthly). These become the foundation for detection rules in EI13 and operational procedures in EI14.

What comes next

EI2: Authentication Methods — Your First Line of Defense. You now know how to read which authentication method each user used (EI1.4) and how to classify methods as phishing-resistant or phishing-capable. EI2 teaches you to configure, deploy, and migrate to stronger methods — starting with Authenticator number matching and progressing to FIDO2 and passkeys. Every configuration change you make in EI2 will be verified using the sign-in log queries you built in this module.

Skills verification checklist

Before moving to EI2, verify you can do each of the following. These are not theoretical — they are the skills every subsequent module assumes you have:

Can you read a sign-in log entry? Open a sign-in event in the Entra admin center and identify: who signed in, from where, with what method, what CA decided, and whether it was flagged as risky. If any field is unclear, revisit EI1.1.

Can you distinguish interactive from non-interactive? Explain which table records which type of event and when you would query each one. If the distinction is unclear, revisit EI1.2.

Can you find service principal sign-ins? Query AADServicePrincipalSignInLogs and identify the active service principals in your tenant. If you have not done this, revisit EI1.3.

Can you determine if MFA was phishing-resistant? Parse the AuthenticationDetails array and classify the method. If you cannot extract and classify the method, revisit EI1.4.

Can you verify a conditional access policy is working? Write a query that checks a specific policy's evaluation results over the last 24 hours. If you cannot parse the ConditionalAccessPolicies array, revisit EI1.5.

Can you triage risk signals? Query for high-risk sign-ins and risky users, and explain what each risk detection type means. If the risk fields are unclear, revisit EI1.6.

Can you assess device and location trust? Combine DeviceDetail and LocationDetails to produce a trust assessment for a sign-in. If you cannot extract these fields, revisit EI1.7.

Can you write a multi-step KQL query? Combine where, extend, summarize, and case() to answer a layered security question. If you cannot write a query from scratch, revisit EI1.8-EI1.9.

Can you correlate across tables? Join SigninLogs with AuditLogs to find what a user did after a suspicious sign-in. If joins are unclear, revisit EI1.10.

Can you build and use a baseline? Run the composite baseline query and the new-country anomaly query. If baselines are unclear, revisit EI1.11.

Is your query library saved? Confirm that the daily, weekly, investigation, and baseline queries are saved in your Sentinel workspace. If not, complete EI1.12.

If you can do all of the above, you are ready for EI2. If any item is unclear, revisit the relevant subsection — the investment in sign-in log fluency pays dividends in every subsequent module.

How EI1 connects forward

The skills and queries built in this module are not self-contained — they are the verification layer for everything you build in the rest of the course:

EI2 uses the authentication method classification query (WEEKLY-01) to verify that your phishing-resistant authentication deployment is progressing. After deploying passkeys for a pilot group, you run the query and confirm that "Phishing-Resistant" sign-ins are increasing.

EI3-EI4 use the CA gap query (DAILY-03) and policy verification queries to confirm that your conditional access architecture is evaluating every sign-in and that the attack-specific policies are producing the expected outcomes.

EI5 uses the risk signal queries (DAILY-01, DAILY-02) as the foundation of the daily risk triage workflow. The queries from EI1.6 become the operational procedure.

EI7 uses the token replay detection pattern (from EI1.2 and EI1.10) to verify that token protection is binding tokens to devices and that stolen tokens are failing validation.

EI9 uses the service principal monitoring queries (WEEKLY-03) to verify application governance and detect anomalous service principal behavior.

EI13 converts the detection patterns from the query library into automated Sentinel analytics rules — the daily and weekly queries become real-time detection capabilities.

EI14 formalizes the daily, weekly, and monthly query cadence into a documented operational procedure with assigned responsibilities and escalation criteria.

Every module in this course starts with "how do you verify it works?" The answer is always a sign-in log query from this module.