In this module
EI0.9 The Lab Environment
Figure EI0.9 — Operational workflow from input through documented output.
Figure — The Lab Environment.
What you need and what it costs
The lab environment for this course requires three components, all available at no cost:
An M365 E5 developer tenant from the Microsoft 365 Developer Program provides a fully licensed E5 environment with 25 user licenses. E5 includes Entra ID P2, which unlocks every identity security feature covered in this course: conditional access, Identity Protection, PIM, access reviews, entitlement management, and advanced audit logging. The developer tenant is completely separate from any production environment — you cannot accidentally affect a real organization.
An Azure subscription connected to the developer tenant provides access to Microsoft Sentinel, Log Analytics workspaces, and Azure resources. The free tier includes 5 GB per day of log ingestion, which is more than sufficient for a lab environment. Sentinel's free trial provides 31 days of the full Sentinel experience at no cost.
A FIDO2 security key is recommended but not required. Physical security keys (such as YubiKey 5 NFC, approximately $25-50) allow you to complete the phishing-resistant authentication exercises in EI2 and test token protection scenarios in EI7. If you do not have a physical key, you can use the passkey functionality in Microsoft Authenticator (synced passkeys) for most exercises once passkey profiles are configured in your developer tenant.
Total cost: $0 for the M365 and Azure components. $25-50 for a physical security key if you want the full hands-on experience.
Step 1: Create the M365 developer tenant
Navigate to developer.microsoft.com/en-us/microsoft-365/dev-program and sign up for the Microsoft 365 Developer Program. If you already have a Microsoft account (personal or work), you can use it to sign up. If not, create one.
If you can't get a developer tenant: Microsoft has 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 signing up for Visual Studio Dev Essentials (free) at visualstudio.microsoft.com first, then retry. If that doesn't work, purchase a single M365 E5 license ($57/user/month) for the full Entra ID P2 stack this course requires, or start with an M365 Business Premium trial ($22/user/month after trial) — Business Premium includes Entra ID P1 and Conditional Access but not P2 features like PIM and Identity Protection. See MSA0.6 — Alternative Lab Options for detailed instructions.
Once enrolled, click "Set up E5 subscription." Choose "Instant sandbox" for the fastest setup — this creates a pre-configured tenant with 16 sample users, sample mail and events data, and SharePoint sites. Alternatively, choose "Configurable sandbox" if you want full control over the tenant from scratch. For this course, the instant sandbox is recommended because the sample users and data provide a realistic environment for the sign-in log exercises in EI1.
Record your administrator credentials. The admin account will be in the format admin@[yourdomain].onmicrosoft.com. This account is a Global Administrator and will be used for all configuration exercises. In later modules, you will create additional accounts with lesser roles to practice the principle of least privilege.
The developer tenant renews automatically every 90 days as long as you are using it for development activity. Running the exercises in this course counts as development activity.
Step 2: Create sample users for identity security scenarios
The instant sandbox includes 16 sample users, but the identity security exercises benefit from a specific set of users that map to common organizational roles. Create the following additional users in the Entra admin center (Identity → Users → All users → New user → Create new user):
Security team:
- alex.security@[yourdomain].onmicrosoft.com — your security analyst account. Assign Security Reader and Security Administrator roles.
- jordan.secops@[yourdomain].onmicrosoft.com — your SOC analyst account. Assign Security Reader role only.
Privileged accounts:
- admin.break1@[yourdomain].onmicrosoft.com — break-glass emergency access account. Assign Global Administrator with permanent (not PIM-eligible) assignment. No MFA configured (this is intentional — break-glass accounts must be accessible when all other authentication is unavailable). You will monitor this account with detection rules in EI13.
- admin.break2@[yourdomain].onmicrosoft.com — second break-glass account. Same configuration. Two break-glass accounts provide redundancy.
Standard users for testing:
- casey.finance@[yourdomain].onmicrosoft.com — finance department user. Used for BEC scenario exercises.
- morgan.external@[yourdomain].onmicrosoft.com — external contractor. Used for B2B and external identity exercises in EI11.
Create a security group called "Identity Security Lab Users" and add all standard users (not the break-glass accounts). You will target conditional access policies at this group throughout the course.
Create a security group called "Phishing-Resistant MFA Users" — initially empty. You will add users to this group as you deploy phishing-resistant authentication in EI2.
Create a security group called "Privileged Users" and add the admin account and the security team accounts. This group will be the target of stricter conditional access policies in EI3.
Step 3: Connect an Azure subscription and deploy Sentinel
If you do not already have an Azure subscription, navigate to azure.microsoft.com/free and create one using the same Microsoft account that owns the developer tenant. The free tier provides $200 in credits for the first 30 days and permanent free access to many services including 5 GB/day of Log Analytics ingestion.
In the Azure portal (portal.azure.com), create a resource group called "rg-identity-security-lab" in a region close to you. Within this resource group, create a Log Analytics workspace called "law-identity-lab." This workspace will receive the Entra ID sign-in and audit logs that you query throughout the course.
Deploy Microsoft Sentinel on the Log Analytics workspace: navigate to the Sentinel service in the Azure portal, click "Create," and select the law-identity-lab workspace. The free trial activates automatically.
After Sentinel is deployed, enable the Microsoft Entra ID data connector. Navigate to Sentinel → Configuration → Data connectors. Search for "Microsoft Entra ID" (it may still appear as "Azure Active Directory" in some regions). Open the connector page and enable all available 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. Click "Apply Changes."
This data connector creates an additional ingestion path that complements the diagnostic settings you will configure in Step 4. The Sentinel data connector integrates with Sentinel's built-in analytics rule templates — when you reach EI13 (Detection Engineering), you will find that many identity-focused rule templates are already available in the Content Hub and can be deployed with a few clicks as a starting point for your custom detection library.
Additionally, enable the "Microsoft Defender XDR" data connector if prompted. This brings Defender for Identity alerts, Defender for Cloud Apps alerts, and cross-domain incidents into the Sentinel workspace — providing the unified view that EI16 (Defender XDR Integration) teaches you to operate.
Step 4: Configure diagnostic settings for Entra ID logs
This step routes Entra ID logs to your Sentinel workspace, enabling the KQL queries used in every module from EI1 onward.
In the Entra admin center, navigate to Identity → Monitoring & health → Diagnostic settings. Click "Add diagnostic setting." Name it "EntraID-to-Sentinel." Under "Logs," select all categories — at minimum, select SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, AuditLogs, RiskyUsers, UserRiskEvents, RiskyServicePrincipals, and ServicePrincipalRiskEvents. Under "Destination details," select "Send to Log Analytics workspace" and choose the law-identity-lab workspace.
After saving, Entra ID will begin streaming logs to the workspace. It may take 15-30 minutes for the first data to appear. You can verify by navigating to your Sentinel workspace → Logs and running the query SigninLogs | take 10. If results appear, the log routing is working. If not, wait and retry — initial population can take up to an hour.
Step 5: Generate initial sign-in activity
Your developer tenant needs sign-in activity to make the EI1 exercises meaningful. Sign in to several Microsoft 365 applications with different sample users:
Sign in to portal.office.com with the admin account. Open Outlook, Teams, and SharePoint. Sign out. Sign in with casey.finance and access Outlook and OneDrive. Sign in with alex.security and access the Entra admin center. Each sign-in generates entries in the SigninLogs table that you will query in EI1.
If you have access to a mobile device, install the Microsoft Authenticator app 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 have a VPN or can access the internet from a different network, sign in from the alternative network to generate sign-in logs from a different IP address. This creates the "unusual location" data that is useful for the baseline exercises in EI1 and the risk detection exercises in EI5.
Step 6: Verify the lab environment
Run through this verification checklist to confirm everything is working before proceeding to EI1:
Try it yourself
Try It — Lab Verification Checklist
Complete each item and confirm it works:
1. Entra admin center access: Navigate to entra.microsoft.com. Confirm you can access Identity → Protect & secure → Conditional Access. (Expected: no policies configured yet.) 2. Sign-in logs populated: Navigate to Identity → Monitoring & health → Sign-in logs. Confirm at least one sign-in event appears. Click on it and verify you can see the Authentication Details and Conditional Access tabs. 3. Sample users exist: Navigate to Identity → Users → All users. Confirm you can see the sample users from the instant sandbox plus the users you created in Step 2. 4. Azure subscription connected: Navigate to portal.azure.com. Confirm you can access the law-identity-lab Log Analytics workspace. 5. Sentinel deployed: Navigate to the Sentinel service. Confirm the workspace is listed and active. 6. Diagnostic settings configured: Navigate to Entra admin center → Identity → Monitoring & health → Diagnostic settings. Confirm your diagnostic setting is listed and shows "Sending." 7. KQL query works: In the Sentinel workspace, navigate to Logs. Run SigninLogs | take 10. Confirm results appear. If no results, the log routing may need more time — wait 30 minutes and retry. 8. Security groups exist: Confirm "Identity Security Lab Users," "Phishing-Resistant MFA Users," and "Privileged Users" groups exist with the correct membership.
If all eight items pass, your lab environment is ready for EI1.
The myth: I have access to our production Entra ID tenant. I can practice conditional access and authentication configuration there.
The reality: Practicing identity security configurations in a production environment risks locking out users, breaking application access, and triggering security incidents. A misconfigured conditional access policy can block all users from signing in. An incorrectly configured authentication methods policy can prevent users from completing MFA. An Identity Protection policy set too aggressively can flag legitimate users as risky and force password resets across the organization. The developer tenant exists specifically so you can make mistakes safely. Practice every configuration in the developer tenant first. Only deploy to production after verifying the configuration works correctly and understanding the impact. EI8 covers the report-only testing methodology for safe production deployment.
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
- 17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
- The Defense Design Method — the six-step framework applied to every identity control you'll build
- EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
- Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
- Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain