Microsoft Defender for Identity: Deploy sensors, secure its accounts and tune detections

Microsoft Defender for Identity (MDI) watches the domain controllers, AD FS, AD CS and Entra Connect servers that attackers most want, but it runs with privileged access on those same tier 0 servers, so a careless deployment can add risk as well as visibility. MDI sensors parse network traffic and Windows events locally on identity servers and send the relevant signals to the Microsoft Defender portal, where they become alerts, lateral movement paths and identity posture assessments. This guide covers the choice between sensor v2.x and v3.x, the prerequisites that most often break deployments, how to secure the Directory Service Account and action account, how to use entity tags and honeytokens, and how to tune detections without blinding them. It is for identity and SOC engineers deploying or inheriting MDI. For the tool-agnostic audit policy and event ID reference, see the Active Directory Security Monitoring and Event IDs Guide; this page does not repeat it.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Use sensor v3.x on Windows Server 2019 and later. Microsoft recommends v3.x for those servers; it runs as LocalSystem, needs no Directory Service Account, and activates through Defender for Endpoint onboarding or standalone v3 onboarding.
• Cover every identity server, not just DCs. AD CS and Entra Connect sensors unlock certificate authority and hybrid posture assessments, and a v3 deployment on those servers still needs at least one v3 sensor on a domain controller.
• The service accounts are tier 0 credentials. The v2.x Directory Service Account needs read on all objects, including Deleted Objects; an action account can reset passwords and disable users. Keep them separate, prefer gMSA, and never reuse them on non-DCs.
• Tag before you tune. Sensitive and honeytoken tags change how detections behave; any sign-in from a honeytoken account raises an alert.
• Tune in Defender XDR, not with exclusions. Microsoft recommends alert tuning rules over exclusions, and existing exclusions do not carry over as MDI detections move to the Defender XDR engine.

How identity and access work in Microsoft Defender for Identity

MDI has three parts: sensors on identity infrastructure, a cloud workspace tied to your Entra tenant, and the Microsoft Defender portal. Sensors capture and parse traffic and events locally and send only the required signals to the cloud. MDI then raises behavioural and threat intelligence detections across reconnaissance, compromised credentials, lateral movement and domain dominance, computes lateral movement paths, and publishes identity posture assessments in Microsoft Secure Score.

Sensor v2.x versus v3.x

A server cannot already have a v2.x sensor when v3.x is deployed, but a workspace can hold both during migration. Run Microsoft's Test-MdiReadiness.ps1 before activating v3.x.

Prerequisites that break deployments

• Connectivity: TCP 443 outbound to *.atp.azure.com, including the workspace sensor API URL. A proxy must not perform SSL inspection; ExpressRoute needs Microsoft peering with BGP community 12076:5220; firewall rules can use the AzureAdvancedThreatProtection service tag, but you must track IP changes.
• Internal ports: DNS 53 to DNS servers, RADIUS UDP 1813 inbound from RADIUS for VPN integration (v2.x), and for network name resolution TCP 135, UDP 137 and TCP 3389 from the sensor to devices (one is required, Microsoft recommends all three). Multi-forest deployments need LDAP 389 and Global Catalog 3268 to remote DCs by default.
• Virtualisation: disable Large Send Offload on VMware NICs, disable Dynamic Memory on Hyper-V, and reserve all guest memory on VMware.
• Time: sensors and DCs must be within five minutes of each other.
• Windows Server 2019 v2.x installs: require KB4487044 or later or the sensor stops itself.

Availability: Microsoft lists EMS E5 or A5, Microsoft 365 E5, A5 or G5, Microsoft 365 E5, A5, G5 or F5 Security, Microsoft 365 F5 Security and Compliance (both F5 options with stated base licences), or a standalone Defender for Identity licence. Creating the workspace needs a user with the Security Administrator role.

Admin roles and privileged access

MDI touches privilege in two directions: the people who administer it, and the accounts it uses inside AD.

Directory Service Account (v2.x)

v2.x sensors use a DSA to query AD objects, track changes and resolve entities. Microsoft recommends a gMSA, so AD rotates the password, over a standard user account that can expire and cause downtime. The DSA needs read-only permission on all objects, including the Deleted Objects container (Microsoft's script grants List Contents and Read Property there), which lets MDI detect deletions. It is also the identity that makes SAM-R calls to devices to read local Administrators membership for lateral movement paths; the default local service identity cannot. In untrusted multi-forest estates, use one DSA per forest. Run Test-MDIDSA -Identity <name> -Detailed to confirm it has no excessive rights. See the Group Managed Service Accounts (gMSA) Guide for retrieval permissions and monitoring.

Action account

Remediation actions (force password reset, disable user) on on-premises accounts run as the DC's LocalSystem by default, and Microsoft recommends keeping that default. If you need a scoped identity instead, a gMSA action account needs, on descendant user objects, Reset password with read and write of pwdLastSet, and read and write of userAccountControl; optionally read and write members on groups. Microsoft's cautions are worth adopting as rules:

• Do not use the same gMSA on servers other than DCs: if that server is compromised, the password can be retrieved and used to change passwords and disable accounts.
• Do not use the same account as DSA and action account: one needs read-only, the other write.
• With v3.x sensors present, select Automatically use the sensor's local system account under Settings, Identities, Microsoft Defender for Identity, Manage action accounts.

People

Restrict who can change MDI settings, tags and exclusions in the Defender portal to a small group with just-in-time access. A changed exclusion or removed honeytoken tag is a quiet way to blind detection, so audit configuration changes. See the Microsoft Defender for Endpoint Guide for portal role design that also covers MDE-onboarded v3 sensors.

Integrations, API tokens and service accounts

Microsoft notes that after full migration to v3.x a remaining DSA configuration keeps being validated and raises Directory services user credentials are incorrect alerts if it fails; removing the workspace configuration does not delete the gMSA from AD, so retire it deliberately. Entra Connect servers deserve a sensor for another reason: their sync credentials bridge AD and the cloud, so protect them as tier 0 credentials. See the Microsoft Entra Connect and Cloud Sync Hardening guide.

Logging and detection

Entity tags and honeytokens

Tags live under Settings, Identities in the Defender portal.

• Sensitive: members of the built-in privileged groups (Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, Print Operators, Group Policy Creator Owners, Domain Controllers and others, including nested members) are sensitive automatically, as are certificate authority, DHCP, DNS and Exchange servers and accounts with Replicating Directory Changes permissions. Tag your own tier 0 groups, PAM vault accounts and the Entra Connect sync account too; some detections, such as sensitive group changes, depend on the tag.
• Honeytoken: tag dormant decoy users or devices; Microsoft states any sign-in from a honeytoken account triggers an alert. Make decoys believable (realistic names, group memberships, a plausible description) and never use them. The Decoy accounts in Active Directory guide and the Honeytokens and Canary Credentials Guide cover design.
• Exchange server: devices only; Exchange servers are tagged sensitive by default.

Tuning without blinding

Microsoft recommends alert tuning rules in Defender XDR over exclusions, because they allow more granular conditions and keep tuned alerts reviewable. Exclusions still exist, under Settings, Identities, Excluded entities, as Exclusions by detection rule or Global excluded entities (IP addresses, subnets, devices, domains), but Microsoft warns that existing detection exclusions do not carry over as detections move to the Defender XDR detection engine; re-create them as tuning rules.

1. Baseline for two to four weeks before tuning: note which alerts come from vulnerability scanners, identity management tools, backup and monitoring servers.
2. Tune narrowly: one source device and one detection, never a whole subnet or a global device exclusion for a server that also holds admin sessions.
3. Never exclude domain controllers, PAM servers or sensitive accounts globally.
4. Review tuning quarterly, removing rules whose source system has been retired.

Detections mapped to techniques

Metrics

• Sensor coverage: percentage of DCs, AD FS, AD CS and Entra Connect servers with a healthy sensor (target 100%).
• Sensor health alerts open longer than 24 hours.
• Identity posture score trend and open high-impact assessments.
• Number of tuning rules and exclusions, and how many were reviewed this quarter.
• Honeytoken accounts tagged and tested.
• Mean time to triage high-severity MDI alerts.

Hardening baseline

Posture assessments

MDI publishes posture assessments in Secure Score under Recommended actions in six categories: Hybrid security, Identity infrastructure, Certificates, Group policy, Accounts and Cloud identities. Certificate template assessments are available wherever AD CS is installed, but certificate authority assessments need a sensor on the AD CS server, and hybrid security recommendations need a sensor on Entra Connect servers. Scores refresh every 24 hours. Work them as a backlog: assign owners, fix the high-impact items first, and track the score. Many map directly to the AD CS Security Guide and Kerberos Delegation Security Guide.

Rollout

1. Prepare: confirm licences, create the workspace, run Test-MdiReadiness.ps1, configure the audit policy and SACLs MDI depends on (covered in the monitoring guide), open connectivity.
2. Pilot: deploy to one DC per site and one AD CS and Entra Connect server; check sensor health and resource use for a week.
3. Scale: v3.x on all 2019 and later DCs, v2.x only where v3.x is not supported; at least one v3 sensor on a DC if v3 covers AD FS, AD CS or Entra Connect.
4. Configure accounts: gMSA DSA for remaining v2.x sensors, LocalSystem for actions, tags and honeytokens.
5. Tune and operate: baseline, tune in Defender XDR, wire alerts into the SOC queue and automated disruption.
6. Rollback: a misbehaving v2.x sensor can be stopped or uninstalled per server; a v3.x sensor is deactivated in the Defender portal. Keep the previous sensor package and change record so a DC can return to its prior state quickly.

Small versus large estates: a single-forest organisation with a few DCs can usually deploy v3.x everywhere in a day and use LocalSystem for everything. Large multi-forest estates need per-forest DSAs for any v2.x sensors, capacity checks on busy DCs, and an exclusion and tuning governance process owned by the SOC.

Framework mapping

Common misconfigurations

• DCs only: no sensors on AD CS or Entra Connect, so certificate authority and hybrid assessments are missing and the most valuable non-DC tier 0 servers go unwatched.
• Over-privileged DSA: a DSA added to Domain Admins "to make it work", or a standard user account with a non-expiring password. Use a gMSA and verify with Test-MDIDSA.
• Shared accounts: one gMSA used as both DSA and action account, or retrievable by non-DC servers.
• Broad exclusions: whole subnets or management servers excluded globally, hiding real attacks from those hosts; or exclusions assumed to have carried over to the Defender XDR engine.
• SSL-inspecting proxy: sensors cannot reach the service through SSL inspection, leading to silent gaps until sensor health alerts are noticed.
• Stale DSA after v3 migration: leftover workspace configuration raising credential alerts and an unused gMSA left in AD.

Practitioner checklist

• Inventory every DC, AD FS, AD CS and Entra Connect server and confirm each has a healthy sensor.
• Use v3.x on Windows Server 2019 and later; keep v2.x only where required.
• Confirm 443 connectivity to the workspace without SSL inspection, and the virtualisation settings Microsoft requires.
• Use a gMSA DSA with read-only rights for v2.x sensors and verify with Test-MDIDSA.
• Keep remediation on LocalSystem, or a DC-only gMSA action account separate from the DSA.
• Tag custom tier 0 accounts and groups as sensitive and deploy at least two honeytoken accounts.
• Replace exclusions with narrow alert tuning rules in Defender XDR and review them quarterly.
• Work the identity posture assessments as an owned backlog and track the score.
• After full v3 migration, remove the workspace DSA configuration and retire the gMSA.

Standards and references

• Microsoft Learn: What is Microsoft Defender for Identity?
• Microsoft Learn: Defender for Identity sensor v2.x prerequisites
• Microsoft Learn: Defender for Identity sensor v3.x prerequisites
• Microsoft Learn: Directory Service Accounts for Defender for Identity
• Microsoft Learn: Manage action accounts
• Microsoft Learn: Defender for Identity entity tags
• Microsoft Learn: Configure Defender for Identity detection exclusions
• Microsoft Learn: Defender for Identity security posture assessments

Related NHI Mgmt Group resources: Active Directory Security Monitoring and Event IDs Guide, ITDR Guide, Microsoft Entra ID Protection, Group Managed Service Accounts (gMSA) Guide.