In this section

The Lab Environment

3-4 hours · Module 0 · Free
What you already know

You understand the identity threat landscape, the attacks this course defends against, and the metrics you'll use to measure progress. This section sets up the lab environment where you'll deploy every control hands-on. Every module from EI1 onward includes exercises in this environment — Conditional Access policies, Identity Protection, PIM, detection rules, and KQL queries all run here.

Scenario

You need a safe, isolated environment where you can create Conditional Access policies, configure Identity Protection, test authentication methods, register applications, and run KQL queries — without affecting a production tenant. A misconfigured CA policy in production can lock out every user in the organization. The developer tenant exists so you can make mistakes safely and learn from them.

What you need and what it costs

The lab requires three components, all available at no cost.

An M365 E5 developer tenant from the Microsoft 365 Developer Program provides a fully licensed environment with 25 user licenses. E5 includes Entra ID P2, which unlocks every identity security feature in this course: Conditional Access, Identity Protection, PIM, access reviews, entitlement management, and advanced audit logging. The tenant is completely isolated from any production environment — you cannot accidentally affect a real organization.

An Azure subscription connected to the developer tenant provides Microsoft Sentinel, Log Analytics, and Azure resources. The free tier includes 5 GB per day of log ingestion — more than sufficient for lab work. Sentinel's free trial provides 31 days of the full experience at no cost. After the trial, the 5 GB/day free ingestion tier covers a lab environment with no additional charge.

A FIDO2 security key is recommended but not required. Physical keys (YubiKey 5 NFC, approximately $25-50) allow you to complete the phishing-resistant authentication exercises in EI2 and test token protection in EI7. Without a physical key, you can use passkey functionality in Microsoft Authenticator for most exercises once passkey profiles are configured in your developer tenant.

Total cost: $0 for M365 and Azure. $25-50 for a physical security key if you want the full hands-on experience.

LAB ARCHITECTURE M365 E5 DEV TENANT Entra ID P2 Conditional Access + PIM Identity Protection Exchange Online SharePoint / OneDrive 25 licenses, $0/mo AZURE + SENTINEL Log Analytics workspace Microsoft Sentinel SigninLogs + AuditLogs Analytics rules engine Defender XDR connector 5 GB/day free tier YOUR WORKSTATION Browser (Edge/Chrome) FIDO2 key (optional) Authenticator app PowerShell 7+ Microsoft.Graph module Any OS, any location

Figure 0.10 — Lab architecture. The M365 E5 developer tenant provides the identity platform, Azure + Sentinel provides the detection and monitoring layer, and your workstation is the operator console. No VPN or on-premises infrastructure required.

Step 1: Create the M365 developer tenant

Navigate to developer.microsoft.com/en-us/microsoft-365/dev-program and sign up. Use an existing Microsoft account or create one.

If you can't get a developer tenant: Microsoft restricted the Developer Program since early 2024 — it now requires a Visual Studio Professional/Enterprise subscription or Partner Program membership. If you see "You don't currently qualify," try Visual Studio Dev Essentials (free) at visualstudio.microsoft.com first. If that doesn't work, purchase a single M365 E5 license ($57/user/month) for the full P2 stack, or start with an M365 Business Premium trial ($22/user/month) for P1 and Conditional Access without P2 features like PIM and Identity Protection.

Once enrolled, click "Set up E5 subscription." Choose Instant sandbox — this creates a pre-configured tenant with 16 sample users, mail, events, and SharePoint sites. The sample data provides a realistic environment for sign-in log exercises in EI1.

Record your admin credentials (admin@[yourdomain].onmicrosoft.com). This Global Administrator account is used for all configuration exercises. The tenant renews automatically every 90 days with continued development activity — running the exercises in this course counts.

The E5 license is critical. It includes Entra ID P2, which provides Conditional Access, Identity Protection with risk-based policies, PIM, access reviews, entitlement management, and 30-day sign-in log retention. Without P2, you can't create risk-based CA policies, can't configure PIM, and can't access Identity Protection — three core capabilities this course teaches. The developer program gives you the same tier organizations pay $57/user/month for, at zero cost.

Step 2: Create sample users for identity scenarios

The instant sandbox includes 16 users, but the identity security exercises need specific accounts mapped to organizational roles. Create these in the Entra admin center (Identity → Users → All users → New user):

Security team: alex.security@[yourdomain].onmicrosoft.com (assign Security Reader + Security Administrator) and jordan.secops@[yourdomain].onmicrosoft.com (Security Reader only). These accounts practice role separation — administrative configuration versus read-only monitoring.

Break-glass accounts: admin.break1 and admin.break2 — permanent Global Administrator assignment. Do not configure MFA on these accounts. Break-glass accounts must remain accessible when all other authentication fails. You will build detection rules for these accounts in EI13 — the monitoring gap you saw in the Midnight Blizzard breach (Section 0.7) starts with exactly this kind of unmonitored privileged account.

Standard users: casey.finance (finance department, BEC scenarios) and morgan.external (external contractor, B2B identity exercises in EI11). These users become the identities you protect throughout the course. When EI4 asks you to create a CA policy requiring MFA for finance users, casey.finance tests it. When EI6 asks you to configure PIM, these accounts demonstrate the eligible-versus-active distinction.

Security groups: Create "Identity Security Lab Users" (all standard users), "Phishing-Resistant MFA Users" (empty — populated as you deploy phishing-resistant auth in EI2), and "Privileged Users" (admin + security team). These groups serve as Conditional Access policy targets throughout the course.

What we see in 90% of environments

Practicing identity security configurations in a production tenant. A misconfigured Conditional Access policy can block all users from signing in. An incorrectly configured authentication methods policy can prevent MFA completion across the organization. An Identity Protection policy set too aggressively forces organization-wide password resets. The developer tenant exists so you make these mistakes safely. Practice every configuration here first. Deploy to production only after verification using the report-only methodology taught in EI8.

Step 3: Connect an Azure subscription and deploy Sentinel

Create an Azure subscription at azure.microsoft.com/free using the same account that owns the developer tenant. This links the subscription to the developer tenant's Entra ID directory — the same tenant's identity data flows into the same subscription's analytics layer. The free tier includes $200 in credits for 30 days and permanent 5 GB/day Log Analytics ingestion.

In the Azure portal, create resource group "rg-identity-security-lab" and Log Analytics workspace "law-identity-lab" within it. Deploy Sentinel: search for "Microsoft Sentinel," click "Create," select law-identity-lab. The free trial activates automatically.

The connection between the developer tenant and Sentinel is what makes this course hands-on training rather than documentation reading. When you create a CA policy in EI4, you verify it by querying the sign-in log in Sentinel. When you configure Identity Protection in EI5, you tune risk thresholds based on events flowing into Sentinel. When you build detection rules in EI13, you deploy them as Sentinel analytics rules. Without Sentinel, you're reading about identity security. With Sentinel, you're engineering it.

Enable the Microsoft Entra ID data connector (Sentinel → Configuration → Data connectors). Enable all log types: Sign-in logs, Non-interactive user sign-in logs, Service principal sign-in logs, Managed Identity sign-in logs, Provisioning logs, Audit logs, Risky users, User risk events, Risky service principals, and Service principal risk events. Also enable Microsoft Defender XDR — this brings cross-domain incidents into Sentinel for EI16.

Step 4: Configure diagnostic settings for Entra ID logs

This step routes Entra ID telemetry to your Sentinel workspace, enabling every KQL query in the course. Without this routing, the sign-in and audit data exists only in the Entra admin center's 30-day log viewer — useful for quick checks but without the analytics capability that Sentinel provides.

Entra Admin Center

IdentityMonitoring & healthDiagnostic settings
Add a setting named "EntraID-to-Sentinel." Select all log categories — SigninLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, ProvisioningLogs, AuditLogs, RiskyUsers, UserRiskEvents, RiskyServicePrincipals, ServicePrincipalRiskEvents. Under destination, select "Send to Log Analytics workspace" and choose law-identity-lab. After saving, the status should show "Sending."

The log types you're enabling each serve a specific purpose in the course. SigninLogs captures interactive user authentication — the primary data source for EI1 through EI5. NonInteractiveUserSignInLogs captures background token refresh and SSO activity — essential for understanding real session behavior. ServicePrincipalSignInLogs captures application authentication — the data source the consent phishing case study in Section 0.7 showed most organizations don't monitor. AuditLogs captures every configuration change — role assignments, CA policy modifications, application consent grants. RiskyUsers and UserRiskEvents capture Identity Protection detections — the risk signals that drive risk-based Conditional Access in EI5.

Entra ID begins streaming logs after saving. Initial data takes 15-30 minutes to appear. Verify with this query in Sentinel:

KQL
// Verify log routing — confirm sign-in data is flowing to Sentinel
SigninLogs
| take 10
// Results = log routing is working
// Empty = wait 30 minutes and retry, initial population takes time

Step 5: Generate initial sign-in activity

The tenant needs sign-in data to make EI1 exercises meaningful. Sign in to portal.office.com with the admin account — open Outlook, Teams, and SharePoint. Sign out and repeat with casey.finance (Outlook, OneDrive) and alex.security (Entra admin center). Each sign-in generates SigninLogs entries you'll query from EI1 onward.

If you have a mobile device, install Microsoft Authenticator and register it for the admin account. This creates authentication method registration events in the audit log and enables MFA exercises in EI2. If you can sign in from a different network (mobile data, VPN, or a different physical location), do so — this generates "unusual location" data useful for baseline exercises in EI1 and risk detection in EI5.

Install PowerShell 7 and the Microsoft Graph module — you'll use these throughout the course for programmatic identity operations:

PowerShell
# Install the Microsoft Graph PowerShell module
Install-Module Microsoft.Graph -Scope CurrentUser
# Connect to your developer tenant
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","Directory.Read.All"
# Verify connection — should show your developer tenant
Get-MgContext | Select-Object TenantId, Account
# List your users to confirm sample data is populated
Get-MgUser -All | Select-Object DisplayName, UserPrincipalName | Format-Table

The Graph PowerShell connection generates additional sign-in events in the ServicePrincipalSignInLogs table and confirms that your environment is ready for the programmatic exercises in later modules. You'll use Graph API calls extensively in EI9 (application governance), EI10 (workload identity), and EI12 (access reviews).

Step 6: Verify the lab environment

Confirm each item before starting EI1:

  1. Entra admin center — access entra.microsoft.com, confirm Conditional Access is visible (Identity → Protect & secure → Conditional Access)
  2. Sign-in logs — at least one event with Authentication Details and Conditional Access tabs
  3. Sample users — sandbox users plus the six accounts from Step 2
  4. Azure subscription — law-identity-lab workspace accessible in portal.azure.com
  5. Sentinel — workspace active in the Sentinel service
  6. Diagnostic settings — "EntraID-to-Sentinel" shows "Sending"
  7. KQLSigninLogs | take 10 returns results in Sentinel Logs
  8. Security groups — all three groups exist with correct membership
  9. Graph PowerShellGet-MgContext returns your developer tenant ID

All nine items passing means your lab is ready for EI1. If the KQL query returns empty results, wait 30 minutes — initial log population can take up to an hour depending on the diagnostic settings propagation. Check the diagnostic settings status first: if it shows "Sending," the data is in transit. If it shows an error, verify the Log Analytics workspace is in the same tenant as the Entra ID directory.

Identity Security Principle

The lab environment is not a shortcut — it is the production deployment methodology. Every control in this course is tested in the developer tenant first, verified with a KQL query, and only then deployed to production using report-only mode. This build-test-verify workflow is the discipline that separates safe deployments from outage-causing mistakes.

Next

That completes Module 0. You understand the identity threat landscape, the attacks, the kill chain, the defensive framework, and you have a lab environment ready. EI1 begins with sign-in logs — the telemetry foundation that every detection, investigation, and posture measurement in this course depends on.

Unlock the Full Course See Full Course Agenda