The Lab Environment

Introduction

Every later module assumes a tenant you can break. This section builds one, and names the three things a developer tenant cannot show you. You will finish with an environment that produces real sign-in telemetry, and a written note of where its limits are.

The lab requires three components. Two are free; the tenant depends on what you are eligible for.

An M365 E5 tenant provides a fully licensed environment with 25 user licenses. The Microsoft 365 Developer Program supplies one to members who qualify, which now requires a standard Visual Studio Professional or Enterprise subscription, ISV Success membership, an eligible Microsoft AI Cloud Partner Program tier, or Premier or Unified Support. Otherwise use a 30-day E5 trial, which needs a card and converts to paid unless canceled. E5 includes Entra ID P2, which unlocks every identity security feature in this course: Conditional Access, Identity Protection, PIM, access reviews and entitlement management. Log retention is thirty days on P1 and P2 alike, so retention is not what P2 buys you. 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. A new workspace ingests free for 31 days at 10 GB per day, which is more than sufficient for lab work. The standing allowance afterwards is 5 GB per month across the whole billing account, so cap the workspace or tear it down before the trial expires. Sentinel's free trial provides 31 days of the full experience at no cost. After the trial, the standing allowance is 5 GB per month across the billing account, which covers a quiet 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.

What it costs is small. What it cannot show you is the part worth knowing first.

A lab shows you real Conditional Access evaluation against real sign-ins, the sign-in and audit schema from ei01 with your own activity in it, and what a policy does in report-only before it does anything in production.

What it cannot show you is the part to write down, because a lab that is trusted for the wrong things teaches confidence rather than skill.

Scale. Per ARC402 13.1, a population of eight users cannot exhibit the behavior a population of eight hundred does, so rarity and novelty mean nothing here. Legacy. A fresh tenant has no accumulated exemptions, no service accounts nobody owns and no application grants from four years ago, which is most of what makes a real estate hard. Consequence. Locking yourself out of a lab costs a rebuild, and per ei03 that is exactly the pressure that makes break-glass design feel optional.

Build it anyway. A control you have watched evaluate once is a different thing from a control you have read about.

The third limit is the one to compensate for deliberately. A lab removes the cost of being wrong, and that cost is what makes break-glass exclusions and report-only feel necessary, so a policy practiced here without them will be written the same way against a tenant where it matters.

The workspace is the only line with a real number attached, and it is the one worth watching rather than the one worth avoiding. Per ARC402 14.2 the habit of knowing what a connector costs is the one most estates never form, and a lab is the cheapest possible place to form it.

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.

A developer tenant gives you E5-equivalent licensing, renewable while you keep using it, so Conditional Access, Identity Protection and PIM are all available to you.

The first thing to change is that Security Defaults is on. Per 0.6 that is the "traditional" maturity level, and more practically it conflicts with Conditional Access: you cannot use both, so every policy you write later silently does nothing until this is turned off.

Create the break-glass account before you turn it off, per ei03. Turning off Security Defaults with no policy and no excluded account is the one sequence in this lab that can lock you out of your own tenant.

Order matters even here, and it is the same report-only-first instinct 0.8 argues for.

That ordering is worth getting right in a lab precisely because it costs nothing here. Security Defaults and Conditional Access are mutually exclusive, so a tenant left with defaults on evaluates none of the policies you write, and the failure is silence rather than an error.

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 ARC406: 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 ARC406). 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.

Four checks, and only one of them tells you whether the data is arriving.

  Standard user      what every policy is measured against
  Administrator      role held against role activated   ei06
  Break-glass        excluded from everything           ei03
  Service account    no MFA, no interactive logon       ei10
  Guest              from a tenant you do not control   ei11

The shapes matter more than the count. A policy that treats every identity the same is a policy you cannot test, and five shapes give you five different answers to the same policy.

Two of them earn their place for reasons worth stating. Create the break-glass account now, because a lab is where you find out whether your exclusion actually excludes, and production is the expensive place to learn it. And the service account exists so you can watch every control in this course miss it.

Five shapes is enough. Adding a sixth of an existing shape teaches nothing.

The service account is the one worth creating even though nothing in ei00 uses it. It is the identity every control in this course fails to reach, so having one present from the start means that gap is visible in your own tenant rather than only described in a later module.

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 10 GB/day of free Log Analytics ingestion for a new workspace’s first 31 days, then 5 GB per month across the billing account, 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 ARC406, 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, which ARC406 builds on.

The portal shows you the last seven days on a free tenant, per 0.3, in a filtered list view.

What you actually need is to write a query against the schema, per ei01 and ei13. Every detection in this course is a query, and a filter blade cannot express one. You also need retention beyond seven days, which per ARC402 11.1 is the property that cannot be recovered afterwards.

On cost: a lab workspace ingesting a handful of users generates very little and the free tier absorbs most of it. Watch it anyway, because the habit of knowing what a connector costs is the one ARC402 14.2 says most estates never form.

// EI0.10: does the workspace actually hold your sign-ins?
SigninLogs
| where TimeGenerated > ago(7d)
| summarize Rows = count(), Users = dcount(UserPrincipalName),
    Earliest = min(TimeGenerated), Latest = max(TimeGenerated)
// Zero rows means diagnostic settings, not a quiet tenant

This is the step that turns a tenant into something you can investigate.

The retention line is the reason to do this on day one rather than when a later module needs it. Diagnostic settings are not retrospective, so the seven days before you configure them stay seven days forever, and every exercise in this course that asks what happened last month needs the setting to already exist.

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.

Connect-MgGraph -Scopes "Directory.Read.All"

# The setting is on the Entra ID tenant, exposed through Azure Monitor
Get-AzDiagnosticSetting -ResourceId `
    "/providers/microsoft.aadiam/diagnosticSettings" |
    Select-Object Name, WorkspaceId,
        @{n='Logs';e={($_.Log | Where-Object Enabled).Category -join ','}}

The Logs column is the answer to the question the blade makes you click through four toggles to see: which categories are actually flowing, rather than which exist.

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:

// 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

Which categories you send decides what you can ask later. SignInLogs answers what happened at authentication and AuditLogs answers what changed in the directory, per 0.5, and the escalation stage of the kill chain lives entirely in the second one.

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:

# 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 for application governance, and again in ARC406 for workload identity and access reviews.

Confirm each item before starting EI1:

1. Entra admin center, access entra.microsoft.com, confirm Conditional Access is visible (Identity → Protection → 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. KQL, SigninLogs | take 10 returns results in Sentinel Logs
8. Security groups: all three groups exist with correct membership
9. Graph PowerShell, Get-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.

SigninLogs
| where TimeGenerated > ago(7d)
| summarize Rows = count(), Users = dcount(UserPrincipalName),
    Earliest = min(TimeGenerated), Latest = max(TimeGenerated)

Check 1 failing is the least interesting: the sign-ins have not happened yet, or you are looking at the wrong tenant.

Check 2 is the one that matters most and gets skipped. If no rows exist, diagnostic settings are wrong or were configured after the activity. Per ARC402 7.10 an empty table and a quiet tenant return the same result, and this is the check that separates them. Ingestion is not instant, so give it time before concluding anything.

Check 3 failing means the policy matched nothing, per 0.3, which is silence rather than a denial and the most common gap in this course.

Check 4 failing is the one you find out about later, the next time you enforce something.

Run check 2 before believing any later query that returns nothing.

Check 2 is the one to internalize rather than perform once. A query returning no rows is not evidence that nothing happened, and on a lab tenant the most likely explanation is always that the data never arrived, which is the same reasoning ARC402 applies to a quiet estate.

The build is the documented part. The note about its limits is the part that stops a lab result being read as an estate result.

Every module after this one assumes a tenant you can break, and building one takes six steps of which two carry an ordering that matters: the break-glass account exists before Security Defaults is turned off, and diagnostic settings are configured before there is anything you want to read. Neither is recoverable afterwards. What the lab gives you is real Conditional Access evaluation against real sign-ins, which is a different thing from reading about it. What it cannot give you is scale, the accumulated exemptions and unowned identities that make a production tenant hard, or the cost of being wrong, and that last absence is exactly the pressure that makes break-glass design and report-only feel optional. Write those three limits down.