Microsoft Defender for Identity

MDI sensors are installed directly on domain controllers and AD FS servers. They passively monitor all authentication and directory traffic without requiring agents on endpoints:

• Network traffic: The sensor captures and analyses all authentication protocols: Kerberos, NTLM, LDAP, DNS, and RPC
• Windows events: Event log parsing for key security events (4624 logons, 4769 service ticket requests, 4776 credential validation, 5136 directory changes)
• Active Directory replication: Monitors AD replication traffic to detect DCSync attacks
• Performance impact: The sensor typically uses ~1-2% CPU and 1-2 GB RAM on the domain controller. It dynamically adjusts its resource consumption under load.
• Standalone sensor option: For environments where DC installation is not permitted, a standalone sensor can be deployed on a dedicated server with port mirroring.

Sensors report to the MDI cloud service via an outbound HTTPS connection. No inbound firewall rules are required.

Sensor installation

MDI detects attacks across the entire identity attack lifecycle, mapped to MITRE ATT&CK:

• Reconnaissance: Account enumeration, network mapping, LDAP queries for privileged groups, DNS reconnaissance, and SAM-R enumeration
• Credential access: Kerberoasting (TGS requests for service accounts), AS-REP Roasting (accounts without pre-auth), brute-force attacks, and NTLM relay
• Lateral movement: Pass-the-Hash, Pass-the-Ticket, overpass-the-hash, remote code execution, suspicious SMB session enumeration
• Privilege escalation: Suspicious service creation, skeleton key malware, SID-History injection, and abuse of delegation permissions
• Domain dominance: DCSync (directory replication), Golden Ticket (TGT forging), DCShadow (rogue DC registration), and domain trust manipulation
• Data exfiltration: DNS tunnelling and suspicious data transfers over AD protocols

Each detection includes a detailed timeline, affected entities, evidence, and recommended investigation steps.

Security alerts overview

No. MDI is fundamentally agentless for endpoint monitoring. It gains visibility by monitoring authentication and directory traffic at the domain controller level:

• Why DC-level monitoring works: Every authentication event in an Active Directory environment involves the domain controller. By monitoring at the DC, MDI sees all sign-ins, group membership queries, Kerberos ticket requests, and directory modifications without touching individual endpoints.
• Coverage gap: Local authentication events that don't involve the DC (e.g., local admin sign-ins, RDP with cached credentials when the DC is unreachable) are not captured by MDI. For these, MDE provides endpoint-level detection.
• Complementary: MDI + MDE together provide complete identity coverage: MDI monitors AD-level authentication and MDI sensors on DCs, while MDE monitors endpoint-level credential usage and suspicious process behaviour.

This agentless architecture means MDI can be deployed in minutes (install sensors on DCs) without any endpoint deployment project.

MDI architecture

MDI continuously evaluates your Active Directory configuration and generates security posture assessment reports that identify configuration weaknesses before attackers exploit them:

• Unsecure account attributes: Accounts with reversible encryption, DES-only Kerberos, accounts that don't require pre-authentication (AS-REP Roastable)
• Dormant accounts: Active accounts that haven't signed in for 180+ days but still have valid passwords
• Legacy protocol usage: NTLM authentication usage that should be migrated to Kerberos, LDAP clear-text binds
• Privileged group sprawl: Users in Domain Admins, Enterprise Admins, or Schema Admins who shouldn't be
• LAPS deployment gaps: Computers without Local Administrator Password Solution (LAPS) for local admin credential management
• Unconstrained delegation: Computers or accounts configured with unconstrained Kerberos delegation that can be exploited for credential harvesting
• SPN configuration: Service accounts with weak or no password expiry that are Kerberoastable

Each assessment includes a severity rating, affected entities, and step-by-step remediation instructions. Assessments are updated continuously and appear in the Microsoft Secure Score.

Security assessments

MDI is natively integrated into the unified Defender XDR portal, providing identity context across all incident investigations:

• Unified incidents: MDI alerts are automatically correlated with MDE, MDO, and Entra ID Protection signals into unified incidents. A Pass-the-Hash detection is linked to the endpoint compromise and any subsequent email activity.
• Identity entity page: Each user in the Defender portal shows a unified timeline combining AD activity (from MDI), endpoint behaviour (from MDE), email activity (from MDO), and cloud app usage (from MDA).
• Advanced hunting: Identity data is available in the IdentityLogonEvents, IdentityQueryEvents, and IdentityDirectoryEvents tables for cross-product threat hunting.
• Automatic response: AIR can take identity-related actions like disabling an account or forcing password reset as part of automated incident response.

This integration means SOC analysts never need to context-switch between portals. An identity-based attack is investigated end-to-end in a single incident view.

MDI in Defender XDR

MDI deployment requires the following:

• Licensing: Microsoft Defender for Identity licence (included in M365 E5, EMS E5, or standalone)
• Domain controllers: Windows Server 2016 or later for the sensor. Server 2012 R2 is supported with the standalone sensor.
• gMSA account: A Group Managed Service Account (gMSA) for the sensor to query Active Directory. This is the recommended and most secure method.
• Network: Outbound HTTPS (443) from domain controllers to the MDI cloud service (*.atp.azure.com)
• Ports: If using the standalone sensor, port mirroring must be configured on the network switch to copy DC traffic to the sensor server
• Permissions: Domain admin or delegated permissions to install the sensor on domain controllers

Deployment typically takes 1–2 hours for a small environment. The sensor installer is downloaded from the MDI portal and installed directly on each DC.

MDI prerequisites

Honeytoken accounts are decoy user accounts that should never be used for legitimate authentication. Any activity involving a honeytoken is an immediate indicator of reconnaissance or compromise:

• Setup: Create a regular AD account with an attractive name (e.g., "admin-backup", "svc-sql-prod") but never use it for any service or sign-in
• Tag in MDI: Mark the account as a honeytoken in the MDI portal under Sensitive Accounts
• Detection: Any authentication attempt, LDAP query, or Kerberos ticket request involving the honeytoken generates a high-severity alert
• Use cases: Detects attackers who have dumped AD credentials and are testing accounts, automated tools performing credential stuffing, and insiders exploring privileged accounts they shouldn't know about

Best practice: deploy 3–5 honeytoken accounts with names that suggest privileged access across different OUs. Ensure the passwords are complex enough that they won't be guessed but the accounts are visible in directory listings.

Honeytoken and entity tags