Microsoft Defender for Identity (MDI) Deployment Guide: Active Directory Threat Detection Without the SOC Complexity
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Active Directory is the identity backbone of most enterprise environments and the most targeted system in domain-based attacks. The attack techniques MDI detects -- Pass-the-Hash, Golden Ticket, DCSync, Kerberoasting, AS-REP Roasting -- appear in almost every post-breach investigation and every red team report. MDI is the fastest way to get behavioral detection for these techniques without building custom SIEM queries from scratch. This guide covers deployment from sensor installation through the highest-value detections to verify.
Create the Directory Services Account and Configure Permissions
MDI requires a low-privilege AD account (or gMSA) to query Active Directory. This account is separate from the sensor service account.
Option 1: Standard user account (simpler)
# Create a dedicated MDI account
New-ADUser -Name 'svc-mdi-reader' `
-SamAccountName 'svc-mdi-reader' `
-UserPrincipalName 'svc-mdi-reader@domain.com' `
-AccountPassword (Read-Host -AsSecureString) `
-PasswordNeverExpires $true `
-Enabled $true
# Do NOT add to any privileged groups -- read-only domain user is sufficient
Option 2: gMSA (recommended)
# Create gMSA for MDI
New-ADServiceAccount -Name 'mdi-svc' `
-DNSHostName 'mdi-svc.domain.com' `
-PrincipalsAllowedToRetrieveManagedPassword 'Domain Controllers'
# Install on each DC
Install-ADServiceAccount mdi-svc
Required permissions for the MDI account:
# Grant read access to the Deleted Objects container
$deletedObjectsDN = 'CN=Deleted Objects,DC=domain,DC=com'
$acl = Get-Acl -Path "AD:\$deletedObjectsDN"
$identity = [System.Security.Principal.NTAccount]'DOMAIN\svc-mdi-reader'
$adRights = [System.DirectoryServices.ActiveDirectoryRights]::GenericRead
$type = [System.Security.AccessControl.AccessControlType]::Allow
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity,$adRights,$type)
$acl.AddAccessRule($ace)
Set-Acl -Path "AD:\$deletedObjectsDN" -AclObject $acl
For SAM-R (lateral movement path mapping), the MDI account also needs to be added to:
Computer Configuration > Security Settings > Local Policies > Security Options
Network access: Restrict clients allowed to make remote calls to SAM: Add the MDI account
Install the MDI Sensor on Domain Controllers
Deploy the sensor on every domain controller, including read-only DCs.
Download the sensor installer:
- In the Microsoft 365 Defender portal, go to Settings > Identities > Sensors
- Download the sensor installer (Azure ATP sensor setup)
- Copy the Access key from the same page -- you need this during installation
Install on each DC:
# Silent installation
.\"Azure ATP Sensor Setup.exe" /quiet AccessKey="<your-access-key>"
# Or run the GUI installer and paste the access key when prompted
The sensor installs as a Windows service (AATPSensor). Verify installation:
Get-Service -Name AATPSensor
# Status should be Running
Get-Service -Name AATPSensorUpdater
# Updater service manages automatic updates
Verify the sensor is connected in the portal: Settings > Identities > Sensors -- each DC should show status: Running
Audit Policy requirements on DCs: MDI requires these audit categories enabled on DCs:
- Audit Account Logon Events: Success, Failure
- Audit Account Management: Success, Failure
- Audit DS Access: Success (specifically Directory Service Access and Changes)
- Audit Logon Events: Success, Failure
- Audit Object Access: Success, Failure
- Audit Policy Change: Success, Failure
- Audit Privilege Use: Success, Failure
Verify via: auditpol /get /category:* on the DC
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Highest-Value Detections to Verify After Deployment
After the sensor is running, verify these specific detections are active -- they cover the most common Active Directory attack techniques:
DCSync detection
MDI detects when a non-DC machine uses MS-DRSR (Directory Replication Service Remote Protocol) to request credential replication. This is how Mimikatz lsadump::dcsync works.
Test in a lab: run mimikatz.exe "lsadump::dcsync /domain:domain.com /user:krbtgt" exit from a non-DC machine -- MDI should generate an alert within 2-3 minutes.
Kerberoasting detection MDI detects bulk Kerberos service ticket requests (TGS-REQ) for accounts with SPNs, which is the Kerberoasting pattern. MDI alert name: Suspected Kerberos SPN reconnaissance
Golden Ticket detection MDI detects anomalous Kerberos tickets with unusual lifetimes, encryption types, or that reference non-existent account attributes. MDI alert name: Forged Kerberos certificate usage and Suspected Golden Ticket usage
Lateral movement path mapping MDI maps lateral movement paths -- chains of compromised credentials that could give an attacker a path to Domain Admin. Review these in: Microsoft 365 Defender > Identity > Lateral movement paths
Reconnaissance detection MDI detects LDAP reconnaissance, DNS enumeration, and SMB session enumeration patterns characteristic of BloodHound/SharpHound runs. MDI alert name: Suspected reconnaissance using LDAP, User and IP address reconnaissance
Integrate MDI Alerts into Microsoft Sentinel or SIEM
MDI alerts appear natively in the Microsoft 365 Defender portal. For SIEM integration:
Microsoft Sentinel (native connector): Sentinel > Data connectors > Microsoft Defender XDR > Connect This brings all MDI alerts, incidents, and entity data into Sentinel as SecurityAlert and SecurityIncident tables.
KQL queries for MDI data in Sentinel:
// MDI alerts from the last 7 days
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == 'Azure Advanced Threat Protection'
| project TimeGenerated, AlertName, AlertSeverity, Entities, Description
| order by TimeGenerated desc
// High severity MDI identity alerts
AlertEvidence
| where TimeGenerated > ago(7d)
| join kind=inner (SecurityAlert | where ProductName has 'Defender for Identity' and AlertSeverity == 'High') on SystemAlertId
| project TimeGenerated, AlertName, EvidenceRole, EntityType, AccountName, HostName
Syslog/CEF integration for non-Sentinel SIEMs: In the MDI portal: Settings > Notifications > Syslog notifications Configure the syslog server address and enable CEF format for your SIEM parser.
The bottom line
MDI deployment order: create the Directory Services account (gMSA preferred), install sensors on all DCs, verify sensors show Running in the portal, check audit policy covers all required categories, then review the lateral movement path map immediately -- it will show the most dangerous credential chains in your environment within hours of deployment. Integrate with Sentinel or your SIEM to route MDI high-severity alerts to your SOC workflow.
Frequently asked questions
Does MDI require changes to domain controller configuration?
Minimal changes. MDI requires the audit policy on DCs to cover specific event categories (most are enabled by default on DCs but a few may need to be added). It also requires the Directory Services account to have specific permissions, and optionally SAM-R permissions for lateral movement path mapping. The sensor itself installs as a service and reads events from the local event log -- it does not require firewall changes on the DC other than outbound HTTPS to the MDI cloud service (*.atp.azure.com on port 443).
How is MDI different from Microsoft Sentinel for Active Directory detection?
MDI is a purpose-built identity threat detection product with 180+ pre-built detections specifically for Active Directory attack patterns. It understands the semantics of Kerberos, NTLM, LDAP, and SAM-R in a way that a generic SIEM rule cannot. Sentinel is a general-purpose SIEM that can ingest MDI alerts and correlate them with other data sources (endpoints, cloud, network). The two complement each other: MDI provides the specialized AD detection capability, Sentinel provides the broader correlation and investigation platform. If you have both, pipe MDI alerts into Sentinel rather than trying to replicate MDI detections in Sentinel KQL.
Can MDI detect Golden Ticket attacks?
Yes, with limitations. MDI detects anomalous characteristics of Kerberos tickets that indicate forgery -- unusual encryption types, ticket lifetimes that exceed domain policy, or tickets referencing account attributes that do not match the current AD state. However, a perfectly crafted Golden Ticket that mimics all expected properties (valid lifetime, correct encryption, matching account attributes) may not trigger all detections. MDI's Golden Ticket detection is one layer; the defense also includes regularly rotating the krbtgt password (twice, with a delay) and monitoring for anomalous ticket usage patterns in authentication logs.
What is the performance impact of the MDI sensor on domain controllers?
Microsoft reports under 2% additional CPU usage and under 10 MB/s additional network bandwidth per DC for typical environments. The sensor reads event log entries in real time and processes LDAP/Kerberos traffic from the network stack. For very high-traffic DCs (supporting tens of thousands of authentications per minute), verify CPU and memory during the first week after deployment. If you see degradation, check the sensor's resource usage in Task Manager and report to Microsoft support -- sensor performance is a known priority and updates are frequent.
Which MDI detections have the highest true positive rate in enterprise environments?
Based on MDI defender community experience, the highest-confidence detections are: Suspected identity theft using Pass-the-Hash (Event code 2017), Suspected DCSync attack (2029), Suspected overpass-the-hash attack (2002), and Malicious request to Data Protection API (2020). These represent direct evidence of credential theft or domain compromise techniques with low false positive rates in domain environments that have auditing properly configured. Reconnaissance-based detections (account enumeration, LDAP scan, SMB enumeration) have higher false positive rates because legitimate tools perform similar queries -- these detections require baselining before treating every alert as malicious.
What is the difference between Microsoft Defender for Identity and Microsoft Defender for Endpoint, and do I need both?
MDI is an identity-focused threat detection tool that ingests Active Directory authentication telemetry (Kerberos, NTLM, LDAP events) from domain controllers and uses it to detect identity-based attacks: Pass-the-Hash, Kerberoasting, DCSync, Golden Ticket, LDAP reconnaissance, and lateral movement patterns. It has no endpoint agent -- it monitors the domain controller traffic to understand what users are doing across the domain. MDE (Microsoft Defender for Endpoint) is an endpoint-focused EDR that monitors processes, files, network connections, and registry activity on individual machines, providing behavioral detection and response capabilities on each enrolled device. They complement each other: MDI sees domain-level authentication patterns that MDE cannot see from individual endpoints, while MDE sees endpoint-level process and file activity that MDI cannot see. In the Microsoft 365 Defender portal, incidents correlate detections from both: an MDI Pass-the-Hash alert links to the MDE process events on the compromised endpoint that generated the credential theft. For comprehensive defense, both are recommended; if forced to choose one, MDE provides broader coverage across more attack techniques.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.