This chapter covers Microsoft Defender for Identity, a cloud-based security solution that uses on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions. For the AZ-500 exam, this topic appears in the Security Operations domain (Objective 4.1) and typically accounts for 5-10% of questions. Mastering Defender for Identity is critical because it bridges on-premises and cloud identity security, a key focus of the exam's emphasis on hybrid environments.
Jump to a section
Imagine a bank that has multiple branches, each with its own employees, managers, and access to vaults. The bank installs a sophisticated security system that monitors all employee badge swipes, door openings, and computer logins. This system learns normal patterns: which employees work at which branch, what time they usually arrive, which vaults they access, and how they authenticate. One day, the system detects that an employee from Branch A swipes into Branch B at 3 AM, then immediately tries to access a vault they've never accessed before, using a password that was recently changed. The security system triggers an alert, isolates the employee's access, and notifies the bank's security team. It also correlates this with a recent phishing email that employee received. The bank's security system is like Microsoft Defender for Identity: it monitors on-premises Active Directory and cloud identities, learns behavioral baselines, detects anomalies like lateral movement or unusual logins, and integrates with other security tools to respond automatically. Without this system, the bank would rely on manual log reviews and would likely miss the attack until it was too late.
What is Microsoft Defender for Identity?
Microsoft Defender for Identity (MDI) is a cloud-based security solution that leverages your on-premises Active Directory (AD) signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. Formerly known as Azure Advanced Threat Protection (ATP), MDI is part of the Microsoft 365 Defender suite and integrates tightly with Microsoft Defender for Endpoint, Microsoft Defender for Cloud Apps, and Microsoft Sentinel.
Why It Exists
Traditional perimeter-based security is ineffective against modern attacks that use legitimate credentials. Attackers often compromise a single user account, then move laterally across the network to gain access to high-value targets. MDI addresses this by monitoring authentication events, entity behavior, and network traffic to detect suspicious activities that indicate an attack in progress. It provides a continuous cycle of detection, investigation, and response.
How MDI Works Internally
MDI operates through a combination of sensors, machine learning, and behavioral analytics.
1. Sensors and Data Collection
MDI uses sensors installed on domain controllers (DCs) to capture network traffic, Windows Event logs, and AD data. The sensor can be installed directly on the DC or as a standalone sensor that receives port mirroring traffic. It collects:
Network packets (via port mirroring or direct capture)
Windows Event logs (e.g., 4624 – successful logon, 4672 – special privileges assigned, 4776 – credential validation)
AD replication traffic
DNS queries
2. Data Processing and Analysis
Collected data is sent to the MDI cloud service via encrypted HTTPS (port 443). The cloud service performs: - Behavioral baseline learning: Over a period (typically 2-3 weeks), MDI learns normal behavior for each user, device, and resource. This includes login times, locations, accessed resources, and typical protocols used. - Machine learning models: MDI uses supervised and unsupervised ML to detect anomalies. For example, a model might detect a user logging in from a new geographic location that is inconsistent with their travel history. - Threat intelligence: MDI correlates detected activities with Microsoft's global threat intelligence to identify known attack patterns (e.g., Pass-the-Hash, Golden Ticket, DCSync).
3. Detection Types
MDI generates alerts for various suspicious activities: - Malicious attacks: e.g., DCSync, Pass-the-Ticket, Overpass-the-Hash, Golden Ticket, Silver Ticket, Skeleton Key. - Abnormal behavior: e.g., unusual logon failures, impossible travel (a user logging in from two distant locations within an impossible timeframe), unusual service creation. - Security misconfigurations: e.g., weak Kerberos encryption, LDAP cleartext binding.
4. Investigation and Response
Alerts are surfaced in the Microsoft 365 Defender portal (security.microsoft.com). Security analysts can:
View the alert timeline with related events.
Use the investigation feature to explore affected entities (users, devices, IPs).
Initiate automated responses via playbooks (e.g., disable user account, isolate device).
Integrate with Microsoft Sentinel for advanced SIEM capabilities.
Key Components, Defaults, and Timers
Sensor installation: Requires .NET Framework 4.7 or later, Windows Server 2012 R2 or later. The sensor uses approximately 10% CPU on the DC.
Data retention: Raw logs are retained for 30 days; alerts and activities are retained for 180 days.
Learning period: 2-3 weeks before detections become reliable.
Ports: The sensor communicates over HTTPS (443) to the MDI cloud service. It uses port 445 for SMB traffic analysis (if enabled).
Licensing: Requires Azure AD Premium P2 or Microsoft 365 E5 license (or standalone MDI license).
Configuration and Verification Commands
Installing the sensor via PowerShell:
# Download the sensor from Microsoft 365 Defender portal
# Run the installer silently
msiexec /i "MDISensorSetup.exe" /q ACCESS_KEY="<your-access-key>"Verify sensor status:
In the portal, navigate to Settings > Identities > Sensors. Check that the sensor shows as Healthy. Also verify that the sensor can communicate by checking the following registry key:
HKLM\SOFTWARE\Microsoft\Azure Advanced Threat Protection\Sensor\StatusValue 1 indicates healthy.
Check event logs:
# Check for sensor errors in Event Viewer
Get-WinEvent -LogName "Microsoft-Windows-AzureADIdentityProtection/Operational" | Where-Object { $_.Level -eq 2 }Interaction with Related Technologies
Microsoft Defender for Endpoint (MDE): MDI can share signals with MDE. For example, if MDI detects a compromised account, MDE can isolate the endpoint associated with that account.
Microsoft Defender for Cloud Apps: MDI can feed identity alerts to Cloud Apps, which can then enforce conditional access policies.
Microsoft Sentinel: MDI alerts can be streamed to Sentinel for correlation with other data sources. This is done via the Microsoft 365 Defender connector.
Azure AD Identity Protection: MDI focuses on on-premises AD, while Identity Protection focuses on cloud identities. Together, they provide comprehensive identity protection.
Specific Exam Numbers and Values
Minimum sensor requirements: Windows Server 2012 R2, .NET 4.7, 8 GB RAM, 4 cores.
Default learning period: 14 days (2 weeks) before alerts are generated based on behavioral baselines.
Alert severity levels: Low, Medium, High.
Sensitive groups: By default, MDI monitors groups like Domain Admins, Enterprise Admins, and Administrators. Additional groups can be configured.
Honeytoken accounts: Can be configured to detect lateral movement. A honeytoken is a dummy account that should never be used; any activity on it triggers an alert.
Trap Patterns
Confusing MDI with Azure AD Identity Protection: MDI is for on-premises AD; Identity Protection is for cloud Azure AD. The exam may ask which tool to use for a hybrid scenario.
Thinking MDI requires agents on all endpoints: No, only sensors on domain controllers. Endpoints are monitored via network traffic and event logs.
Assuming MDI can block attacks automatically: MDI is primarily detection and investigation; automated response requires integration with other tools (e.g., playbooks in Microsoft Sentinel).
Misunderstanding the learning period: Alerts may trigger during the learning period, but they are less reliable. The exam may test that the baseline is established after 2-3 weeks.
Install Sensor on Domain Controller
Download the MDI sensor from the Microsoft 365 Defender portal under Settings > Identities > Sensors. Run the installer with the access key generated in the portal. The sensor captures network traffic and event logs. Ensure the domain controller meets prerequisites: Windows Server 2012 R2+, .NET 4.7+, 8 GB RAM, 4 cores. After installation, verify the sensor status is 'Healthy' in the portal. The sensor will begin collecting data immediately, but behavioral baselines will take 2-3 weeks to establish.
Configure Data Collection Sources
By default, the sensor collects Windows Event logs (e.g., 4624, 4672, 4776) and network traffic via port mirroring or direct capture. You can enable additional log sources like DNS queries. In the portal, configure which events to capture and set up port mirroring if using a standalone sensor. The sensor uses HTTPS (443) to send data to the cloud. Ensure no firewall blocks this outbound traffic. Also, consider enabling SMB traffic analysis for lateral movement detection.
Define Sensitive Groups and Honeytokens
In the portal, navigate to Settings > Identities > Entity tags. Tag groups like Domain Admins as 'Sensitive' to receive high-severity alerts for any suspicious activity involving these groups. Create honeytoken accounts—dummy users with no real access. Any authentication attempt using a honeytoken account triggers a high-severity alert, indicating potential lateral movement. Honeytokens should be placed in groups like Domain Admins to attract attackers.
Monitor Alerts in Microsoft 365 Defender
Alerts appear in the Microsoft 365 Defender portal under Incidents & alerts. Each alert includes severity, affected entities, and a timeline of related events. Analysts can investigate by clicking on the alert to see the full story. Use the investigation graph to explore relationships between users, devices, and IPs. Alerts can be triaged as True Positive, False Positive, or Benign. For true positives, initiate response actions like disabling the account or isolating the device.
Integrate with Microsoft Sentinel for SIEM
To enable advanced correlation and response, connect MDI to Microsoft Sentinel. In Sentinel, add the Microsoft 365 Defender connector. This streams MDI alerts into Sentinel, allowing you to create analytics rules, run threat hunting queries, and automate responses via playbooks. For example, you can create a rule that triggers a playbook to disable a user account when MDI detects a DCSync attack. Sentinel retains data for up to 2 years, extending MDI's 180-day retention.
Enterprise Scenario 1: Detecting Lateral Movement After Phishing
A financial services company with 10,000 employees and 50 domain controllers deploys MDI to detect credential theft. An attacker phishes a junior accountant, steals their credentials, and uses them to log into a file server. MDI detects this as unusual because the accountant never accesses the file server. The attacker then attempts to dump credentials via LSASS on a domain controller. MDI's lateral movement detection triggers a high-severity alert. The security team investigates and finds the compromised account, resets the password, and blocks the attacker's IP. The incident is contained within 30 minutes. Without MDI, the attacker might have escalated to Domain Admin and caused a breach.
Enterprise Scenario 2: Detecting DCSync Attack
A healthcare organization uses MDI to protect its on-premises AD. An attacker with compromised Domain Admin credentials attempts a DCSync attack to replicate all password hashes. MDI detects the unusual replication request (non-standard replication behavior) and triggers a 'Directory Service Replication' alert. The security team immediately isolates the domain controller and resets the krbtgt account password twice (to invalidate any Golden Tickets). MDI's alert provided early warning, preventing a full compromise.
Common Misconfigurations and Pitfalls
Insufficient sensor coverage: Not installing sensors on all domain controllers leaves blind spots. Attackers can target unmonitored DCs.
Ignoring learning period: During the first 2-3 weeks, MDI may generate many false positives. Teams should tune alerts after the baseline is established.
Not integrating with other tools: MDI alone cannot block attacks. Without integration with Sentinel or Defender for Endpoint, response is manual and slow.
Overlooking honeytokens: Not configuring honeytoken accounts misses a key detection opportunity. Honeytokens are simple to set up and highly effective.
Performance Considerations
Sensor CPU usage: ~10% on a typical DC. For high-traffic DCs, consider using a standalone sensor with port mirroring.
Network bandwidth: MDI sends compressed data; typical usage is 1-5 Mbps per DC.
Storage: MDI cloud service handles storage; no on-premises storage required.
AZ-500 Objective 4.1: Configure and Manage Defender for Identity
The exam tests your ability to plan, deploy, and manage MDI in hybrid environments. Specific sub-objectives include:
Plan and deploy MDI sensors
Configure data collection sources
Manage and respond to security alerts
Integrate with other Microsoft security solutions
Most Common Wrong Answers and Why Candidates Choose Them
Choosing Azure AD Identity Protection for on-premises AD threats: Candidates confuse the two. Remember: Defender for Identity = on-premises AD; Identity Protection = cloud Azure AD. If the question mentions 'on-premises Active Directory', the answer is Defender for Identity.
Thinking MDI requires agents on every workstation: MDI only requires sensors on domain controllers. Agents on endpoints are not needed; MDI collects data via network traffic and event logs from DCs.
Believing MDI automatically blocks attacks: MDI is detection-only. Automated response requires integration with Microsoft Sentinel or Defender for Endpoint. The exam may ask 'What is the first step to automate response?' – answer: integrate with Sentinel.
Ignoring the learning period: The exam may ask 'When does MDI start generating reliable alerts?' – answer: after 2-3 weeks of baseline learning.
Specific Numbers and Terms That Appear on the Exam
Sensor prerequisites: Windows Server 2012 R2, .NET 4.7, 8 GB RAM, 4 cores.
Default learning period: 14 days (2 weeks).
Alert retention: 180 days.
Sensitive groups: Domain Admins, Enterprise Admins, Administrators.
Honeytoken accounts: dummy accounts that trigger alerts on any activity.
Ports: 443 (HTTPS) for cloud communication; 445 for SMB (optional).
Edge Cases and Exceptions
Read-only domain controllers (RODCs): Sensors cannot be installed on RODCs. You must install a standalone sensor with port mirroring.
Multi-forest environments: MDI supports multiple forests. Each forest requires its own sensor configuration.
Virtualized DCs: Sensors work on virtual DCs, but ensure the host does not overcommit CPU resources.
How to Eliminate Wrong Answers
If the answer mentions 'cloud-only' or 'Azure AD', it's likely wrong for on-premises scenarios.
If the answer suggests installing agents on all endpoints, it's wrong.
If the answer implies automatic blocking without integration, it's wrong.
Look for keywords: 'sensor', 'domain controller', 'on-premises', 'lateral movement', 'DCSync' – these point to MDI.
Defender for Identity monitors on-premises Active Directory using sensors on domain controllers.
Sensors require Windows Server 2012 R2+, .NET 4.7+, 8 GB RAM, 4 cores.
Default learning period is 2-3 weeks before reliable behavioral baselines are established.
Alerts are retained for 180 days; raw data for 30 days.
Honeytoken accounts are dummy accounts that trigger alerts on any activity, useful for detecting lateral movement.
Sensitive groups (e.g., Domain Admins) should be tagged to receive high-severity alerts.
MDI integrates with Microsoft Sentinel for advanced SIEM and automated response.
MDI does not automatically block attacks; it requires integration for automated response.
Common exam traps: confusing MDI with Azure AD Identity Protection, thinking agents are needed on endpoints, assuming immediate accurate alerts.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Defender for Identity
Protects on-premises Active Directory
Uses sensors on domain controllers
Detects lateral movement, DCSync, Golden Ticket attacks
Integrates with Microsoft 365 Defender and Sentinel
Requires Azure AD Premium P2 or Microsoft 365 E5 license
Azure AD Identity Protection
Protects cloud Azure AD identities
Uses cloud-based machine learning and sign-in logs
Detects risky sign-ins, leaked credentials, impossible travel
Integrates with Conditional Access for automatic remediation
Requires Azure AD Premium P2 license
Mistake
Defender for Identity requires an agent on every user workstation to detect threats.
Correct
MDI only requires sensors on domain controllers. It captures network traffic and event logs from DCs to monitor all authentication and activity across the domain. No endpoint agents are needed.
Mistake
Defender for Identity can automatically block malicious activities without any additional configuration.
Correct
MDI is primarily a detection and investigation tool. Automated response (e.g., disabling accounts) requires integration with Microsoft Sentinel or Microsoft Defender for Endpoint via playbooks or policies.
Mistake
Defender for Identity and Azure AD Identity Protection are the same service.
Correct
They are different. MDI protects on-premises Active Directory; Azure AD Identity Protection protects cloud Azure AD identities. They complement each other but are distinct.
Mistake
After installing the sensor, MDI immediately starts generating accurate alerts.
Correct
MDI requires a learning period of 2-3 weeks to establish behavioral baselines. Alerts generated during this period may be less reliable. After the baseline, detections become more accurate.
Mistake
Defender for Identity only works in cloud-only environments.
Correct
MDI is designed for hybrid environments. It protects on-premises Active Directory and can also monitor cloud identities when integrated with Azure AD Connect. It does not work in cloud-only environments without on-premises AD.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Microsoft Defender for Identity (MDI) is a cloud-based security solution that protects on-premises Active Directory identities from advanced threats. It uses sensors on domain controllers to capture network traffic, event logs, and AD data. MDI detects attacks like lateral movement, DCSync, and Golden Ticket by analyzing behavior and correlating with threat intelligence. It is part of the Microsoft 365 Defender suite and integrates with Sentinel for response.
Download the sensor installer from the Microsoft 365 Defender portal under Settings > Identities > Sensors. Run the installer with the access key generated in the portal. The sensor can be installed directly on a domain controller or as a standalone sensor with port mirroring. Ensure the DC meets prerequisites: Windows Server 2012 R2+, .NET 4.7+, 8 GB RAM, 4 cores. After installation, verify the sensor status is 'Healthy' in the portal.
The learning period is typically 2-3 weeks (14-21 days). During this time, MDI establishes a baseline of normal behavior for users, devices, and resources. Alerts generated during this period may be less reliable. After the baseline is established, MDI can more accurately detect anomalies. The exam may test that the default learning period is 14 days.
Yes, MDI detects DCSync attacks by monitoring directory replication requests. When an account (even a Domain Admin) requests replication of password hashes from a domain controller, MDI compares this to normal replication behavior. If the request is unusual (e.g., from a non-DC, at odd hours), MDI triggers a 'Directory Service Replication' alert with high severity.
MDI integrates with Sentinel via the Microsoft 365 Defender connector. This connector streams MDI alerts into Sentinel, allowing you to create analytics rules, run hunting queries, and automate responses using playbooks. For example, you can set a rule that triggers a playbook to disable a user account when MDI detects a compromised identity. Sentinel retains data up to 2 years, extending MDI's 180-day retention.
Honeytoken accounts are dummy user accounts created specifically to be attractive targets for attackers. They should never be used for any legitimate activity. Any authentication attempt using a honeytoken account triggers a high-severity alert in MDI, indicating potential lateral movement. Honeytokens are often placed in sensitive groups like Domain Admins to catch attackers trying to escalate privileges.
No, sensors cannot be installed on RODCs because RODCs do not support the necessary components. To monitor an environment with RODCs, you must install a standalone sensor and configure port mirroring to capture network traffic to and from the RODC. This ensures MDI can still detect threats involving RODCs.
You've just covered Microsoft Defender for Identity — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?