Lab Setup: Sample Data and Validation

Connecting data sources

A Sentinel workspace without data connectors has a working analytics engine, a functioning query editor, and detection rules that can be created. It also has nothing to detect, nothing to query, and nothing to investigate. The approach here is deliberate: connect the minimum data sources needed for the course, generate realistic activity across those sources, and verify the data appears in the workspace. Module 8 covers data connector strategy at production depth. For initial setup, you need the Defender XDR connector for security telemetry and the Entra ID connector for sign-in and audit logs.

Figure 0.6.1 — Data flow from M365 tenant through connectors to Sentinel workspace tables. Key tables (left), enrichment tables (center), and detection tables (right) serve different investigation purposes.

The Defender XDR connector

The Defender XDR connector streams incidents, alerts, and advanced hunting events from the unified Defender portal into your Sentinel workspace. This single connector covers Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. All product-specific telemetry arrives through one integration point.

Understanding the connector architecture matters for investigation. When Defender XDR correlates alerts from multiple products into a single incident (a phishing email from MDO, a risky sign-in from Entra ID Protection, and a suspicious process from MDE), the correlation happens inside Defender XDR before the incident reaches Sentinel. The connector delivers the pre-correlated incident, giving you the full attack story in your workspace. Without the Defender XDR connector, you would get the raw events through individual product connectors but not the correlation. Correlation turns five separate alerts into one investigation.

The Entra ID connector

The Entra ID connector populates the two most queried tables in identity-based investigations: SigninLogs and AuditLogs. SigninLogs records every authentication attempt with the IP address, location, client application, Conditional Access evaluation result, and risk detection state. AuditLogs records directory changes: user creation, group membership changes, role assignments, application consent grants, and authentication method registration. These two tables are the foundation of identity investigation in Modules 12 through 16.

On the same Data connectors page, search for "Microsoft Entra ID" and open the connector. Enable both SigninLogs and AuditLogs. Both tables have minimal ingestion volume in a lab: typically 10-50 MB per day depending on how actively you use the tenant.

Generating realistic telemetry

The simplest way to populate your workspace is to use your tenant. Sign in as your admin account and two or three test users over the next several days. Open Outlook and send emails between users. Include emails with links and attachments, since these populate the EmailUrlInfo and EmailAttachmentInfo tables that Module 12 uses. Access SharePoint documents and create files. Send Teams messages. Each action generates audit log events and sign-in records that flow through the connectors into Sentinel within minutes.

For email telemetry, send at least ten to fifteen emails between your test users over several days. Include a few with external links to create entries in EmailUrlInfo that you will query when investigating phishing URLs. Include attachments of different types (Word documents, PDFs, images) to populate EmailAttachmentInfo. Send at least one email from an external account to a tenant user to create an external sender pattern that the course's phishing detection rules target.

To simulate the suspicious activity patterns you will investigate in later modules, sign in as a test user from a different browser profile, a mobile device, or a VPN connection. This creates sign-in records from different IP addresses and potentially different locations: the exact pattern that Module 12's AiTM investigation teaches you to detect. Create an inbox forwarding rule on a test mailbox by navigating to Outlook on the web, then Settings, then Mail, then Forwarding. Forward to another test user's address. This generates the audit event that Module 12's investigation queries target.

For admin activity telemetry, perform a few directory changes: create a test user, add a user to a group, modify a conditional access policy in report-only mode, register an authentication method. Each action populates AuditLogs with the operation type, target resource, and actor identity. The AuditLogs table is where you find evidence of persistence techniques in later modules. When an attacker creates a new user, adds themselves to a privileged group, or registers a new authentication method on a compromised account, those actions appear in AuditLogs. Generating your own admin activity now gives you a baseline of what legitimate directory changes look like, so you can recognize illegitimate ones during investigations.

Specifically, create at least one new test user through the Entra admin center (this generates a "Add user" operation in AuditLogs). Add that user to the "Security Reader" group (generates "Add member to group"). Navigate to Authentication methods for a test user and register a phone number (generates "User registered security info"). Each of these operations maps directly to attacker persistence techniques you will investigate: unauthorized user creation in Module 14, privilege escalation through group membership in Module 15, and MFA manipulation in Module 12.

For instant sandbox users, the 24 pre-created test users come with sample mail and SharePoint documents, but you still need to generate sign-in activity by logging in as those users. Signing in as three to four different test users each day for the first week gives you a solid baseline of normal activity. The telemetry builds over days, not hours. Plan to generate activity across three to five days before expecting rich query results. The more diverse your baseline activity, the more useful your investigation comparisons will be in later modules.

Validating your data pipeline

Data takes five to fifteen minutes to appear in Sentinel after connector activation and user activity. Open the Logs blade in Sentinel and run your first validation query:

SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, AppDisplayName,
         IPAddress, Location, ResultType, ConditionalAccessStatus
| sort by TimeGenerated desc
| take 10

If you get results, the Entra ID connector is working. If zero results, either the connector is not enabled, no sign-in activity has occurred since enabling it, or data has not propagated yet. Wait 15 minutes after your first sign-in and retry.

Here is what a single record from that query looks like. This is the raw evidence you will read hundreds of times throughout the course:

TimeGenerated:            2026-05-21T14:32:18Z
UserPrincipalName:        adelev@yourlab.onmicrosoft.com
AppDisplayName:           Microsoft Office 365 Portal
IPAddress:                82.132.xx.xx
Location:                 GB
ClientAppUsed:            Browser
ResultType:               0
ResultDescription:        Success
ConditionalAccessStatus:  success
AuthenticationRequirement: singleFactorAuthentication
RiskLevelDuringSignIn:    none
RiskState:                none
DeviceDetail:             {"browser": "Chrome 125.0", "operatingSystem": "Windows 10"}
MfaDetail:                {"authMethod": "PhoneAppNotification"}

That record tells a complete story. Adele Vance signed in successfully from a UK IP address using Chrome on Windows 10, authenticating to the Office 365 portal. Conditional Access evaluated and allowed the sign-in. MFA was satisfied via phone app notification. The risk level was none.

Every field is an investigation data point, and understanding them now saves time in every module that follows. ResultType 0 means success. ResultType 50126 means invalid username or password. ResultType 50074 means the user did not pass MFA. ResultType 53003 means Conditional Access blocked the sign-in. When you see a cluster of 50126 events for the same user from the same IP address, you are looking at a password spray. When you see a 50074 followed by a successful sign-in from the same IP five minutes later, someone either completed MFA or bypassed it.

ConditionalAccessStatus has three values that matter: "success" means a policy applied and the user met its requirements. "failure" means a policy applied and blocked the sign-in. "notApplied" means no policy evaluated for this sign-in, which in a properly configured environment should concern you. In Module 12's AiTM investigation, the attacker's sign-ins show "notApplied" because the stolen session cookie bypassed the authentication flow entirely, meaning Conditional Access never had a chance to evaluate the request.

RiskLevelDuringSignIn is Entra ID Protection's real-time assessment. Values range from "none" through "low," "medium," and "high." A "high" risk sign-in means Microsoft's machine learning detected a pattern consistent with known attack techniques: anomalous travel, anonymous proxy usage, or credential exposure in a known breach. DeviceDetail shows the browser and operating system. A sudden change from Chrome on Windows to Safari on macOS for the same user within minutes is worth investigating. MfaDetail shows which MFA method was used. PhoneAppNotification means the user approved a push notification. If the method changes from PhoneAppNotification to PhoneAppOTP (a one-time code), that could indicate an attacker with access to the authenticator app seed.

In Module 12, when you investigate an AiTM credential phishing campaign, the same SigninLogs query returns records that look very different: unfamiliar IP addresses, unusual locations, SessionId values indicating token replay, and ConditionalAccessStatus values of "notApplied" because the attacker bypassed MFA by stealing the session cookie. You will recognize the anomalies because you know what normal looks like.

After confirming SigninLogs, check the remaining tables. Run AuditLogs | take 10 to verify directory change events. Run EmailEvents | take 10 to verify email telemetry from the Defender XDR connector. If EmailEvents returns zero results, send a test email between two tenant users and wait 15 minutes.

For a thorough check, run this query that counts records per table across the last 24 hours:

union SigninLogs, AuditLogs, EmailEvents, SecurityAlert
| where TimeGenerated > ago(24h)
| summarize Records = count() by Type
| sort by Records desc

This tells you which connectors are actively delivering data. If SigninLogs and AuditLogs show counts but EmailEvents shows zero, the Defender XDR connector may need reconfiguration. Verify that the EmailEvents table is checked on the connector page. SecurityAlert may show zero in a new tenant with minimal activity, which is normal. That table populates when Defender products detect suspicious behavior. DeviceProcessEvents will not appear yet. That table requires a device onboarded to Defender for Endpoint, which Module 2 covers. Having SigninLogs, AuditLogs, and EmailEvents populated is sufficient to begin Module 1.

Content Hub solutions

Four Content Hub solutions provide pre-built analytics rules and workbooks that enhance your lab. Install from Content Hub: Microsoft Entra ID for sign-in analytics and identity workbooks, Microsoft Defender XDR for incident correlation rules, Microsoft 365 for Office 365 threat detection rules, and UEBA Essentials for behavioral analytics that enriches entity profiles with risk scores.

Each solution installs with one click. The analytics rules install in a disabled state. Leave them disabled. These are templates designed for production environments with thousands of users. Enabling them immediately in a lab with three test users fills your incident queue with false positive alerts before you understand what the rules do or how to tune them. Module 10 teaches you to evaluate, tune, and deploy analytics rules correctly. That is the right time to enable them, not now.

What your lab looks like now

With connectors enabled and activity generating telemetry, your lab environment is complete. You have an M365 E5 tenant producing security events, a Sentinel workspace ingesting those events, and the foundation for every investigation, detection, and hunting exercise in the course. The architecture is identical to a production security environment. The data volume is smaller. The techniques you learn are transferable without modification.