This chapter covers Microsoft Defender for Identity (MDI), a cloud-based security solution that identifies, detects, and investigates advanced threats targeting on-premises Active Directory environments. For the SC-200 exam, MDI is a critical component of the Defender XDR domain, and questions typically account for 5-10% of the exam. You must understand its architecture, sensor deployment, alert types, and how it integrates with Microsoft Defender XDR and Microsoft Sentinel. This chapter provides the deep technical knowledge you need to answer MDI questions correctly and avoid common traps.
Jump to a section
Imagine a large office building with a security guard at the front desk. The guard doesn't just check badges at the door — he knows every employee by name, knows their normal arrival time, their typical floor, and who they usually meet with. He has a list of expected visitors for the day. When someone walks in, the guard compares their behavior against that baseline: if an employee who always arrives at 9 AM shows up at 3 AM, the guard immediately flags it. If an employee tries to access a restricted server room they've never entered before, the guard stops them. The guard also watches for suspicious patterns: one employee swiping into multiple floors in under 30 seconds, or someone trying to log into a computer that's already logged in. This guard doesn't block all traffic — he silently watches, logs everything, and only alerts when something deviates from the norm. That's exactly what Microsoft Defender for Identity does: it sits on your domain controllers, passively listening to every authentication request (like the guard watching who enters), builds a behavioral baseline for each user and device, and then alerts on anomalies. It uses the network traffic it sees (via port mirroring or a sensor) to detect attacks like DCSync, Golden Ticket, and pass-the-hash — all without installing agents on every endpoint.
What is Microsoft Defender for Identity?
Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, Azure ATP) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced attacks. It uses machine learning, behavioral analytics, and a deep understanding of the Active Directory protocol to detect threats like credential theft, lateral movement, and privilege escalation.
Why does it exist? Traditional security tools often miss attacks that use legitimate credentials or blend in with normal traffic. MDI fills this gap by monitoring domain controller traffic, analyzing entity behavior, and correlating events across your environment. It is not a replacement for endpoint detection (Microsoft Defender for Endpoint) or SIEM (Microsoft Sentinel) — it is a dedicated identity threat detection platform.
How It Works: The Internal Mechanism
MDI operates by capturing and parsing network traffic from domain controllers. It does this through dedicated sensors installed on domain controllers or via standalone sensors that receive mirrored traffic. Here's the step-by-step mechanism:
Traffic Capture: The MDI sensor uses Windows Event Tracing (ETW) and network packet capture (via WinPcap or Npcap) to listen to all inbound and outbound traffic on the domain controller. It captures Kerberos, NTLM, LDAP, and other AD-related protocols.
Protocol Parsing: The sensor parses the packets to extract authentication events, service requests, and directory queries. For example, it can see Kerberos TGT requests, TGS requests, NTLM challenges, and LDAP binds.
Event Forwarding: The parsed events are sent securely over HTTPS to the MDI cloud service. The sensor does not store data locally — it streams events in real-time. The cloud service then processes the events using machine learning models.
Behavioral Profiling: MDI builds a baseline for each entity (user, device, resource) over time. It learns normal behavior patterns: typical logon times, accessed resources, geolocation, and authentication frequency. This baseline is stored in the cloud.
Anomaly Detection: When a new event deviates from the baseline, MDI generates an alert. For example, if a user logs in from a new country, or a service account tries to perform a DCSync attack, an alert is triggered.
Alert Enrichment: MDI correlates the alert with other signals — from Microsoft Defender for Endpoint, Microsoft Cloud App Security, and Azure AD Identity Protection — to provide a comprehensive story. This enrichment happens in the Microsoft 365 Defender portal.
Key Components and Defaults
MDI Sensor: Installed on domain controllers (or standalone). It requires .NET Framework 4.7 or later, 2 CPU cores, 6 GB RAM, and 5 GB disk space. It uses port 443 for outbound communication to the cloud service.
MDI Cloud Service: The backend that processes events and runs detection models. It is multi-tenant and scales automatically.
MDI Portal: Accessed via Microsoft 365 Defender (security.microsoft.com). Alerts appear under 'Identity'.
Detection timeout: Alerts are generated within minutes of an event. The exact time depends on the detection type (e.g., DCSync is nearly real-time, while behavioral anomalies may take 5-10 minutes).
Data retention: Raw events are retained for 30 days. Alerts are retained for 90 days (configurable up to 180 days in some cases).
Configuration and Verification Commands
To verify sensor health, use the following PowerShell cmdlet on the domain controller:
Get-MDISensorStatusThis returns status like 'Running', 'Stopped', or 'Error'. For more detailed diagnostics:
Test-MDISensorConnectivityTo check which domain controllers have sensors:
Get-ADSensor | Format-Table Name, StatusIn the Microsoft 365 Defender portal, navigate to Settings > Identities > Sensors to view sensor health, version, and last update time.
Interaction with Related Technologies
Microsoft Defender for Endpoint (MDE): MDI shares signals with MDE. If MDE detects a suspicious process on an endpoint, MDI can correlate it with identity events to confirm lateral movement.
Microsoft Cloud App Security (MCAS): MDI alerts can be forwarded to MCAS for investigation. MCAS can also trigger conditional access policies based on MDI detections.
Microsoft Sentinel: MDI alerts can be ingested into Sentinel via the 'Microsoft Defender for Identity' data connector. This allows custom analytics and incident response.
Azure AD Identity Protection: MDI detects on-premises threats; Azure AD IP detects cloud-based identity risks. Together, they provide a complete identity protection story.
Specific Detection Examples
DCSync Attack Detection: MDI detects when a non-domain-controller requests replication of directory data (like password hashes). It looks for GetNCChanges requests from unauthorized entities.
Golden Ticket Detection: MDI analyzes Kerberos ticket requests. It flags TGTs with abnormally long validity periods (e.g., 10 years instead of 10 hours) or tickets that use forged KRBTGT hashes.
Pass-the-Hash Detection: MDI correlates NTLM authentication events across multiple machines. If a hash is used from a machine that shouldn't have it, an alert fires.
Skeleton Key Detection: MDI monitors for abnormal authentication patterns that indicate a skeleton key malware (which allows any password to authenticate).
Honeytoken Detection: MDI supports honeytoken accounts — fake accounts that should never be used. Any authentication attempt from a honeytoken triggers a high-severity alert.
Performance Considerations
MDI sensors are lightweight but can impact domain controller performance if resources are constrained. Recommended: at least 2 cores and 6 GB RAM per sensor. In high-volume environments (e.g., 100,000+ authentication events per day), consider placing sensors on dedicated domain controllers or using standalone sensors with port mirroring. The cloud service handles scaling; no on-premises management server is needed.
Licensing
MDI is included with Microsoft 365 E5, Microsoft 365 E5 Security, or as a standalone add-on. It is also available with Azure AD Premium P2 (limited capabilities). The SC-200 exam assumes you know that MDI is part of the Microsoft 365 E5 Security suite.
Install MDI Sensor on Domain Controller
Download the sensor installer from the Microsoft 365 Defender portal under Settings > Identities. Run the installer on a domain controller. It will prompt for a workspace key (generated from the portal). The sensor installs the required drivers (WinPcap/Npcap) and starts capturing traffic. It registers itself with the cloud service using the workspace key. After installation, verify with `Get-MDISensorStatus`. The sensor will begin sending authentication events immediately.
Sensor Captures Network Traffic
The sensor uses WinPcap to capture all packets on the domain controller's network interface. It filters for AD-related protocols: Kerberos (UDP/TCP 88), NTLM (TCP 445, 139), LDAP (TCP 389, 636), and DNS (UDP 53). It extracts authentication details like usernames, source IPs, timestamps, and ticket properties. The sensor does not decrypt traffic — it relies on the plaintext portions of the protocols. It also reads Windows Event Logs for additional context (e.g., Event ID 4624 for logon).
Events Sent to Cloud Service
The sensor packages the parsed events into JSON format and sends them over HTTPS (port 443) to the MDI cloud service endpoint (e.g., `yourworkspace.atp.azure.com`). The communication is encrypted using TLS 1.2. The sensor uses a certificate pinned to the service. If the sensor loses connectivity, it buffers events locally for up to 48 hours (configurable). The cloud service acknowledges receipt; if not, the sensor retries with exponential backoff.
Cloud Service Analyzes Events
The cloud service processes the events through multiple machine learning models. These models are trained on millions of authentication events from global tenants. They look for patterns like: unusual time-of-day logins, impossible travel (e.g., login from US and UK within 5 minutes), abnormal service usage, and known attack patterns (e.g., DCSync replication requests). Each detection model has a confidence score; alerts are generated only when the score exceeds a threshold (typically 0.8 on a 0-1 scale).
Alert Generated and Enriched
When a detection fires, MDI creates an alert in the Microsoft 365 Defender portal. The alert includes: affected user/device, attack type, MITRE ATT&CK technique, evidence (e.g., source IP, timestamps), and severity (Low, Medium, High). MDI automatically correlates the alert with other signals from Defender for Endpoint, Cloud App Security, and Azure AD. For example, a suspicious logon from a remote IP might be cross-referenced with an MDE alert on that endpoint. The enriched alert appears in the unified incidents queue.
Investigate and Respond
Security analysts can investigate the alert in the Microsoft 365 Defender portal. They can view the user's timeline, see related alerts, and use the advanced hunting schema (IdentityLogonEvents, IdentityQueryEvents) to query raw data. Response actions include: disabling the user account, resetting password, or initiating an automated investigation with Microsoft 365 Defender. The SC-200 exam expects you to know how to use advanced hunting to investigate MDI alerts.
Enterprise Scenario 1: Detecting DCSync in a Large Financial Organization
A global bank with 50,000 users and 200 domain controllers deploys MDI sensors on all domain controllers. One day, MDI generates a high-severity alert: 'Suspicious DCSync replication request' from a non-domain-controller server. The alert shows that the server (IP 10.1.2.100) requested directory replication from a domain controller. The security team investigates: they see the server is a newly deployed application server that should not have replication rights. They isolate the server, reset the KRBTGT password twice (standard procedure after a DCSync attack), and force password resets for all privileged accounts. Without MDI, this attack might have gone unnoticed for weeks. In production, the key configuration is ensuring sensors are on all writable domain controllers. A common mistake is placing sensors only on some DCs, which leaves gaps in coverage. Performance: each sensor uses about 5% CPU on a typical DC; with 200 DCs, the cloud service handles the load seamlessly.
Enterprise Scenario 2: Honeytoken Account Catches Insider Threat
A healthcare organization creates a honeytoken account named 'svc_backup_admin' with no real privileges. They configure MDI to alert on any authentication from this account. An internal IT admin, curious about the account, tries to log into it from his workstation. MDI immediately generates a 'Honeytoken authentication' alert. The security team investigates and finds the admin was testing credentials — a violation of policy. They terminate the admin's access. This scenario highlights how MDI can detect insider threats even when no malicious activity occurs. The honeytoken account must never be used; any use is suspicious. In production, honeytokens are created in Active Directory but not added to any group. They should have a strong password that is not shared.
Common Misconfigurations
Missing sensors on all DCs: If an attacker compromises a DC without a sensor, MDI cannot detect attacks originating from that DC. Best practice: install sensors on all writable DCs.
Insufficient resources: Sensors on underpowered DCs may drop packets, leading to missed detections. Always meet minimum requirements.
Firewall blocking outbound traffic: Sensors must reach the cloud service on port 443. If a proxy requires authentication, configure the sensor with proxy credentials.
Not configuring honeytokens: Honeytokens are easy to set up but often overlooked. They provide high-confidence alerts with low false positives.
SC-200 Exam Focus on Microsoft Defender for Identity
The SC-200 exam covers MDI under objective '1.2 Mitigate threats using Microsoft Defender for Identity' (part of 'Defender XDR'). You must be able to:
Describe the architecture (sensor, cloud service, portal).
Identify the types of alerts (DCSync, Golden Ticket, Pass-the-Hash, Skeleton Key, Honeytoken).
Understand how to configure sensors (installation, workspace key, proxy).
Explain integration with Defender XDR and Sentinel.
Use advanced hunting to investigate identity events.
Common Wrong Answers and Why Candidates Choose Them
'MDI requires an agent on every endpoint' — Wrong. MDI uses sensors on domain controllers, not endpoints. Candidates confuse MDI with Microsoft Defender for Endpoint which requires an agent on each device.
'MDI can block attacks in real-time' — Wrong. MDI is primarily a detection tool. It does not block attacks; it alerts. Blocking requires integration with conditional access or other tools.
'MDI replaces Active Directory auditing' — Wrong. MDI supplements but does not replace native AD auditing. MDI uses network traffic and event logs, but some detections require additional configuration (e.g., honeytokens).
'MDI sensors must be installed on all domain controllers including read-only' — Wrong. Sensors are only needed on writable domain controllers. Read-only DCs do not replicate changes, so they are less critical.
Specific Numbers and Values Tested
Sensor minimum requirements: 2 cores, 6 GB RAM, 5 GB disk.
Outbound port: TCP 443.
Data retention: 30 days for raw events, 90 days for alerts (configurable up to 180).
Honeytoken: any authentication triggers a high-severity alert.
DCSync detection: looks for GetNCChanges from non-DC.
Edge Cases and Exceptions
Multiple forests: MDI can monitor multiple forests if sensors are installed on DCs in each forest. The workspace can support up to 10 forests.
No internet connectivity: Sensors require outbound HTTPS. If DCs cannot reach the internet, use a standalone sensor with a proxy or deploy a gateway.
Virtual DCs: MDI works with virtual DCs. Ensure the virtual switch allows promiscuous mode for the sensor if using port mirroring.
How to Eliminate Wrong Answers
Use the underlying mechanism: MDI is network-based, not agent-based. If an answer mentions installing software on every workstation, it's wrong. If it says 'blocks attack', it's wrong unless it talks about integration. Focus on detection, not prevention. Also, remember that MDI uses machine learning — so any answer suggesting static rules only is incomplete.
MDI sensors are installed on writable domain controllers (not read-only) and require 2 CPU cores, 6 GB RAM, 5 GB disk.
Sensors communicate outbound over TCP 443 to the MDI cloud service; no inbound ports are needed.
MDI detects DCSync by monitoring GetNCChanges replication requests from non-domain-controller accounts.
Honeytoken accounts are fake accounts that should never authenticate; any authentication triggers a high-severity alert.
MDI alerts are viewable in the Microsoft 365 Defender portal under 'Identity' and can be correlated with other Defender XDR alerts.
MDI integrates with Microsoft Sentinel via the 'Microsoft Defender for Identity' data connector for advanced hunting and custom analytics.
Raw event data is retained for 30 days; alerts are retained for 90 days (configurable up to 180).
MDI does not block attacks; it only detects and alerts. Blocking requires integration with conditional access or manual remediation.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Defender for Identity
Monitors on-premises Active Directory traffic via sensors on DCs
Detects attacks like DCSync, Golden Ticket, pass-the-hash
Uses network packet capture and ETW
Generates alerts in Microsoft 365 Defender
Requires on-premises infrastructure (sensors)
Azure AD Identity Protection
Monitors cloud-based Azure AD sign-ins and user behavior
Detects risks like leaked credentials, impossible travel, anonymous IP
Uses Azure AD signals and machine learning
Triggers conditional access policies for remediation
Fully cloud-based, no on-premises components
Mistake
MDI requires an agent on every computer in the domain.
Correct
MDI uses sensors on domain controllers only, not on every endpoint. The sensor captures network traffic from DCs to detect anomalies.
Mistake
MDI can automatically block a user when an attack is detected.
Correct
MDI is a detection-only tool. It generates alerts but does not perform blocking actions. Blocking requires integration with conditional access or manual response.
Mistake
MDI only works with Azure AD, not on-premises Active Directory.
Correct
MDI is designed specifically for on-premises Active Directory. It monitors on-prem DCs and sends events to the cloud service. It does not require Azure AD.
Mistake
MDI replaces the need for Windows Event Log auditing.
Correct
MDI supplements event logs but does not replace them. It uses network traffic and some event logs, but native auditing is still needed for compliance and other detections.
Mistake
MDI sensors can be installed on any server, not just domain controllers.
Correct
Sensors must be installed on domain controllers or on standalone servers that receive mirrored traffic from DCs. Placing a sensor on a non-DC server without port mirroring will not capture AD traffic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The MDI sensor communicates with the cloud service over HTTPS on TCP port 443. It does not require any inbound ports. For network capture, it listens on the local network interface to capture AD traffic (Kerberos, NTLM, LDAP, DNS). Ensure the sensor can resolve the cloud service endpoint (e.g., yourworkspace.atp.azure.com).
Yes, MDI detects Pass-the-Hash attacks by correlating NTLM authentication events across multiple machines. It looks for the same hash being used from different source machines, especially if the hash belongs to a privileged account. An alert is generated when anomalous hash usage is detected.
Honeytoken accounts are created in Active Directory as normal user accounts but are never used. In the MDI portal (Microsoft 365 Defender > Settings > Identities > Honeytoken accounts), you can add a user or group. Any authentication from these accounts triggers a high-severity alert. Ensure the account has no real privileges and is not used for any legitimate purpose.
MDI focuses on identity threats by monitoring domain controller traffic and detecting attacks like DCSync, Golden Ticket, and lateral movement. MDE focuses on endpoint threats by installing an agent on devices to detect malware, suspicious processes, and file-based attacks. Both integrate in Defender XDR for cross-domain detection.
Yes, MDI can monitor multiple Active Directory forests. You need to install sensors on domain controllers in each forest. A single MDI workspace can support up to 10 forests. All events are sent to the same cloud service and appear in the same portal.
The sensor buffers events locally for up to 48 hours (configurable). Once connectivity is restored, it sends the buffered events to the cloud. If the buffer exceeds the limit, older events are dropped. The sensor health status will show 'Disconnected' in the portal.
Sensors require outbound HTTPS to the cloud service. If your domain controllers cannot access the internet, you can deploy a standalone sensor on a server that has internet access and configure port mirroring from the DCs to that server. Alternatively, use a forward proxy with authentication.
You've just covered Microsoft Defender for Identity — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?