Microsoft Defender for Identity sensor deployment

For organisations running on-premises Active Directory, Microsoft Defender for Identity (MDI) is the detection product for identity-based attacks — credential theft, lateral movement, golden-ticket attacks, DC reconnaissance, password spray against AD. MDI's value depends on sensor coverage: gaps in coverage are blind spots attackers can exploit.

Where sensors go

MDI deploys lightweight sensors on:

• All domain controllers — captures network traffic, ETW events, AD events. This is the most critical placement.
• All AD FS servers (if running federation) — captures token-issuance events and risky-IP signals.
• All Entra Connect servers — captures sync events and hybrid identity signals.
• Optionally on other servers with specific roles requiring monitoring.

The general rule: if it's an identity-related server, install a sensor.

DC sensor coverage

For domain controllers specifically:

• Every DC should have a sensor. Skipping any DC creates a blind spot — attackers can pick the unmonitored DC for their reconnaissance.
• All sites and forests — if you have multiple AD sites or multiple forests, each needs sensor coverage.
• Backup / disaster recovery DCs in separate sites also need sensors.

A typical mature MDI deployment has sensors on dozens to hundreds of DCs.

Performance

Sensors are deliberately lightweight:

• Modest CPU — typically under 5% of DC capacity.
• Modest memory — a few hundred MB.
• Modest network — sends telemetry to MDI cloud over HTTPS.

For most DCs, the performance impact is negligible. For very busy DCs (large authentication volume), test in a controlled environment first.

Deployment

The typical deployment:

1. Plan licensing — MDI is included in Microsoft 365 E5, Microsoft 365 E5 Security, EMS E5, and standalone MDI.
2. Configure the MDI instance in the Defender XDR portal (formerly its own MDI portal, now unified).
3. Generate the sensor package specific to your instance.
4. Install sensors on every target server via your config-management tooling (SCCM, Intune, Ansible, manual for small fleets).
5. Validate sensor connectivity — sensors should report healthy in the MDI dashboard.
6. Configure directory service accounts — MDI needs a low-privilege AD account to read directory data.
7. Tune detections — initial detections include some baseline noise that needs tuning.

Tuning detections

Out of the box, MDI generates more alerts than steady-state operations need. Initial tuning:

• Legitimate suspicious activities — admin actions that look like attacker reconnaissance. Flag and exclude.
• Service accounts with privileged behaviour — document and exclude.
• Vulnerability scanners running against AD — they produce signals that mimic attacker reconnaissance. Whitelist by source IP.
• Backup software with directory access — similar.

After 4–8 weeks of tuning, the alert volume settles into a sustainable rate.

Defender XDR integration

MDI signals flow into Microsoft Defender XDR alongside Defender for Endpoint, Defender for Office 365, and Defender for Cloud Apps. The most valuable detections come from cross-product correlation — a phishing email leading to credential theft leading to lateral movement leading to data exfiltration appears as a single incident with the full chain visible.

For tenants with MDI deployed, the advanced hunting experience in Defender XDR has an IdentityLogonEvents table covering AD and Entra ID sign-in events with rich detail — particularly useful for credential-spray and impossible-travel investigations.

Common pitfalls

• Sensor gaps — skipping one or two DCs because "they're not important." Attackers find those DCs first.
• No directory service account configured — sensor can't enrich detections; alert quality suffers.
• Tuning never done — alert fatigue sets in, real signals get ignored.
• Defender XDR not consulted — MDI alerts in isolation are less useful than combined with the broader picture.
• AD configuration unhardening — MDI surfaces misconfigurations (e.g., reversibly-stored passwords). Act on them, don't just monitor.

What MDI doesn't replace

MDI detects identity-based attacks against AD and Entra ID. It complements but doesn't replace:

• Defender for Endpoint for endpoint-side detection.
• Defender for Office 365 for email-side detection.
• Defender for Cloud Apps for SaaS-side detection.

The whole Defender stack working together is what catches modern multi-product attack chains.

For Microsoft 365 customers with significant on-prem AD, MDI is essentially required as part of a serious security baseline. Deploy fully; tune deliberately; integrate with the broader Defender XDR experience.