Advanced ⏱ 120 min 📋 12 Steps

Integrate MDI with Sentinel & Automate Response

Connect Microsoft Defender for Identity alerts to Microsoft Sentinel, create identity-focused analytics rules, build automated playbooks that disable compromised accounts and notify the SOC, deploy identity threat workbooks, and establish an end-to-end automated response workflow for identity-based attacks.

📋 Overview

About This Lab

This lab connects Microsoft Defender for Identity (MDI) with Microsoft Sentinel to create a unified identity threat detection and automated response pipeline. You will ingest MDI alerts into Sentinel, build custom analytics rules that detect credential theft, lateral movement, and privilege escalation patterns, create Logic App playbooks that automatically disable compromised accounts and send Teams notifications, and deploy Sentinel workbooks that give your SOC real-time visibility into identity threats across on-premises Active Directory and cloud identities.

🏢 Enterprise Use Case

A financial services company with 15,000 employees and a hybrid Active Directory environment detects an average of 40 identity-related alerts per day from MDI. Their 6-person SOC manually triages each alert in the Defender XDR portal and copies findings to their Sentinel workspace for correlation. Mean time to contain a compromised account is 4 hours. The CISO wants to reduce this to under 15 minutes by automating the detection-to-response pipeline: MDI detects the threat, Sentinel correlates and enriches the alert, a playbook automatically disables the compromised account, and the SOC is notified via Teams. all within minutes of the initial detection.

🎯 What You Will Learn

  1. Connect the Microsoft Defender XDR data connector to ingest MDI alerts into Sentinel
  2. Explore MDI data tables in Log Analytics (IdentityLogonEvents, IdentityDirectoryEvents, IdentityQueryEvents)
  3. Create custom analytics rules for identity-specific threat patterns
  4. Build a Logic App playbook that automatically disables compromised user accounts
  5. Create automation rules that trigger playbooks on identity alerts
  6. Deploy a Sentinel workbook for identity threat monitoring dashboards
  7. Correlate MDI alerts with Entra ID sign-in data for comprehensive identity investigation
  8. Implement a tiered response workflow with human-in-the-loop for high-impact actions
  9. Test the end-to-end pipeline from detection to automated response

🔑 Why This Matters

Identity is the new perimeter. 80% of breaches involve compromised credentials according to the Verizon DBIR. Manual response to identity threats is too slow; attackers can escalate from initial compromise to domain admin in under 2 hours using tools like Mimikatz, Rubeus, and Impacket. Automating the response pipeline ensures compromised accounts are disabled within minutes, not hours. Integration with Sentinel adds cross-signal correlation that MDI alone cannot provide. combining identity events with endpoint, email, and cloud data for a complete attack picture.

⚙️ Prerequisites

  • Completed Labs 01–03. MDI sensors deployed, detections configured, attack path investigation completed
  • Microsoft Sentinel workspace. deployed and active (see Sentinel Lab 01)
  • Microsoft Sentinel Contributor role. to create analytics rules, automation rules, and playbooks
  • Logic App Contributor role. to create and manage automation playbooks
  • Microsoft Entra ID P2 license. for risky user APIs and Conditional Access integration
  • An Azure AD / Entra ID test account. for safely testing account disable automation
💡 Pro Tip: Use a dedicated test account for playbook testing. Never test account-disable automation against production admin accounts. Create a test user like mdi-test-user@contoso.com for safe validation.

Step 1 · Connect MDI Data to Sentinel

MDI alerts flow into Sentinel through the Microsoft Defender XDR data connector. This connector ingests incidents, alerts, and advanced hunting data from all Defender products including MDI.

Portal Instructions

  1. Navigate to Microsoft Sentinel > Data connectors
  2. Search for Microsoft Defender XDR
  3. Click Open connector page
  4. Under Connect incidents & alerts, click Connect
  5. Under Connect events, enable the identity tables:
    • IdentityLogonEvents. authentication events (NTLM, Kerberos, LDAP)
    • IdentityDirectoryEvents. AD object changes (password resets, group changes)
    • IdentityQueryEvents. LDAP and DNS queries (reconnaissance detection)
  6. Click Apply Changes
  7. Wait 5–10 minutes, then verify data is flowing by running a test query

Verify Data Ingestion

// WHAT: Verify that MDI telemetry is flowing into the Sentinel Log Analytics workspace
// WHY:  After connecting the Defender XDR data connector, data may take 5-10 minutes to appear.
//       These three queries confirm each identity table is receiving events.
// OUTPUT: Event counts grouped by application/action type. Empty results = data not flowing.

// Query 1: Verify authentication events from MDI sensors
// IdentityLogonEvents captures all Kerberos, NTLM, and LDAP authentication events
// Application = "Active Directory" for on-prem AD auth; LogonType distinguishes interactive/network
IdentityLogonEvents
| where TimeGenerated > ago(1h)
| summarize Count=count() by Application, LogonType
| order by Count desc

// Query 2: Verify directory change events (password resets, group changes, object modifications)
// IdentityDirectoryEvents captures AD object mutations detected by MDI sensors
IdentityDirectoryEvents
| where TimeGenerated > ago(24h)
| summarize Count=count() by ActionType
| order by Count desc

// Query 3: Verify MDI alerts are arriving via the SecurityAlert table
// ProviderName "Azure Advanced Threat Protection" = MDI alerts (legacy name still used in Sentinel)
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProviderName == "Azure Advanced Threat Protection"
| summarize Count=count() by AlertName, AlertSeverity
| order by Count desc
💡 Pro Tip: If the IdentityLogonEvents table returns no results, check that your MDI sensors are healthy in the Defender XDR > Settings > Identities page. Unhealthy sensors stop sending data.

Step 2 · Explore MDI Data Tables in Log Analytics

Understand the MDI data tables before building analytics rules. Each table provides different identity signal types that you will use for detection and correlation.

Key Identity Hunting Queries

// WHAT: Four key identity hunting queries for proactive threat detection in Sentinel
// WHY:  These queries surface threats that MDI's built-in detections may not catch individually.
//       Use them as Sentinel analytics rules or ad-hoc hunting queries.

// Query 1: Detect brute force via failed Kerberos authentication
// THRESHOLD: >10 failed attempts from a single account suggests credential guessing/spraying
// FailedAttempts and DistinctDCs help distinguish brute force from a single mistyped password
IdentityLogonEvents
| where TimeGenerated > ago(24h)
| where LogonType == "Kerberos" and ActionType == "LogonFailed"
| summarize FailedAttempts=count(), DistinctDCs=dcount(DestinationDeviceName) 
    by AccountName, AccountDomain
| where FailedAttempts > 10
| order by FailedAttempts desc

// Query 2: Detect suspicious LDAP queries targeting sensitive AD attributes
// WHY: Attackers enumerate admincount (find admins), serviceprincipalname (Kerberoasting targets),
//      and msds-allowedtodelegateto (delegation abuse targets) during reconnaissance
// MITRE ATT&CK: T1087.002 (Account Discovery: Domain Account)
IdentityQueryEvents
| where TimeGenerated > ago(24h)
| where ActionType == "LDAP query"
| where QueryTarget has_any ("admincount", "serviceprincipalname", "msds-allowedtodelegateto")
| project TimeGenerated, AccountName, DeviceName, QueryType, QueryTarget
| order by TimeGenerated desc

// Query 3: Detect modifications to sensitive AD groups (privilege escalation)
// WHY: Adding accounts to Domain Admins or Enterprise Admins is the most direct privilege
//      escalation path. This should be rare and always authorized via change management.
IdentityDirectoryEvents
| where TimeGenerated > ago(7d)
| where ActionType == "Group Membership changed"
| where TargetAccountDisplayName has_any ("Domain Admins", "Enterprise Admins", 
    "Schema Admins", "Account Operators")
| project TimeGenerated, AccountName, ActionType, TargetAccountDisplayName,
    AdditionalFields
| order by TimeGenerated desc

// Query 4: Detect Pass-the-Hash via excessive NTLM authentication
// WHY: High NTLM volume from a single account indicates PtH lateral movement - legitimate
//      environments use Kerberos. THRESHOLD: >20 NTLM logons from one account in 24h
IdentityLogonEvents
| where TimeGenerated > ago(24h)
| where LogonType == "NTLM" and Protocol == "Ntlm"
| where ActionType == "LogonSuccess"
| summarize NtlmLogons=count(), DistinctDevices=dcount(DeviceName) 
    by AccountName
| where NtlmLogons > 20
| order by NtlmLogons desc
⚠️ Important: The IdentityQueryEvents table can be very high-volume. Use targeted filters (ActionType, QueryTarget) to avoid scanning millions of benign LDAP queries. Always include time filters in your queries.

Step 3 · Create Identity Analytics Rules

Create custom Sentinel analytics rules that detect identity-specific attack patterns. These rules complement MDI’s built-in detections with cross-signal correlation.

Rule 1: Credential Theft Followed by Lateral Movement

  1. Navigate to Microsoft Sentinel > Analytics > Create > Scheduled query rule
  2. Name: MDI. Credential Theft with Lateral Movement
  3. Severity: High
  4. MITRE ATT&CK: T1003 (OS Credential Dumping), T1021 (Remote Services)
  5. Set the query:
// WHAT: Sentinel analytics rule - Detect credential theft followed by lateral movement within 1 hour
// WHY:  This correlation rule catches the most dangerous identity attack pattern: compromised
//       credentials being immediately used to move laterally. Neither signal alone is definitive,
//       but together they indicate an active break-in requiring immediate containment.
// MITRE ATT&CK: T1003 (OS Credential Dumping) + T1021 (Remote Services)
// FREQUENCY: Run every 15 minutes, looking back 1 hour for real-time detection
// THRESHOLD: Any match (>0 results) triggers an incident - this is a high-fidelity signal
// OUTPUT: The account that was compromised, the credential theft alert, and the device they moved to

// Step 1: Find MDI alerts indicating credential theft in the last hour
let credential_alerts = SecurityAlert
| where TimeGenerated > ago(1h)
| where ProviderName == "Azure Advanced Threat Protection"
| where AlertName has_any ("Suspected credential theft", "Suspected NTLM relay",
    "Suspected overpass-the-hash", "Suspected identity theft")
| extend AccountName = tostring(parse_json(ExtendedProperties).["User Account"])
| project CredentialAlertTime=TimeGenerated, AlertName, AccountName, AlertSeverity;
// Step 2: Find successful lateral movement logons (RDP or network access to servers)
let lateral_movement = IdentityLogonEvents
| where TimeGenerated > ago(1h)
| where LogonType in ("RemoteInteractive", "Network")  // RDP and SMB/WMI access
| where ActionType == "LogonSuccess"
| project LateralTime=TimeGenerated, AccountName, DeviceName, LogonType;
// Step 3: Correlate - same account appears in both credential theft AND lateral movement within 1 hour
credential_alerts
| join kind=inner lateral_movement on AccountName
| where LateralTime between (CredentialAlertTime .. (CredentialAlertTime + 1h))
| project CredentialAlertTime, AlertName, AccountName, LateralTime, DeviceName, LogonType
  1. Run frequency: Every 15 minutes
  2. Lookup data from: Last 1 hour
  3. Alert threshold: Greater than 0
  4. Entity mapping: map AccountName to Account, DeviceName to Host
  5. Click Create

Rule 2: Sensitive Group Change by Non-Admin

// WHAT: Sentinel analytics rule - Detect non-admin accounts modifying sensitive AD groups
// WHY:  Only approved admin accounts should modify Domain Admins, Enterprise Admins, etc.
//       A non-admin account making these changes indicates compromised credentials or insider threat.
// MITRE ATT&CK: T1098 (Account Manipulation), T1078 (Valid Accounts)
// FREQUENCY: Every 15 minutes | THRESHOLD: Any match = High severity incident
// OUTPUT: The unauthorized account, which group was modified, and the target DC

let admin_accounts = dynamic(["admin", "svc-admin", "t2-admin"]);  // Whitelist of authorized admins
IdentityDirectoryEvents
| where TimeGenerated > ago(15m)
| where ActionType == "Group Membership changed"
| where TargetAccountDisplayName has_any ("Domain Admins", "Enterprise Admins",
    "Schema Admins", "Backup Operators", "Account Operators")
| where not(AccountName has_any (admin_accounts))   // Exclude known authorized admin accounts
| project TimeGenerated, AccountName, ActionType, TargetAccountDisplayName,
    DestinationDeviceName, AdditionalFields
💡 Pro Tip: Start analytics rules in Alert mode, not Incident mode. Once you’ve validated the rule generates accurate alerts with minimal false positives (monitor for 1–2 weeks), switch to Incident mode to create Sentinel incidents automatically.

Step 4 · Build an Account Disable Playbook

Create a Logic App playbook that automatically disables a compromised user account in Entra ID when a high-severity identity alert fires.

Create the Logic App

  1. Navigate to Microsoft Sentinel > Automation > Playbook templates
  2. Search for Disable user in Entra ID
  3. Click Create playbook
  4. Name: Playbook-MDI-DisableCompromisedUser
  5. Resource group: your Sentinel resource group
  6. Enable system-assigned managed identity
  7. Click Create and continue to designer

Azure CLI: Create from Scratch

# Create the resource group for playbooks
az group create --name rg-sentinel-playbooks --location eastus

# Deploy a Logic App with managed identity
az logic workflow create \
  --resource-group rg-sentinel-playbooks \
  --name Playbook-MDI-DisableCompromisedUser \
  --definition @playbook-definition.json \
  --mi-system-assigned

# Grant the Logic App's managed identity permission to disable users
LOGIC_APP_PRINCIPAL=$(az logic workflow show \
  --resource-group rg-sentinel-playbooks \
  --name Playbook-MDI-DisableCompromisedUser \
  --query identity.principalId -o tsv)

# Assign User.ReadWrite.All via Microsoft Graph app role
az ad app permission grant \
  --id $LOGIC_APP_PRINCIPAL \
  --api 00000003-0000-0000-c000-000000000000 \
  --scope User.ReadWrite.All

Logic App Flow Design

# Playbook Logic Flow
#
# 1. TRIGGER: Microsoft Sentinel incident
#    ─ Fires when an incident is created with identity entities
#
# 2. GET ENTITIES: Extract account entities from the incident
#    ─ Parse Account name and UPN from incident entities
#
# 3. CONDITION: Check if the alert severity is High or Critical
#    ─ Only auto-disable for confirmed high-severity threats
#
# 4. ACTION (if High/Critical):
#    a. Disable the user account in Entra ID
#       ─ PATCH https://graph.microsoft.com/v1.0/users/{id}
#       ─ Body: {"accountEnabled": false}
#    b. Revoke all refresh tokens
#       ─ POST https://graph.microsoft.com/v1.0/users/{id}/revokeSignInSessions
#    c. Add a comment to the Sentinel incident
#       ─ "Account {UPN} was automatically disabled by playbook"
#    d. Send a Teams notification to the SOC channel
#       ─ Include: user, alert name, severity, incident link
#
# 5. ACTION (if Medium/Low):
#    a. Add a comment recommending manual review
#    b. Send a Teams notification requesting analyst review
⚠️ Important: Add an exclusion list to prevent the playbook from disabling service accounts, break-glass admin accounts, or executive accounts. Disabling a critical service account could cause a larger outage than the original threat.

Step 5 · Build a SOC Notification Playbook

Create a second playbook that sends rich notifications to your SOC Teams channel whenever an identity incident is created.

Teams Notification Playbook

  1. Create a new Logic App: Playbook-MDI-TeamsNotification
  2. Trigger: Microsoft Sentinel incident
  3. Action: Post adaptive card to Teams channel
  4. Configure the adaptive card to include:
    • Incident title and severity
    • Affected user account (from entities)
    • Alert description and MITRE technique
    • Direct link to the Sentinel incident
    • Action buttons: Investigate | Dismiss | Escalate
  5. Set the Teams channel: SOC-Identity-Alerts

PowerShell: Send Test Notification

# Test the Teams webhook directly
$webhookUrl = "https://contoso.webhook.office.com/webhookb2/..."
$card = @{
    "@type"    = "MessageCard"
    "@context" = "http://schema.org/extensions"
    summary    = "MDI Alert: Credential Theft Detected"
    themeColor = "FF0000"
    title      = "🚨 High Severity: Suspected Credential Theft"
    sections   = @(@{
        activityTitle    = "MDI Identity Alert"
        activitySubtitle = "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss UTC')"
        facts = @(
            @{ name = "User"; value = "john.doe@contoso.com" },
            @{ name = "Alert"; value = "Suspected overpass-the-hash attack" },
            @{ name = "Severity"; value = "High" },
            @{ name = "Source DC"; value = "DC01.contoso.com" }
        )
    })
    potentialAction = @(@{
        "@type"  = "OpenUri"
        name     = "Open in Sentinel"
        targets  = @(@{ os = "default"; uri = "https://portal.azure.com/#/sentinel" })
    })
} | ConvertTo-Json -Depth 10

Invoke-RestMethod -Uri $webhookUrl -Method Post -Body $card -ContentType "application/json"

Step 6 · Create Automation Rules

Automation rules connect your analytics rules to your playbooks. They define which incidents trigger which playbooks based on severity, product, and entity type.

Portal Instructions

  1. Navigate to Microsoft Sentinel > Automation > Create > Automation rule
  2. Name: Auto-Disable-Compromised-Identity
  3. Trigger: When incident is created
  4. Conditions:
    • Incident provider equals Microsoft Defender XDR OR Microsoft Sentinel
    • Alert product name contains Azure Advanced Threat Protection
    • Severity is High
  5. Actions:
    • Run playbook: Playbook-MDI-DisableCompromisedUser
    • Run playbook: Playbook-MDI-TeamsNotification
    • Assign owner: SOC-Identity-Team
    • Add tag: auto-response-executed
  6. Order: 1 (runs first)
  7. Click Apply

Create a Second Rule for Medium Severity

  1. Name: Notify-Identity-Alert-Medium
  2. Conditions: Severity is Medium, Alert product contains Azure Advanced Threat Protection
  3. Actions: Run playbook Playbook-MDI-TeamsNotification only (no auto-disable)
  4. This ensures Medium alerts get visibility without automatic containment
💡 Pro Tip: Use a tiered approach: auto-respond to High/Critical (disable account + notify), notify-only for Medium (SOC reviews and decides), and log-only for Low/Informational. This balances speed with accuracy.

Step 7 · Deploy an Identity Threat Workbook

Create a Sentinel workbook that provides real-time identity threat dashboards for your SOC.

Workbook Tiles

// Tile 1: MDI Alert Trend (last 30 days)
SecurityAlert
| where ProviderName == "Azure Advanced Threat Protection"
| where TimeGenerated > ago(30d)
| summarize AlertCount=count() by bin(TimeGenerated, 1d), AlertSeverity
| render timechart

// Tile 2: Top Targeted Users
SecurityAlert
| where ProviderName == "Azure Advanced Threat Protection"
| where TimeGenerated > ago(30d)
| extend User = tostring(parse_json(ExtendedProperties).["User Account"])
| summarize AlertCount=count() by User
| top 10 by AlertCount
| render barchart

// Tile 3: Authentication Anomalies
IdentityLogonEvents
| where TimeGenerated > ago(7d)
| where ActionType == "LogonFailed"
| summarize FailedLogons=count() by AccountName, LogonType
| where FailedLogons > 50
| order by FailedLogons desc

// Tile 4: Sensitive Group Modifications
IdentityDirectoryEvents
| where TimeGenerated > ago(30d)
| where ActionType == "Group Membership changed"
| where TargetAccountDisplayName has_any ("Domain Admins", "Enterprise Admins")
| project TimeGenerated, AccountName, TargetAccountDisplayName, ActionType

// Tile 5: Playbook Execution Summary
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where resource_workflowName_s has "MDI"
| where TimeGenerated > ago(30d)
| summarize Executions=count() by resource_workflowName_s, status_s
| render piechart

Deploy the Workbook

  1. Navigate to Microsoft Sentinel > Workbooks > Add workbook
  2. Click Edit > Advanced Editor
  3. Add each query as a separate tile with appropriate visualisation (timechart, barchart, table)
  4. Add parameter filters: TimeRange, Severity, AccountName
  5. Save as MDI. Identity Threat Dashboard
  6. Pin to your SOC’s shared dashboard

Step 8 · Correlate MDI with Entra ID Sign-In Data

Combine on-premises MDI data with cloud-based Entra ID sign-in logs for full identity investigation coverage.

Cross-Signal Correlation Queries

// WHAT: Cross-signal correlation - Link on-premises credential theft (MDI) with cloud sign-ins (Entra ID)
// WHY:  When an attacker steals credentials on-prem, they often use them to access cloud services.
//       This query finds users who triggered MDI credential theft alerts AND successfully signed into
//       cloud apps afterward - indicating a fully compromised hybrid identity.
//       Neither MDI nor Entra ID alone sees this complete picture; Sentinel correlation is essential.
// TABLES: SecurityAlert (MDI alerts) joined with SigninLogs (Entra ID cloud sign-ins)
// OUTPUT: Cloud sign-in details for compromised users: app accessed, IP, location, risk level
//         Look for: sign-ins from unusual countries, anonymous proxies, or unfamiliar devices

let compromised_users = SecurityAlert
| where ProviderName == "Azure Advanced Threat Protection"
| where AlertSeverity in ("High", "Medium")
| where TimeGenerated > ago(24h)
| extend AccountUPN = tostring(parse_json(ExtendedProperties).["User Account"])
| distinct AccountUPN;
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName in (compromised_users)
| where ResultType == "0"  // ResultType 0 = successful sign-in (attacker got in)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
    LocationDetails, DeviceDetail, RiskLevelDuringSignIn
| order by TimeGenerated desc

// WHAT: Correlate on-prem NTLM activity with Entra ID risky user detections
// WHY:  Users flagged as risky by Entra ID Protection AND using NTLM on-prem = high-confidence
//       compromised identity requiring immediate containment in both environments
let ntlm_users = IdentityLogonEvents
| where TimeGenerated > ago(24h)
| where Protocol == "Ntlm" and ActionType == "LogonSuccess"
| distinct AccountUpn;
AADRiskyUsers
| where RiskLevel in ("high", "medium")
| where UserPrincipalName in (ntlm_users)
| project UserPrincipalName, RiskLevel, RiskState, RiskDetail
💡 Pro Tip: This cross-signal correlation is the real power of Sentinel + MDI. A credential theft on-prem (MDI alert) followed by a cloud sign-in from a new country (Entra ID) is a strong indicator of a fully compromised identity. Neither system alone sees the complete picture.

Step 9 · Test the End-to-End Pipeline

Validate the complete detection-to-response pipeline using a controlled test scenario.

Test Procedure

  1. Use the test account mdi-test-user@contoso.com
  2. Generate a test alert by running a simulated credential harvest (see MDI Lab 02)
  3. Wait for MDI to detect and alert (typically 5–15 minutes)
  4. Verify the alert appears in the Sentinel Incidents queue
  5. Verify automation rule triggers:
    • Check the Automation > Run history tab
    • Verify the disable playbook executed successfully
    • Verify the Teams notification was sent
  6. Verify the test user is disabled in Entra ID: Get-MgUser -UserId mdi-test-user@contoso.com | Select AccountEnabled
  7. Verify the incident has the auto-response-executed tag
  8. Re-enable the test user after validation

Re-enable Test Account

# Re-enable the test account after validation
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Check account status
Get-MgUser -UserId "mdi-test-user@contoso.com" | Select-Object DisplayName, AccountEnabled

# Re-enable the account
Update-MgUser -UserId "mdi-test-user@contoso.com" -AccountEnabled:$true

# Verify it's re-enabled
Get-MgUser -UserId "mdi-test-user@contoso.com" | Select-Object DisplayName, AccountEnabled

Step 10 · Implement Human-in-the-Loop for High-Impact Actions

For VIP accounts and service accounts, add an approval step before auto-disabling. This prevents automation from causing outages for critical business accounts.

Approval Workflow Design

  1. In the Logic App designer, add a Condition step after entity extraction
  2. Check if the user is in a protected accounts list (VIPs, service accounts, break-glass admins)
  3. If protected: send a Teams adaptive card with Approve / Deny buttons, wait for response (timeout: 30 minutes)
  4. If not protected: proceed with automatic disable
  5. If approval times out: escalate to the SOC manager via email and phone call

Protected Accounts List

# Create a Sentinel Watchlist for protected accounts
# Navigate to Sentinel > Watchlists > Create

# Watchlist name: ProtectedIdentities
# Alias: protected_identities
# CSV format:
# UPN,AccountType,Owner,BusinessJustification
# admin@contoso.com,BreakGlass,IT-Security,Emergency access account
# svc-erp@contoso.com,ServiceAccount,ERP-Team,SAP integration service
# ceo@contoso.com,VIP,Executive-Office,CEO account requires manual review

# Use in KQL to check if a user is protected:
let protected = _GetWatchlist('protected_identities') | project UPN;
SecurityAlert
| where ProviderName == "Azure Advanced Threat Protection"
| extend User = tostring(parse_json(ExtendedProperties).["User Account"])
| extend IsProtected = User in (protected)

Step 11 · Monitor Automation Health

Monitor your automation pipeline to ensure playbooks are running successfully and not failing silently.

Monitoring Checklist

  1. Navigate to Sentinel > Automation > Active playbooks. verify all playbooks show Enabled
  2. Check Run history for each playbook. look for failed runs
  3. Navigate to the Logic App in the Azure portal > Run history. click on failed runs to see error details
  4. Set up an Azure Monitor alert for Logic App failures

KQL: Automation Health Dashboard

// Playbook execution summary (last 7 days)
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where TimeGenerated > ago(7d)
| where resource_workflowName_s has "MDI"
| summarize 
    TotalRuns=count(),
    Succeeded=countif(status_s == "Succeeded"),
    Failed=countif(status_s == "Failed")
    by resource_workflowName_s
| extend SuccessRate = round(todouble(Succeeded) / TotalRuns * 100, 1)
| project Playbook=resource_workflowName_s, TotalRuns, Succeeded, Failed, SuccessRate

// Incidents with auto-response tag
SecurityIncident
| where TimeGenerated > ago(30d)
| where Labels has "auto-response-executed"
| summarize Count=count() by bin(TimeGenerated, 1d)
| render timechart

Step 12 · Clean Up & Next Steps

Review the end-to-end pipeline and plan ongoing operations.

What You Accomplished

  1. Detection. MDI sensors detect identity threats on domain controllers
  2. Ingestion. Alerts flow to Sentinel via Defender XDR connector
  3. Correlation. Analytics rules enrich with Entra ID sign-in data
  4. Response. Playbooks auto-disable accounts and notify SOC
  5. Visibility. Workbooks provide real-time identity threat dashboards

Clean Up Lab Resources

# Disable automation rules (if testing)
# Navigate to Sentinel > Automation > disable the test rules

# Re-enable any disabled test accounts
Connect-MgGraph -Scopes "User.ReadWrite.All"
Update-MgUser -UserId "mdi-test-user@contoso.com" -AccountEnabled:$true

# Delete test playbooks (if no longer needed)
az logic workflow delete \
  --resource-group rg-sentinel-playbooks \
  --name Playbook-MDI-DisableCompromisedUser --yes

Next Steps

  • Add playbooks for additional response actions: reset password, revoke MFA, block IP in Conditional Access
  • Create a playbook that escalates to ServiceNow or Jira for incident tracking
  • Integrate with Security Copilot for AI-assisted identity investigation
  • Build Sentinel hunting queries for proactive identity threat hunting
  • Configure Conditional Access policies that automatically respond to risky sign-ins
  • Establish a weekly identity security review: alert trends, playbook success rates, false positive analysis
💡 Pro Tip: Track your key metrics monthly: mean time to contain compromised accounts (target: <15 min), playbook success rate (target: >95%), and false positive rate for auto-disable (target: <5%). These metrics justify continued investment in identity automation.

📚 Documentation Resources

ResourceDescription
MDI in Microsoft Defender XDRIntegration overview and data flow
Microsoft Defender XDR connector for SentinelConnect Defender XDR data including MDI to Sentinel
Automate responses with playbooksBuild Logic App playbooks for automated incident response
Create custom analytics rulesDetect threats with scheduled query rules
Automation rules in SentinelOrchestrate playbook execution and incident management
MDI advanced huntingIdentity-specific KQL tables and hunting scenarios
Sentinel watchlistsManage lookup data like protected account lists
Monitor your data with workbooksCreate custom dashboards for identity threat data
← Previous Lab All Labs →