Forem: Christian

Event-Driven Threat Detection: Building Real-Time Security on Conditional Access Gaps

Christian — Thu, 26 Mar 2026 10:03:40 +0000

In the previous post, we identified three key gaps that Conditional Access cannot address:

Brute force patterns (e.g. 10 failures in 2 minutes)
Activity from excluded users (e.g. executives bypassing geo-blocking)
behavioural anomalies (e.g. Saturday midnight logins)

This post builds the detection layer that catches what CA misses. Not prevention but detection. Stream Analytics complements Conditional Access, not replaces it.

What this system detects:

Brute force patterns (5+ failures in 10-minute windows)
Geographic anomalies from excluded users (non-UK access with no CA oversight)
behavioural anomalies (off-hours activity from UK locations)

What this system does NOT detect:

Token theft without anomalous sign-in activity
Lateral movement after successful authentication
Data exfiltration post-login

This highlights a critical principle: identity security requires both preventative controls (Conditional Access) and detective controls (event-driven monitoring).

Note: This is about detection. This should feed into a SIEM integration for SOC investigation and response

Architecture: Event Hub + Stream Analytics

The Pipeline:

Entra ID sign-ins → Real authentication events (success, CA blocks, password failures)
Event Hub (signin-events) → Buffers events for stream processing (2 partitions, 1-day retention)
Stream Analytics → 3 continuous queries running SQL against event stream
Event Hub (threat-alerts) → Stores detected threats with full investigation context

Why Event Hub? Decouples collection from processing. Events persist even if Stream Analytics fails. Query has bug? Replay events with corrected query. Connection drops? Events buffered.

Why monitor excluded users? When Senior Level executive logs in from New York, CA policy doesn't apply (user excluded from geo-blocking) → authentication succeeds → no CA oversight. Stream Analytics flags this for investigation: legitimate executive travel or compromised account?

Infrastructure: Terraform deploys everything in ~5 minutes. Event Hub Basic tier (£0.86/day), Stream Analytics 1 SU (£0.10/hour active).

With the ingestion layer in place, we can now define detection logic as continuous queries running against the event stream.

Query 1: Brute Force Detection

Purpose: Detect 5+ authentication failures from same user within 10-minute window.

SELECT
    userPrincipalName,
    COUNT(*) as failed_attempts,
    System.Timestamp() AS window_end,
    'Failed Login Spike' as alert_type
INTO [FailedLoginOutput]
FROM [EventHubInput]
WHERE status.errorCode <> 0
GROUP BY userPrincipalName, TumblingWindow(minute, 10)
HAVING COUNT(*) >= 5;

How tumbling windows work:

Fixed 10-minute intervals: 14:00-14:09, 14:10-14:19, etc.
Non-overlapping: User with 6 failures in one window → alert fires
Separate windows: 3 failures in window 1 + 3 in window 2 → no alert (distributed, not burst)

Why this matters: Prevents alert fatigue from slow distributed attacks while catching concentrated bursts indicative of automated credential stuffing.

Key decision: Include errorCode 53003 (CA blocks) or only 50126 (wrong passwords)?

Early iteration excluded CA blocks (user might have correct password, wrong location—not a credential attack). After testing, included both to capture attackers trying multiple locations during brute force.

Production teams: Adjust based on threat model. Exclude 53003 for pure credential attacks. Include for comprehensive activity monitoring. Or better still; split them into separate detections.

Query 2: Geographic Anomalies

Purpose: Flag ALL non-UK access for investigation. Operational staff will be CA-blocked, but we want to monitor excluded executives.

SELECT
    userPrincipalName,
    location,
    ipAddress,
    createdDateTime,
    'Non-UK Access' as alert_type
INTO [HighRiskOutput]
FROM [EventHubInput]
WHERE location NOT LIKE '%United Kingdom%'
    AND location NOT LIKE '%UK%'
    AND location NOT LIKE '%, GB'
    AND location IS NOT NULL
    AND location <> 'Unknown, Unknown';

The GB Location Bug (cost me an hour of debugging):

Version 1 (failed):

WHERE location NOT LIKE '%UK%' AND location NOT LIKE '%United Kingdom%'

Looked reasonable. Deployed. Tested.

Alerts fired for Salford, Manchester, Islington—all UK cities!

The problem: Entra ID uses ISO country code "GB", not "UK". Sign-in location appears as "Salford, GB", not "Salford, UK".

My query checked NOT LIKE '%UK%'. It correctly detected "Salford, GB" doesn't contain "UK"—so it flagged a UK city as non-UK. False positive cascade.

Version 2 (deployed):
Added NOT LIKE '%, GB' to catch the ISO format. Also added <> 'Unknown, Unknown' to filter geolocation lookup failures.

Lesson: Never assume data format. Always inspect actual payloads before writing filters. The GB vs UK issue is obvious in hindsight—but you only find it by testing with real data.

Why alert on excluded users?

Executive logs in from Singapore → Policy doesn't apply (excluded from geo-blocking) → Stream Analytics flags it → Security investigates:

Check group membership → Senior Level executive
Verify CA policy exclusion → Correctly excluded
Conclusion: Legitimate travel (no action) OR unexpected location (escalate)

Alert forces human review of activity from users who bypass CA policies.

Query 3: Off-Hours Activity

Purpose: Flag UK-based logins on weekends or outside 9-5 UTC business hours.

SELECT
    userPrincipalName,
    location,
    createdDateTime,
    DATEPART(hour, createdDateTime) as login_hour,
    DATEPART(weekday, createdDateTime) as day_of_week,
    'Off-Hours Activity' as alert_type
INTO [OffHoursOutput]
FROM [EventHubInput]
WHERE (
    location LIKE '%, GB'
    OR location LIKE '%United Kingdom%'
    OR location LIKE '%UK%'
  )
  AND (
      DATEPART(weekday, createdDateTime) IN (1, 7)  -- Weekday numbering: 1=Sunday, 7=Saturday (verify DATEFIRST setting)
      OR DATEPART(hour, createdDateTime) NOT BETWEEN 9 AND 17
  );

UK-only location filter: Non-UK logins already trigger Query 2 (geographic anomalies). This query focuses on unusual timing from allowed locations. Prevents duplicate alerts—keeps queries mutually exclusive.

Location matching brittleness: This query uses the same string pattern matching as Query 2 (LIKE '%, GB'). For production, consider extracting countryOrRegion during ingestion and using structured field comparison (WHERE country = 'GB') instead of string matching. More reliable and avoids the GB vs UK inconsistency issues.

Timezone considerations: All Entra ID timestamps are UTC. This query checks UTC hours 9-17, not local UK time. Implications:

UK summer (BST, UTC+1): "9-5 UK time" = 8-16 UTC → query misses 16-17 UTC hour
UK winter (GMT, UTC+0): "9-5 UK time" = 9-17 UTC → query is accurate

For precise UK business hours detection, adjust query to account for BST/GMT transitions or accept UTC-based approximation.

Early iteration mistake: Singapore login at 2 AM triggered BOTH Query 2 (non-UK) AND Query 3 (off-hours). Duplicate alerts cause investigation fatigue.

Fix: Added UK-only filter to Query 3. Now each query targets a distinct signal dimension:

Query 1: Authentication failures (any location, any time)
Query 2: Geographic anomalies (non-UK access, any time)
Query 3: Behavioral anomalies (UK access, unusual timing)

Note: A single event can still trigger multiple queries if it matches multiple dimensions. For example, a UK user failing login 10 times at 2 AM on Saturday triggers Query 1 (failures) AND Query 3 (off-hours). This is expected—each query surfaces a different investigation angle for the same suspicious event.

Data Collection: Graph API to Event Hub

Python script fetches sign-in logs from Graph API → transforms to simplified schema → sends to Event Hub in batches.

# Get connection string from Terraform
cd terraform
terraform output -raw eventhub_send_connection_string

# Add to .env file
echo "EVENTHUB_CONNECTION_STRING=$(terraform output -raw eventhub_send_connection_string)" >> ../scripts/.env

# Process events
cd ../scripts
python export_signin_logs_to_eventhub.py

Typical completion: ~30 seconds for 3300 events.

Schema transformation:

{
    "userPrincipalName": log["userPrincipalName"],
    "status": {
        "errorCode": log.get("status", {}).get("errorCode", 0)
    },
    "location": f"{log.get('location', {}).get('city')}, {log.get('location', {}).get('countryOrRegion')}",
    "ipAddress": log.get("ipAddress"),
    "createdDateTime": log["createdDateTime"]
}

Debugging gotcha: Script crashed with cryptic DNS error (getaddrinfo failed). Looked like network issue. Spent 20 minutes checking firewalls, DNS settings, network connectivity.

Actually: Extra quote in .env file: 'Endpoint=sb://.... Parser read the quote, couldn't parse hostname, threw DNS error.

Lesson: Connection string format errors manifest as network failures. Print connection strings (redacted) to verify exact format before debugging network stack.

Investigation Workflows

All 3300 threats stored in Event Hub threat-alerts with complete investigation context. Azure Portal → Event Hub → Data Explorer shows each threat.

Example 1: Brute Force Attack

The sign-in logs show repeated failures (error code 50126) from a UK location.
Individually, these events would not trigger Conditional Access. However, when analysed as a sequence, they form a clear brute force pattern and worth investigating.

Investigation:

Check user's normal location: UK (matches profile?)
Failed attempts: 10 in 2 minutes (definite brute force pattern)
Action: Contact user to verify, force password reset, review MFA enrollment

Example 2: Excluded User (Critical Scenario)

Investigation:

Alert received: Non-UK access from New York
Check Entra ID: Navigate to user → Group memberships
Discovery: User is member of "Senior Level" group (executives)
Verify CA policy: "LAB - Block Non UK (Exclude Senior Level)" → Senior Level group excluded
Conclusion: Expected (excluded executive), NOT breach

Policy doesn't apply to this user (excluded for travel requirements). No remediation needed—log for audit trail.

This demonstrates defense-in-depth: CA policy doesn't apply (excluded), Stream Analytics flagged it for visibility, security team confirms expected behavior.

Without Stream Analytics, this login is invisible. No flag, no investigation, no confirmation that exclusion is being used legitimately vs. account compromise.

Example 3: Off-Hours Activity

Investigation:

Location: UK (expected for this user)
Time: Saturday 11:34 (outside Mon-Fri 9-5)
Action: Log for trend analysis, contact user if pattern emerges

Key Learnings

1. Real Data Reveals Edge Cases: GB vs UK location bug (Entra uses "Salford, GB"), CA blocks (53003) vs auth failures (50126) require different handling, connection string format errors manifest as DNS failures.

2. Event Hub Decouples Collection from Processing: Events persist even if Stream Analytics fails. Query bug? Replay with corrected query. Critical for production reliability. This also enables replay—allowing you to reprocess historical events with updated detection logic.

3. Alert Design Prevents Fatigue: Early iteration had duplicate alerts (Singapore 2 AM triggered geo + off-hours). Fix: UK-only filter for Query 3. Each query targets distinct signal dimension.

4. IaC Accelerates Iteration: Manual deployment ~2 hours. Terraform apply ~5 minutes. Debugging 2 query bugs took ~30 minutes with IaC vs. 4+ hours manual.

Security Audit: Stream Analytics in Production

This is a LAB environment. The following security gaps would fail production review.

What We Skipped (Intentionally):

Component	Lab Setup	Production Requirement	Risk
Network	Public Event Hub endpoints	Private Link + VNet integration	Data exposure, unauthorized access
Secrets	Connection strings in .env files	Azure Key Vault + managed identities	Credential theft, no rotation
Encryption	Basic tier (no encryption at rest)	Premium tier with customer-managed keys	Data breach if storage compromised
Query Changes	Manual edits in portal	CI/CD with approval gates	Accidental query breakage, no audit trail
Monitoring	No alerting on job failures	Azure Monitor alerts + runbooks	Silent detection failures
Data Retention	1-day Event Hub retention	Long-term storage (SQL/Log Analytics)	Compliance violations, lost audit trail

Production Must-Haves for Stream Analytics:

1. Network Isolation

Private Link for Event Hub (~£12/month per endpoint)
VNet integration for Stream Analytics job
Network security groups restricting inbound/outbound

2. Identity & Access

Managed identities for Stream Analytics → Event Hub authentication
Azure Key Vault for any connection strings (Python script)
RBAC with least privilege (no account keys in queries)

3. Data Protection

Premium Event Hub with encryption at rest (~£531/month)
Customer-managed keys (CMK) for compliance
TLS 1.2+ for all data in transit

4. Operational Excellence

Multi-region deployment for disaster recovery
Automated failover for Event Hub namespace
Azure Monitor alerts on: job stopped, output errors, SU utilization >80%
Runbooks for common failure scenarios

5. Change Management

Version control for query definitions (Git)
CI/CD pipeline for query deployments
Approval gates before production changes
Rollback capability if query breaks

6. Compliance & Audit

Forward threat-alerts to Log Analytics workspace (7-year retention)
Immutable audit logs for compliance
Data residency controls for GDPR/regional requirements
Regular access reviews for Event Hub/Stream Analytics permissions

Conditional Access evaluates individual sign-in events.
This system detects patterns across events—the difference between blocking risk and understanding it.

Skills demonstrated: Stream Analytics query development, Event Hub event-driven architecture, SQL tumbling windows, real-time threat detection, production security architecture design, infrastructure as code iteration.

Conditional Access Realism: Testing Real Sign-Ins to Understand Policy Gaps

Christian — Tue, 24 Mar 2026 15:07:08 +0000

Your Conditional Access policy blocked risky logins last week. Working as designed.

But can you answer these questions?

Are your executives' travel logins being monitored?
Can you detect 10 failed password attempts in 2 minutes?
What happens when excluded users authenticate from unusual locations?

Conditional Access makes point-in-time decisions: Allow or Block. Binary. Conditional Access policies themselves do not aggregate events over time or detect patterns. While Entra ID provides risk detections (e.g., via Identity Protection), these are separate systems and not configurable at the CA policy level. It can't tell you if a user failed authentication 10 times in 2 minutes. It can't flag unusual behavior from users excluded from your policies.

We built a synthetic login-generator to simulate real-world authentication patterns. The generator intentionally models probabilistic attack behavior and temporal variance to mimic real-world authentication noise rather than uniform test traffic.

UK locations and international travel. Successful logins and deliberate brute force attacks. Business hours activity and out of hours authentications. Policy compliance and executive exclusions.

The result: CA enforced policy exactly as designed. But successful logins happened—some legitimate, some from excluded executives, some exhibiting patterns only visible through cross-event analysis.

We're testing how Conditional Access protects identities—and discovering where it needs help.

The Problem: Conditional Access's Blind Spots

Conditional Access excels at point-in-time decisions:

Is this IP address risky? Block.
Is the sign-in location outside the UK? Block access.

Every authentication request gets evaluated independently. Allow or deny. Binary.

What CA cannot detect:

Patterns over time: Five failed password attempts in 10 minutes? CA evaluates each attempt separately. No aggregation.
Behavioral anomalies: Finance manager who normally works 9-5 suddenly authenticating at 2 AM? CA doesn't track baselines.
Activity from excluded users: Executive excluded from geo-blocking logs in from Singapore at midnight? Policy doesn't apply—authentication succeeds with zero oversight. No Conditional Access enforcement or policy-driven detection
Distinction between policy blocks and authentication failures: User blocked by CA (wrong location, correct password) looks different from brute force attempt (wrong password, allowed location).

These aren't CA failures; they're architectural limitations. CA prevents threats at the door. It doesn't monitor patterns that develop across multiple authentication attempts.

To test these limitations, we built realistic authentication data.

Building the Authentication Event Generator

We built a Python script using MSAL (Microsoft Authentication Library) to generate realistic authentication events across hundreds of users. The script randomly selects users from a pool and generates logins with user credentials, it also tries the wrong password 10 times in 2 mins for 5 percent of users and I use a VPN app to simulate different geo-logins.

The Event Generation Strategy

Event Distribution:

Mix of successful and failed authentications
Geographic diversity:
- UK locations: Salford, Manchester, Islington
- Non-UK locations: New York, Zagreb, Qafsah, Karachi, Kyiv, etc
Temporal patterns: Business hours plus off-hours testing (late night, weekends)
Attack simulation: Concentrated bursts of rapid password failures (10 attempts per user in 2 minutes)

Why this distribution?: Real authentication traffic isn't uniform. Most activity happens during business hours from expected locations. Suspicious activity is the minority—but buried in normal traffic.

Technical Implementation: MSAL + ROPC Flow

The script uses Microsoft Authentication Library (MSAL) with Resource Owner Password Credential (ROPC) flow to generate real Entra ID sign-in events:

from msal import PublicClientApplication
import random
import time

PASSWORD = "redacted"
WRONG_PASSWORD = "redacted"
BRUTE_FORCE_RATE = 0.05  # 5% of logins trigger brute force
BRUTE_FORCE_ATTEMPTS = 10  # 10 attempts in 2 minutes

def generate_login(username, password, is_intentional_failure=False):
    """Generate a real sign-in via ROPC flow"""
    app = PublicClientApplication(
        CLIENT_ID,
        authority=f"https://login.microsoftonline.com/{TENANT_ID}"
    )

    result = app.acquire_token_by_username_password(
        username=username,
        password=password,
        scopes=["User.Read"]
    )

    if "access_token" in result:
        print(f"✅ {username} - Login successful")
        return True
    else:
        print(f"❌ {username} - Failed")
        return False

# Main loop: randomly select users and generate logins
for user in user_pool:
    trigger_brute_force = random.random() < BRUTE_FORCE_RATE

    if trigger_brute_force:
        # Brute force: 10 failed attempts in 2 minutes
        for attempt in range(BRUTE_FORCE_ATTEMPTS):
            generate_login(user, WRONG_PASSWORD, is_intentional_failure=True)
            time.sleep(12)  # ~12 seconds between attempts
    else:
        # Normal login
        generate_login(user, PASSWORD)

    time.sleep(10)  # Rate limiting between users

Why ROPC for labs:

✅ Creates real Entra ID sign-in events (triggers CA policies)
✅ Generates authentic telemetry (same schema as production)
✅ Scriptable and repeatable
❌ ROPC bypasses MFA and modern authentication controls, making it unsuitable for production and risky even in poorly isolated environments

Geographic diversity: We manually switched VPN endpoints (UK: Salford, Manchester; Non-UK: Miami,Zagreb, Qafsah, Karachi, Kyiv, etc) before running the script. Each VPN location creates different IP addresses, ensuring Entra ID's geolocation service sees real non-UK sign-in attempts that trigger CA policy evaluation.

The Conditional Access Policy Design

We created a policy that reflects realistic business requirements: strict geo-blocking for operational staff, global access for executives.

Policy Name: "LAB - Block Non UK (Exclude Senior Level)"

*Policy blocks non-UK locations but excludes Senior group—creating a monitoring gap we'll address in next section

Policy Configuration:

Setting	Value	Rationale
Users	All users	Policy applies to entire directory
Exclusions	Senior Level group (executives)	Global access requirements (travel, M&A, incident response)
Cloud apps	All cloud apps	Protect all resources
Locations	NOT United Kingdom	Enforce only for non-UK sign-ins
Grant	Block access	Zero tolerance for non-UK access from operational staff

The Three User Populations This Creates:

Operational Staff from UK → Policy applies → Location = UK → Access granted
Operational Staff from Non-UK → Policy applies → Location ≠ UK → Access blocked (errorCode: 53003)
Senior Level Executives from Non-UK → Policy doesn't apply (excluded) → Access granted (monitoring gap)

Why Senior Levels needs exclusions: CEO travels for board meetings, CFO accesses systems during international audits, security team responds to incidents 24/7 from any location. Strict geo-blocking would block critical business operations.

Critical security consideration: While the policy doesn't apply to excluded users (no CA enforcement), Entra ID still generates sign-in events for every authentication attempt. These events contain full context (user, location, IP, timestamp, outcome) and flow to our monitoring systems. This means:

✅ Excluded users' activity is logged and available for investigation
✅ SOC can detect suspicious patterns from executive accounts (unusual locations, off-hours access)
✅ Forensic analysis possible if executive account is compromised

The gap: Detection isn't automated within CA policy framework. Manual log review required—or Stream Analytics (next section) for real-time monitoring.

Understanding CA Evaluation Outcomes

When Conditional Access evaluates an authentication request, there are four possible outcomes.

Outcome 1: SUCCESS (Policy Satisfied)

{
  "userPrincipalName": "chloe.oconnel@acme.onmicrosoft.com",
  "status": { "errorCode": 0 },
  "conditionalAccessStatus": "success",
  "location": { "city": "Manchester", "countryOrRegion": "GB" }
}

What this means: User authenticated successfully, CA evaluated and all conditions met (UK location), access granted. Normal activity.

Outcome 2: FAILURE - CA Block (Policy Enforced)

{
  "userPrincipalName": "Ethan.Bell@acme.onmicrosoft.com",
  "status": {
    "errorCode": 53003,
    "failureReason": "Blocked by Conditional Access"
  },
  "conditionalAccessStatus": "failure",
  "location": { "city": "Zagreb", "countryOrRegion": "Croatia" }
}

What this means: User might have correct password, but CA blocked before authentication completed. Policy condition not met (non-UK location). No access token issued.

CRITICAL DISTINCTION:

errorCode 53003 = CA block (policy prevented access)
errorCode 50126 = Invalid password (authentication failure, potential brute force)

These are different security events: CA block means user blocked by policy (could have correct password, wrong location). Auth failure means wrong password (typo or attack).

Outcome 3: NOT APPLIED (Policy Exemption - Monitoring Gap)

{
  "userPrincipalName": "wei.huang@acme.onmicrosoft.com",
  "status": { "errorCode": 0 },
  "conditionalAccessStatus": "notApplied",
  "location": { "city": "Qafsah", "countryOrRegion": "Tunisia" },
  "appliedConditionalAccessPolicies": [{
    "displayName": "LAB - Block Non UK (Exclude Senior Level)",
    "result": "notApplied"
  }]
}

What this means: User is in excluded group (Senior Level executives). CA policy doesn't evaluate this user at all. Authentication succeeds based on credentials alone.

This is the security gap: Excluded users' activity happens with no CA oversight. If executive account is compromised, attacker gets same exemptions. No automated detection.

Investigation required: Manual review needed. Is this legitimate travel or compromised executive account?

Stream Analytics will monitor conditionalAccessStatus: "notApplied" events to flag excluded users' activity.

Outcome 4: FAILURE - Authentication Failure (Wrong Password)

{
  "userPrincipalName": "rhys.oconnel@acme.onmicrosoft.com",
  "status": {
    "errorCode": 50126,
    "failureReason": "Invalid username or password"
  },
  "conditionalAccessStatus": "notApplied",
  "location": { "city": "Salford", "countryOrRegion": "GB" }
}

What this means: User failed to authenticate

(wrong password). CA was not evaluated because authentication failed before CA stage.This ordering is critical: it explains why brute force attacks (invalid credentials) never reach Conditional Access and therefore bypass policy evaluation entirely but should be worth investigating.

Why CA shows notApplied: Authentication pipeline validates credentials first, then evaluates CA. If credentials fail, CA never runs.

This is the signal for brute force detection: Multiple errorCode 50126 events in short time window = potential attack.

User is logging in from New York so should be blocked by CA but it was not applied as it failed password authentication before reaching the CA engine so it was not applied in this case.

Comparison Table: The Four Outcomes

Outcome	errorCode	conditionalAccessStatus	Meaning	Investigation?
Success	0	`success`	User authenticated, policy met	No
CA Block	53003	`failure`	Policy blocked access	Depends
Not Applied (Excluded)	0	`notApplied`	Policy skipped (user excluded)	YES
Auth Failure	50126	`notApplied`	Wrong password	YES

Key takeaway: Not all "notApplied" events are the same. Excluded users vs. authentication failures both show notApplied, but for different reasons. Check errorCode to distinguish.

Real-World Scenarios: Policy in Action

Scenario 1: Operational Staff from Non-UK (CA Block)

User: IT admin attempting login from Zagreb
CA Evaluation: Policy applies → Location = Zagreb, Croatia (non-UK) → Blocked (errorCode 53003)
Result: Access denied. Policy working as designed.

Scenario 2: Senior Level Executive from Non-UK (Monitoring Gap)

User: An executive login from Qafsah at 10:24 PM
CA Evaluation: User in Senior Level group → Policy doesn't apply → Access granted (notApplied)
Result: Login succeeds. No CA oversight.

Investigation needed: Is this legitimate travel or compromised executive account? CA can't tell—it never evaluated the risk.

Next section: Stream Analytics will flag all non-UK access from excluded users for investigation.

Scenario 3: Brute Force Attack (CA Can't Detect)

User: A user with 10 wrong password attempts in 2 minutes from UK
CA Evaluation: Each attempt fails authentication → CA never runs (evaluated independently)
Result: 10 failed logins in 2 minutes. CA policies do not natively detect or respond to rapid authentication failures. While platform-level protections like smart lockout may mitigate this, they are not visible or tunable within Conditional Access policy logic.

What CA detects: Nothing. CA evaluates each attempt independently—no aggregation, no pattern detection.

Next section: Stream Analytics will aggregate errorCode 50126 events over time windows to detect brute force.

Scenario 4: Off-Hours Activity (CA Allows, But Suspicious)

User: HR coordinator at 2:13 AM Saturday from Salford
CA Evaluation: Location = UK → Policy met → Access granted
Result: Login succeeds.

Why this is suspicious: HR coordinator normally works Mon-Fri 9-5. Why 2 AM Saturday? CA doesn't track baselines or detect behavioral anomalies.

Next section Stream Analytics will flag off-hours activity for investigation.

Results: What CA Caught and Missed

What Conditional Access Successfully Protected

✅ Geo-blocking enforcement: Non-UK login attempts from operational staff blocked
✅ Policy compliance: Every non-UK operational staff login denied
✅ Legitimate access: Successful logins from authorized users in compliant scenarios
✅ Executive mobility: Senior Level global access maintained

CA did exactly what it's designed to do: Evaluate each authentication request against location policy, enforce blocks, allow compliant requests and exempted users.

What Conditional Access Missed

❌ Brute force patterns: Rapid authentication failures went undetected—CA evaluated each attempt independently
❌ Excluded user activity: Non-UK logins from Senior Level executives happened with no CA oversight
❌ Behavioral anomalies: Off-hours logins from operational staff allowed (UK location satisfied policy, but timing unusual)
❌ Attack progression: No visibility into whether failed attempts escalate over time

These aren't CA failures—they're gaps in CA's detection capabilities. CA prevents known threats. It doesn't detect patterns over time, monitor exempted users, or identify behavioral anomalies.

Security Audit: Lab vs. Production Considerations

This is a LAB environment for learning. The following security gaps exist and would fail production review:

What We Skipped (Intentionally)

Secrets Management: Client ID and Tenant ID hardcoded in Python script. Production requires Azure Key Vault with managed identities.

ROPC Flow: Deprecated authentication method that bypasses MFA. Production must use interactive flows (authorization code flow, device code flow) that support modern security features.

Password Storage: Plaintext passwords in script constants (redacted in snip}. Production requires secure credential management and certificate-based authentication.

Rate Limiting: No backoff logic for API throttling. Production needs exponential backoff and retry policies.

Production Requirements

When deploying authentication testing in production environments:

Use service principals with certificate authentication (not ROPC with passwords)
Store credentials in Azure Key Vault (retrieve via managed identity)
Implement proper error handling (API throttling, network failures, authentication errors)
Use test users in isolated tenant (never test against production user accounts)
Minimal Graph API scopes (only AuditLog.Read.All for reading sign-in logs, not Directory.Read.All)

Why we use ROPC in this lab: Creates authentic Entra ID sign-in events that trigger real CA policy evaluation. Allows reproducible testing scenarios. Production would use interactive authentication or real user logins for testing, not scripted automation.

The Three Gaps CA Can't Fill

Gap 1: Pattern Detection Over Time (Brute Force)

What CA can't do: Aggregate authentication failures over time windows.

Real-world impact: Attacker tries hundreds of passwords over hours from UK-based VPS. Each attempt: UK location (policy allows), wrong password (auth fails, CA doesn't evaluate). No detection, no lockout, no alert.

Solution needed: Time-windowed aggregation. "If user fails authentication 5+ times in 10 minutes, trigger alert."

Gap 2: Monitoring Excluded Users (Executive Compromise)

What CA can't do: Monitor excluded users' activity. No Conditional Access enforcement or policy-driven detection is applied to excluded users.

Real-world impact: Executive account compromised. Attacker logs in from Singapore at 2 AM. Policy doesn't apply (executive excluded) → Access granted → No alert.

Solution needed: Monitoring layer that flags ALL non-UK access (including excluded users) for investigation.

Gap 3: Behavioral Anomaly Detection (Off-Hours)

What CA can't do: Establish per-user behavioral baselines and detect deviations.

Real-world impact: Finance manager account compromised. Attacker logs in from UK-based VPS at midnight. UK location = policy allows. Unusual timing goes unnoticed for days.

Solution needed: Behavioral analytics that track normal patterns per user and flag outliers.

Next section will show you how to build it.

Conclusion: CA Prevents, Detection Detects

We tested Conditional Access with realistic authentication data:

What CA does brilliantly:

✅ Blocked non-UK login attempts from operational staff
✅ Maintained executive mobility
✅ Binary decisions executed instantly

What CA cannot do:

❌ Detect patterns over time (brute force)
❌ Monitor excluded users' activity (blind spot)
❌ Identify behavioral anomalies (off-hours, unusual locations)

Conditional Access evaluates context (location, device, risk signals) but not intent. A sequence of low-risk events can still represent high-risk behavior when viewed over time.

This isn't a criticism of CA—it's understanding its design: Conditional Access is a prevention control. It's not designed for continuous monitoring, pattern detection, or behavioral analytics.

Defense-in-depth requires both:

Conditional Access: Prevents threats at the door
Stream Analytics (next section): Detects patterns that slip through

Skills demonstrated:

MSAL authentication with ROPC flow (generating real Entra ID sign-in events for testing)
Realistic authentication data generation (geographic and temporal diversity)
Conditional Access policy design (geo-blocking with executive exclusions)
CA evaluation outcome interpretation (Success, Failure, Not Applied, Auth Failure)
Security gap analysis (what CA detects vs. what it misses)

Next: Event-Driven Stream Analytics Threat Detection — where we'll aggregate these events in real-time to catch brute force, monitor excluded users, and flag off-hours anomalies

We have the authentication data. We understand CA's gaps. Now let's build real-time detection that catches the patterns CA can't see.

Conditional Access evaluates events. Detection systems evaluate sequences.

Security failures happen in the gap between those two questions.

Building Hybrid Identity at Scale: 1,000+ Users from Active Directory to Entra ID

Christian — Sun, 15 Mar 2026 20:35:05 +0000

Description: Built a production-scale hybrid identity lab with 1,158 users
synced from Active Directory to Microsoft Entra ID. Used Terraform
for infrastructure-as-code, persistent disks to save £65/month,
and automated PowerShell imports. Includes UPN transformation,
OU structure, and honest security trade-offs.
Total cost: <£5/month
series: AI-IAM-Engineering-Lab

Most hybrid identity tutorials show you how to sync 5 test users. That's like learning to drive in an empty parking lot, then wondering why you crash in rush hour traffic. The real problems—UPN transformations that don't make sense, sync conflicts at scale, performance issues with thousands of objects—only surface when you're actually operating at volume.

This post walks through building a hybrid identity environment with 1,158 users. Over a thousand users with realistic department distributions, job titles, and organizational structures. We're deploying Active Directory on Azure using Terraform, automating the entire user import with PowerShell, and synchronizing everything to Microsoft Entra ID while dealing with the UPN transformation headaches.

Why Hybrid Identity Still Matters in 2026

Despite what cloud vendors want you to believe, 95% of enterprises still run hybrid identity. On-premises Active Directory isn't disappearing anytime soon. Legacy applications authenticate against it. Group policies manage thousands of workstations. And every single M365 deployment needs identity synchronization unless you're starting from absolute zero.

The gap between "cloud-only" marketing and operational reality creates a massive skill shortage. Identity engineers who can architect hybrid solutions at scale remain valuable precisely because this knowledge is just absolutely necessary to keep enterprises running.

Architecture: The Full Picture

Complete hybrid identity architecture: AD syncing to Entra ID via Entra Connect with UPN transformation

On-Premises Layer (simulated in Azure):

Windows Server 2022 domain controller running aiiam.local
1,158 users across six departments
Department-based OU structure
Users authenticate with @aiiam.local UPN

Synchronization Layer:

Microsoft Entra Connect with Password Hash Synchronization
30-minute delta sync intervals
UPN suffix transformation from .local to .onmicrosoft.com
OU filtering for organizational users only

Cloud Layer:

Microsoft Entra ID tenant: acme.onmicrosoft.com
1,158 synchronized users with hybrid identity attributes
Both UPNs work for seamless SSO

Active Directory uses sarah.mitchell@aiiam.local, but Entra ID needs a routable domain. Entra Connect handles this transparently—users can authenticate with either UPN.

Domain controller IDENTITYDC running aiiam.local with all AD services operational

Infrastructure Deployment: Terraform for Repeatability

Manual setup works for one-off demos. For labs you'll teardown and rebuild? Infrastructure-as-Code saves hours.

The Terraform config handles everything: virtual network, domain controller VM, storage for user data, and—critically—a persistent OS disk that survives terraform destroy.

Here's the persistent disk configuration:

resource "azurerm_windows_virtual_machine" "ad_server" {
  name                  = "ad-dc-vm"
  computer_name         = "IDENTITYDC"
  size                  = "Standard_D2s_v3"

  identity {
    type = "SystemAssigned"  # Managed identity for secure blob access
  }

  os_disk {
    name                 = "ad-dc-os-disk-persistent"
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
    disk_size_gb         = 128
  }
}

The disk name ad-dc-os-disk-persistent makes Azure treat it as pre-existing on subsequent deployments. First run: fresh Windows Server image. After terraform destroy and reapply: it reattaches the existing disk with your DC config intact.

💡 Game Changer: This persistent disk strategy transformed my workflow. Initial setup: 2-3 hours (domain promotion, user imports, Entra Connect config). With persistent disks: terraform destroy when done (saves money), terraform apply when needed (back online in 10 minutes with everything intact). For labs that run intermittently, this is the difference between £90/month and £5/month.

Cost optimization for intermittent labs:

resource "azurerm_dev_test_global_vm_shutdown_schedule" "ad_vm_shutdown" {
  virtual_machine_id    = azurerm_windows_virtual_machine.ad_server.id
  enabled               = true
  daily_recurrence_time = "1900"
  timezone              = "GMT Standard Time"
}

Auto-shutdown at 7 PM GMT means you're only paying for compute when actively using the lab. VM stopped: £0.02/day for disk storage. Total monthly cost: under £5. This is also a fail safe incase I forget to terraform destroy after a demo day to avoid charges for VM running.

Run terraform apply and watch Azure populate your resource group:

Terraform-deployed resources: VM, persistent disk, networking, and storage

Everything you need for hybrid identity lands in one resource group: persistent OS disk, Standard_D2s_v3 VM, storage account with the user JSON, network interface with static IP, security group, public IP, and virtual network. Tags track project phase for cost analysis across multiple lab environments.

User data JSON file uploaded to blob storage for VM initialization

Terraform uploads entra_users.json to blob storage, VM downloads it using a time-limited SAS token. Keeps sensitive data out of custom script extensions.

Active Directory Setup: Getting the Domain Right

Domain name choice matters. I used aiiam.local because .local is conventional for on-premises AD.

Installing AD DS features and promoting to domain controller with aiiam.local domain

After promotion and the inevitable reboot:

AD Web Services, DNS, Netlogon, and NTDS running—domain controller is operational

Organizational Unit Structure: Preparing for Scale

OU structure isn't just tidiness—it impacts Entra Connect filtering, Group Policy, and administrative delegation. I created AIIAM-Users as the parent OU holding all departmental OUs:

DC=aiiam,DC=local
├── AIIAM-Users
│   ├── Engineering
│   ├── Operations
│   ├── Executive
│   ├── Finance
│   ├── People
│   └── Security

Department-based organizational units under AIIAM-Users parent container

AIIAM-Users OU structure populated with users distributed across departments

The parent OU becomes the sync boundary. Default containers stay on-premises.

Importing 1,158 Users: Automation at Work

The user data: 1,158 AI-generated identities in entra_users.json. Each has realistic attributes—display name, job title, department, office location. The JSON came from Entra ID's Graph API format, which means it needed transformation for AD import (because of course Microsoft's two identity systems use different attribute names for the same data).

The PowerShell script does a few things: reads the JSON, creates OUs if they're missing, sets the correct UPN suffix, and most importantly—shows progress every 100 users so you don't spend 8 minutes wondering if it crashed.

Here's the core import logic:

# Read and parse JSON
$users = Get-Content "C:\IdentityLab\entra_users.json" | ConvertFrom-Json
Write-Host "Loaded $($users.Count) users from JSON" -ForegroundColor Cyan

# Department mapping from job titles
$departmentMap = @{
    "Engineer" = "Engineering"
    "Operations" = "Operations"
    "Executive" = "Executive"
    "Finance" = "Finance"
    "HR" = "People"
    "Director" = "Security"
}

$count = 0
foreach ($user in $users) {
    $count++
    $username = ($user.userPrincipalName -split '@')[0]

    # Determine department from job title
    $department = "Operations"  # default
    foreach ($key in $departmentMap.Keys) {
        if ($user.jobTitle -match $key) {
            $department = $departmentMap[$key]
            break
        }
    }

    New-ADUser -Name $user.displayName `
               -GivenName $user.givenName `
               -Surname $user.surname `
               -UserPrincipalName "$username@aiiam.local" `
               -SamAccountName $username `
               -Title $user.jobTitle `
               -Department $department `
               -Office $user.officeLocation `
               -Path "OU=$department,OU=AIIAM-Users,DC=aiiam,DC=local" `
               -AccountPassword (ConvertTo-SecureString "redacted!" -AsPlainText -Force) `
               -Enabled $true

    if ($count % 100 -eq 0) {
        Write-Host "Imported $count users..." -ForegroundColor Green
    }
}

Import script processing 1,100+ users with progress indicators

Import completed in 8 minutes. Progress indicators every 100 users prevented that "is this frozen?" anxiety.

1,157 users successfully imported in Active Directory across six departments

Department distribution:

Department	Users	Percentage
Operations	711	61.5%
Engineering	269	23.2%
Executive	69	6.0%
Finance	58	5.0%
People	48	4.1%
Security	2	0.2%

Operations dominated because the AI dataset included many operational roles: specialists, managers, coordinators. This mirrors real organizations where operational staff outnumber engineers.

The 2-Hour Gotcha That Almost Broke Everything

Here's the mistake that cost me two hours: my first import succeeded—1,157 users created in AD, everything looked perfect. Sync ran. Users appeared in Entra ID. Victory, right?

Wrong. The Department field was completely empty in Entra ID. Not null. Just... blank. For every single user.

I spent two hours thinking Entra Connect was broken. Checked attribute mappings. Re-ran sync. Read Microsoft docs. Questioned my career choices. Finally realized the source JSON didn't have a department attribute—it only had jobTitle. Entra Connect was working perfectly. It was faithfully syncing an empty field.

The fix: extract department from job titles using pattern matching in PowerShell during import. Worked for 99% of cases. Edge cases got dumped into Operations as the default. Lesson learned: validate your source data BEFORE building infrastructure around it.

Why does this matter? Try building conditional access policies based on department when every user's department is blank. Can't require MFA for Finance if you can't identify who's in Finance.

Entra Connect Configuration: Where Theory Meets Reality

Downloading Entra Connect installer directly to the domain controller

1. Authentication Method

Selecting Password Hash Synchronization for simplest hybrid auth

Three options: Password Hash Sync (PHS), Pass-through Authentication (PTA), or Federation. PHS wins for labs and many production scenarios:

Simplicity: No additional infrastructure
Resilience: Cloud auth works even if on-premises AD is offline
Security: One-way hash sync, not passwords
Seamless SSO: Transparent auth on domain-joined machines

PTA needs agents online. Federation demands ADFS infrastructure. PHS just works.

2. Service Account Permissions

Creating service account with required permissions for synchronization

Let the wizard create the service account. It grants precisely the needed permissions.

3. UPN Suffix Mapping: The Confusing Part

When Entra Connect analyzes your AD forest, it finds @aiiam.local. The wizard warns: "UPN suffix 'aiiam.local' is not verified in Entra ID and cannot be added."

You'll see: "Continue without matching all UPN suffixes to verified domains."

Most people panic here. "Continue without matching" sounds like you're about to break something critical. Here's what actually happens:

User in AD: sarah.mitchell@aiiam.local
Entra Connect reads this during sync
Suffix aiiam.local doesn't exist in Entra ID (.local isn't routable)
Entra Connect substitutes the default domain: acme.onmicrosoft.com
User syncs to cloud as: sarah.mitchell@acme.onmicrosoft.com

Both UPNs work. On-premises: @aiiam.local. Cloud services: @acme.onmicrosoft.com. Seamless SSO makes it transparent.

⚠️ Critical: Don't panic when you see "Continue without matching all UPN suffixes." Check it and move on. Th is is just saying proceed even though your AD UPN suffixes don’t match verified Entra domains. Microsoft best practise recommends adding a routable domain to AD. This is the CORRECT configuration for hybrid environments with non-routable on-premises domains.

OU Filtering & Source Anchor

Configure sync to include only AIIAM-Users OU. Uncheck everything else. This keeps admin accounts, computer objects, and default containers on-premises.

Source anchor defaults to mS-DS-ConsistencyGuid—don't change it. This immutable identifier permanently links on-premises objects to cloud.

Write-Back Configuration

I enabled password write-back because I wanted to see how it works in practice. This lets users reset their passwords via M365 self-service, and the change automatically syncs back to on-premises AD—genuinely useful for production. I skipped device write-back, group write-back, and user write-back to avoid complexity. Password write-back is low-risk (passwords flow one way: cloud → on-prem during resets). The others? Add them when you have a clear use case

After config, sync starts immediately. First sync takes longer. Subsequent delta syncs every 30 minutes process only changes.

Entra Connect sync scheduler showing 30-minute delta sync intervals

The 30-minute interval means AD changes appear in Entra ID within half an hour. For testing: Start-ADSyncSyncCycle -PolicyType Delta.

Verification: Confirming Hybrid Identity

After initial sync (about 30 minutes), check Entra ID portal with filter: On-premises sync enabled == Yes

Entra ID portal showing 1,158 users with on-premises sync enabled

Exactly 1,158 users—every AD import now exists in Entra ID. Click any user to see hybrid metadata:

Aaliyah Campbell's profile showing full hybrid identity attributes and sync details

Job Information (synced from AD):

Job title: Junior Software Engineer
Department: Engineering
Office location: London, UK

On-premises Sync Metadata (hybrid identity fields):

On-premises sync enabled: Yes
On-premises last sync date time: 13 Mar 2026, 21:28
On-premises distinguished name: CN=Aaliyah Campbell,OU=AIIAM-Users,DC=aiiam,DC=local
On-premises immutable ID: A+NNCUrXmEKcpV8o3zqjjA== (Base64-encoded mS-DS-ConsistencyGuid)
On-premises SAM account name: aaliyah.campbell
On-premises user principal name: aaliyah.campbell@aiiam.local
On-premises domain name: aiiam.local

The distinguished name confirms the OU structure synchronized correctly. The immutable ID links this cloud object permanently to the on-premises AD account—mess with this and you break the sync relationship. The dual UPN setup is right there: one for on-premises (@aiiam.local), one for cloud (@acem.onmicrosoft.com).

This metadata saves you when auth breaks at 2 AM. User can't log in? Check these fields first. They'll tell you immediately if sync failed, if the UPN got mangled, or if you're chasing a completely different problem.

Testing Dual UPN Authentication

Both UPNs work:

aaliyah.campbell@aiiam.local for domain-joined systems
aaliyah.campbell@acme.onmicrosoft.com for M365, Azure portal, and Entra ID apps

Seamless SSO means domain users authenticate automatically to cloud services. No credential re-entry. The UPN transformation is invisible—they just log in.

Key Learnings from Building at Scale

UPN mapping is counterintuitive but works perfectly. That warning about unmatched UPN suffixes? It's technically accurate but designed to terrify you. Microsoft's UI team made that checkbox sound like you're bypassing a critical safety check. You're not. "Continue without matching" isn't a workaround—it's literally the correct configuration for every hybrid environment with non-routable on-premises domains. Microsoft recommends you add a routable domain to avoid split identity problem.

Persistent disks are transformational. First build: 3 hours manual setup. Terraform deployment: 8 minutes. Persistent disk strategy: destroy compute to save costs, rebuild in 10 minutes when needed. For intermittent labs, this is game-changing.

Department fields matter. Seemed optional until I thought about conditional access. Need MFA for Finance users accessing sensitive apps? Department field makes that policy trivial.

Scale reveals hidden issues. With 5 test users, you don't notice that your import script has zero progress indicators. At 1,000 users, watching a silent PowerShell window for 8 minutes wondering if it crashed becomes maddening. You also discover fun things like LDAP query optimization, why bulk operations matter, and how network latency to your domain controller adds up when you're creating users one at a time.

Cost optimization needs planning. Standard_D2s_v3 running 24/7: £90/month. Auto-shutdown + manual startup: £5/month. Include the shutdown schedule in your Terraform config—not as an afterthought when you open your Azure bill and wonder why you're funding Microsoft's next datacenter expansion.

JSON transformation between systems requires attention. Entra ID's Graph API format differs from what New-ADUser expects. Job title maps to title not jobTitle. Office location maps to physicalDeliveryOfficeName not officeLocation. Small mismatches cause silent failures.

Security Audit: Lab vs. Production Trade-offs

Let's be clear: this deployment would get you fired in production.

Domain controller with a public IP? RDP open to the entire internet? No MFA? Static passwords committed to version control? Any competent security team would shut this down before it hit production.

And that's fine. This is a lab, not a production environment. But let's be honest about exactly what corners we're cutting and why they'd be catastrophic in the real world.

Security Measures We Implemented

Infrastructure:

Managed Identity for blob access (ended up using SAS token)
Time-limited SAS tokens (1-hour expiry)
Private blob storage
Network Security Group rules
Auto-shutdown to reduce attack surface

Identity:

Password Hash Sync (more resilient than pass-through)
Service account least privilege
OU filtering (admin accounts stay on-premises)
Immutable ID anchoring

Security Concerns We Deliberately Ignored

Network Exposure:

RDP open to 0.0.0.0/0: Production should restrict RDP to known IP ranges or use Azure Bastion
Public IP on domain controller: Real deployments use site-to-site VPN or ExpressRoute
No network segmentation: Production needs separate subnets for DCs, apps, and management

Authentication & Access:

No MFA enforcement: Production Entra ID requires MFA for admins minimum, ideally all users
Static passwords in Terraform: Sensitive values should use Azure Key Vault
No conditional access policies: Production needs location-based, device compliance, and risk-based policies
No Privileged Identity Management: Admin access should be just-in-time, not permanent
UPN Transformation: One of the most common root causes of Microsoft 365 authentication incidents during hybrid migrations is keeping .local UPNs instead of aligning them before sync with Microsoft Entra Connect.

Monitoring & Compliance:

No audit logging: Production needs Azure Monitor, Log Analytics, and SIEM integration
No alerts on suspicious activity: Failed auth, unusual locations, privilege escalation should trigger alerts
No backup strategy: Domain controller state should be backed up
No disaster recovery plan: Production needs documented DR procedures and tested failover

Compliance & Governance:

No encryption at rest: Production should enforce Azure Disk Encryption
No data residency controls: Compliance may mandate specific Azure regions
No change management: Production changes need approval workflows, not direct terraform apply

Why This Is Acceptable for Labs

Labs prioritize demonstration/learning and cost over defence-in-depth. RDP from anywhere lets you connect without VPN complexity. Static passwords simplify Terraform demos. No MFA reduces testing friction.

The goal is understanding how hybrid identity works, not building a production fortress. You're experimenting, breaking things, fixing them. That's harder when every action needs MFA approval and change management tickets.

But: Understanding what you're skipping is critical. Every ignored control is a production requirement. The transition from lab to production isn't scaling up—it's hardening security.

Making This Safer

How would you harden this?

Network: Replace NSG 0.0.0.0/0 with specific IPs, deploy Azure Bastion, implement Azure Firewall

Identity: Enable MFA, implement conditional access, configure PAWs, use Identity Protection

Monitoring: Stream logs to Sentinel, configure anomaly alerts, enable Cloud App Security

You can progressively add these controls. Each layer teaches you something.

What else would you add? Drop your hardening recommendations in the comments. Someone always thinks of the control you missed.

What's Next:

We've built the foundation: AD infrastructure, 1,158 users imported, hybrid sync to Entra ID. These identities authenticate seamlessly across on-premises and cloud resources.

Next part adds Conditional Access and security monitoring: Conditional Access based on location, Azure Event Hub streaming AD sign-in events, Stream Analytics for anomaly detection. The 1,158-user dataset provides sufficient volume for meaningful security telemetry.

The identity foundation is in place. Now we monitor and detect threats.

Questions about hybrid identity at scale? Drop them in the comments.

Cost-Effective IAM Lab Infrastructure for Enterprise-Scale Testing

Christian — Thu, 12 Mar 2026 12:01:17 +0000

Build a realistic Identity & Access Management lab with 1,606 AI-generated employees, multi-cloud infrastructure, and Terraform teardown strategies that keep costs under $1."

Most IAM tutorials use toy datasets—10 users, simplified scenarios, no real infrastructure.
That's fine for learning basics, but useless for testing ML detection systems at production scale.

The problem: Machine learning needs realistic data volumes. A single attack among 10 users
represents 10% of your dataset. Among 1,606 users generating 31,644 events, 69 attacks
represent 0.218%—an enterprise-realistic attack rate.

What I built:

1,606 AI-generated employees with realistic organizational structure
45 security groups (departments, seniority, functional roles)
Behavioral metadata (devices, work patterns, VPN usage)
Multi-cloud data pipeline (Azure Blob → Neo4j → Entra ID)
Total cost: $0.21 using Terraform teardown strategy

This foundation supports ML training, attack simulation, and behavioral analytics—all at
enterprise scale without enterprise costs.By the end, you'll have infrastructure that supports realistic attack simulation, graph-based privilege analysis, and behavioral anomaly detection.

What You'll Build (Step-by-Step Roadmap)

Here's our implementation plan:

Step 1: Design Terraform infrastructure for teardown efficiency
Step 2: Generate 1,606 realistic employees using Gemini API
Step 3: Create realistic behavioral attributes (not just names)
Step 4: Deploy multi-cloud data pipeline (Azure Blob, Neo4j, Entra ID)
Step 4: Cost optimization and actual spend analysis

Each step builds on the previous, creating a complete IAM lab environment suitable for ML training, attack simulation, and detection validation.

Step 1: Design Terraform Infrastructure for Teardown Efficiency

The key to keeping costs under $1 is aggressive teardown. Cloud resources cost money every hour they exist. My strategy: deploy infrastructure only when needed, destroy it immediately after data upload, and rely on Azure Blob Storage (pennies per month) for persistence.

Here's the complete Terraform configuration:

# terraform/main.tf
resource "azurerm_resource_group" "identity_lab" {
  name     = "rg-ai-iam-identity-lab"
  location = "uksouth"

  tags = {
    Project     = "AI-IAM-Engineering"
    Environment = "Demo"
    ManagedBy   = "Terraform"
  }
}

resource "azurerm_storage_account" "data_lake" {
  name                     = "${var.prefix}datalake${random_string.unique_suffix.result}"
  resource_group_name      = azurerm_resource_group.identity_lab.name
  location                 = azurerm_resource_group.identity_lab.location
  account_tier             = "Standard"
  account_replication_type = "LRS"  # Cheapest option
  account_kind             = "StorageV2"
  min_tls_version          = "TLS1_2"
  access_tier              = "Hot"
}

resource "azurerm_storage_container" "synthetic_identities" {
  name                  = "synthetic-identities"
  storage_account_name  = azurerm_storage_account.data_lake.name
  container_access_type = "private"
}

resource "azurerm_virtual_network" "identity_lab" {
  name                = "${var.prefix}-vnet"
  location            = azurerm_resource_group.identity_lab.location
  resource_group_name = azurerm_resource_group.identity_lab.name
  address_space       = ["10.1.0.0/16"]
}

Why this approach matters:

The critical Terraform configuration is the prevent_deletion_if_contains_resources = false flag in the AzureRM provider. This allows terraform destroy to clean up everything in one command, even if resources remain. No orphaned resources = no surprise bills.

Deployment workflow:

terraform init
terraform apply   # Deploy infrastructure
# ... upload data to blob storage ...
terraform destroy # Tear down everything except blob storage

Storage account remains (costs ~$0.20/month), VNet gets destroyed (saves ~$5/month). Data persists in blob storage for future use.

Results: Infrastructure deploys in 2 minutes, destroys in 1 minute. Storage costs $0.20/month ongoing. VNet and compute resources only exist during active testing.

Step 2: Generate 1,606 Realistic Employees Using Gemini API

Realistic identities require diverse names, proper job titles, organizational hierarchy, and believable security group assignments. I used Gemini 2.0 Flash (free tier) to generate all 1,606 employees through structured prompting.

Gemini generates realistic names, but across 161 API calls, duplicates emerge.
My solution: track all generated names globally and exclude them from future prompts.

How it works:

Generate batch 1 (10 employees) → store names in self.used_names
Generate batch 2 → pass 50 random previously used names to exclude
Repeat for all 161 batches
Result: 100% unique names across 1,606 employees

Without this, you'd get 20-30 duplicate "John Smith" entries that break Entra ID imports
(UPNs must be unique).

The challenge: ensuring uniqueness across 161 API calls (10 employees per batch). Gemini can accidentally generate duplicate names across batches. The solution: global name tracking with AI-guided exclusions.

# generate_employees_universal.py (core logic)
import google.generativeai as genai
import json

BATCH_SIZE = 10
TENANT_DOMAIN = "laplace90210gmail.onmicrosoft.com"

class EntraIDEmployeeGenerator:
    def __init__(self, target_count, tenant_domain):
        self.target_count = target_count
        self.model = genai.GenerativeModel('gemini-2.0-flash')
        self.used_names = set()  # Global uniqueness tracking
        self.used_upns = set()

    def generate_prompt(self, batch_num, employees_in_batch):
        """Generate prompt with anti-duplicate instructions"""
        name_exclusions = ""
        if len(self.used_names) > 0:
            sample_names = list(self.used_names)[:50]
            name_exclusions = f"\nAVOID THESE NAMES: {', '.join(sample_names)}"

        prompt = f"""Generate {employees_in_batch} realistic UK employees for ACME Corporation.

CRITICAL: Each employee must have a COMPLETELY UNIQUE name.
- Mix British, Indian, African, Chinese, Middle Eastern, European names
- Use varied surnames: Smith, Patel, Khan, O'Connor, Chen, etc.
{name_exclusions}

Requirements:
1. Diverse UK names reflecting modern Britain
2. Realistic job titles matching seniority distribution
3. UK cities: London, Manchester, Birmingham, Edinburgh, Leeds, Bristol
4. 100% MFA enabled
5. Only Executives/VPs get admin access

Return ONLY JSON array with exact structure..."""

        return prompt

Why this approach works:

Traditional data generation tools create bland, unrealistic identities. Gemini understands context: "Senior Security Engineer" gets appropriate security groups, "Junior Engineer" doesn't get admin access, VPs get E5 licenses while juniors get E3.

Distribution achieved:

Departments: Engineering (40%), Security (15%), Operations (20%), Finance (10%), People (10%), Executive (5%)
Seniority: Executive (0.5%), VP (0.5%), Director (2%), Manager (7%), Senior (20%), Mid (40%), Junior (30%)
Security groups: 45 total (6 departments + 7 seniority levels + 32 functional groups)

API efficiency:

Total API calls: 161 (1,606 ÷ 10 per batch)
Rate limiting: 4 seconds between calls
Total generation time: ~11 minutes
Cost: $0.00 (Gemini free tier)

Results: 1,606 unique employees with realistic organizational structure, ready for Entra ID import. File size: 1.1 MB (organization_1606_entra.json).

Step 3: Creating Realistic Behavioral Attributes

It's not enough to generate names and job titles. For realistic IAM testing,
you need behavioral patterns that mirror real organizations.

What I added to each employee:

Consistent devices:
- Each employee assigned 1 primary device (OS + browser)
- 95% of logins use primary device, 5% use secondary
- Executives more likely to use mobile (iOS/Safari)
Work pattern metadata:
- Work hours by seniority (Executives: 7am-8pm, Juniors: 9am-5pm)
- Weekend work probability (Executives: 40%, Juniors: 2%)
- Location consistency (London-based employees rarely VPN from Manchester)
VPN usage patterns:
- 80% of employees in VPN-Users group
- VPN users get private IPs (10.x.x.x) 60% of the time
- Non-VPN users always get public IPs mapped to office locations
Group membership logic:
- Everyone in their department group
- Seniority-based groups (Junior-Level, Senior-Level, etc.)
- Functional groups (MFA-Enabled: 100%, Admin-Access: 3%)
- VIP users (5+ groups) represent 0.5% of population

Why this matters:

When you eventually test ML detection systems, these patterns are what
the models learn. Random data = models can't distinguish normal from abnormal.
Realistic patterns = models can identify true anomalies.

Code example:

def assign_device(seniority):
    """Assign realistic device based on seniority"""
    if seniority in ['Executive', 'VP']:
        # Executives more likely to use mobile
        if random.random() < 0.3:
            return {'os': 'iOS', 'browser': 'Safari 17'}

    # Most employees use desktop
    return {
        'os': random.choice(['Windows 11', 'macOS']),
        'browser': random.choice(['Chrome 120', 'Edge 120', 'Firefox 121'])
    }

Results:

Device consistency: 95% (matches real employee behavior)
Weekend work distribution: Realistic by seniority
VPN usage: 80% of employees (typical for remote-hybrid orgs)
VIP users: 8 employees with 5+ group memberships

Step 4: Deploy Multi-Cloud Data Pipeline (Azure Blob, Neo4j, Entra ID)

Generated identities need to flow through three systems:

Azure Blob Storage – Long-term persistence (cheap)
Neo4j Graph Database – Privilege escalation path analysis
Microsoft Entra ID – Real identity provider for authentication testing

Each system serves a different purpose. Blob storage is the source of truth. Neo4j enables graph queries like "find all privilege escalation paths from junior engineers to admin access." Entra ID provides real OAuth tokens for testing authentication flows.

Azure Blob Upload:

# upload_to_blob.py
from azure.storage.blob import BlobServiceClient

class DataLakeUploader:
    def __init__(self, connection_string):
        self.blob_service_client = BlobServiceClient.from_connection_string(
            connection_string
        )

    def upload_file(self, local_file, blob_name=None):
        blob_client = self.blob_service_client.get_blob_client(
            container="synthetic-identities",
            blob=blob_name or os.path.basename(local_file)
        )

        with open(local_file, 'rb') as data:
            blob_client.upload_blob(data, overwrite=True)

        return blob_client.url

Neo4j Graph Load:

# load_to_neo4j.py (simplified)
from neo4j import GraphDatabase

def load_organization(driver, employees):
    with driver.session() as session:
        # Create employee nodes
        for emp in employees:
            session.run("""
                CREATE (e:Employee {
                    employee_id: $id,
                    name: $name,
                    department: $dept,
                    seniority: $seniority,
                    admin_access: $admin
                })
            """, id=emp['employee_id'],
                 name=emp['displayName'],
                 dept=emp['department'],
                 seniority=emp['seniority'],
                 admin=emp.get('admin_access', False))

        # Create group relationships
        for emp in employees:
            for group in emp['groups']:
                session.run("""
                    MATCH (e:Employee {employee_id: $id})
                    MERGE (g:Group {name: $group})
                    CREATE (e)-[:MEMBER_OF]->(g)
                """, id=emp['employee_id'], group=group)

Why Neo4j matters:

Graph databases excel at relationship queries. Finding privilege escalation paths in SQL requires recursive CTEs and performs poorly. In Neo4j:

// Find paths from junior employees to admin access
MATCH path = (junior:Employee {seniority: 'Junior'})-[:MEMBER_OF*1..3]->(admin:Group)
WHERE admin.name CONTAINS 'Admin'
RETURN path

This query runs in milliseconds and reveals 43 potential privilege escalation paths invisible to traditional analytics.

Results:

Azure Blob: 2 files uploaded (organization + groups), 1.15 MB total
Neo4j: 1,606 Employee nodes, 45 Group nodes, 6,424 MEMBER_OF relationships
Entra ID: (Optional) Real identity provider available for OAuth testing

Step 5: Cost Optimization and Actual Spend Analysis

The complete infrastructure ran for 2 weeks during development. Here's the actual cost breakdown:

Azure Costs:

Storage account (blob): $0.16
Azure total: $0.21

Other Costs:

Gemini API (161 calls): $0.00 (free tier)
Neo4j Aura (free tier): $0.00
Non-Azure total: $0.00

Total project cost: $0.21 (rounding up to $0.21 for safety margin)

Cost optimization strategies that worked:

Terraform teardown immediately after uploads – VNet costs $5/month if left running. Destroyed after 3 days = $0.50 saved.
Blob storage only – After initial upload, only blob storage remains. 1.15 MB costs $0.02/month.
Gemini free tier – 1,500 free requests/day. 161 batches easily fits within free tier.
Neo4j Aura free tier – 200k nodes/1M relationships included free. 1,606 employees well under limit.
UK South region – Cheapest Azure region in Europe (vs. West Europe).

What $0.21 Buys You vs. Commercial Alternatives

This Lab ($0.21):

1,606 employees, 45 groups, 30 days behavioral data
Multi-cloud infrastructure (Azure + Neo4j + Entra ID)
Full control over data generation and attack scenarios
Scales to 10,000+ users by changing one variable

Commercial IAM Training Labs:

Pluralsight/Cloud Academy IAM courses: $29-49/month subscription
Pre-built datasets (50-100 users max)
No customization, no attack injection
No infrastructure provisioning practice

Azure Training Environments (without teardown):

Running VNet + VM 24/7: ~$150/month
Most tutorials ignore cost optimization entirely
Students rack up $500+ bills learning "free" cloud skills

Terraform teardown reduced my cost by 99.3%.

What costs would look like without optimization:

VNet running 30 days: $5.00
Premium blob storage: $2.50
Neo4j paid tier: $65/month
Unoptimized cost: ~$72/month

Teardown strategy reduced cost by 99.3%.

Conclusion: What You Built and What's Next

You now have a production-ready IAM lab with 1,606 AI-generated employees, 45 security groups, and multi-cloud infrastructure connecting Azure, Neo4j, and Entra ID. Total cost: $0.21 for initial deployment.

This foundation supports realistic attack simulation (covered in my next post), ML-based anomaly detection, graph-based privilege escalation analysis, and behavioral analytics. The data is realistic enough that detection systems trained here translate to production environments.

What this unlocks:

Inject realistic attacks (impossible travel, compromised accounts, credential stuffing)
Train ML models on 30+ days of behavioral login patterns
Analyze privilege escalation paths through Neo4j graph queries
Test detection systems against enterprise-scale data volumes

The infrastructure scales beyond this initial deployment. Need 10,000 users? Change one variable. Need 90 days of login history? Adjust the event generator. The teardown strategy keeps costs minimal regardless of scale.

This foundation is ready for behavioral simulation, attack injection, and ML
detection testing.* I'll explore those areas in future posts as I continue
building on this lab

Code repository: Available on request
Questions? Drop them in the comments.