Microsoft Defender for Identity: what the sensors really detect, and what they do not replace
Microsoft Defender for Identity watches what happens at the heart of the directory: authentications, queries, replication and sensitive changes. Deployed well, it catches attacks that go unnoticed elsewhere. Deployed poorly, it leaves blind spots and buries teams in alerts. An overview from auditors who meet it in the field.
Where to install sensors
Defender for Identity relies on sensors installed on the servers that hold identity. Domain controllers come first: every domain controller, including read-only DCs and those in remote sites. A single uncovered DC is enough to create a blind spot, because an attacker targeting that server escapes traffic analysis.
Coverage should then extend to the other Tier 0 components:
- AD FS, to monitor federated authentications and suspicious access to federation servers;
- AD CS, to detect abnormal certificate requests and changes to the certification authority;
- Microsoft Entra Connect, whose synchronization account and local database are prime targets.
Microsoft offers two families of sensors: the classic sensor, installed separately, and a newer sensor built into Microsoft Defender for Endpoint that can be activated from the Defender portal on supported Windows Server versions. Prerequisites, supported versions and the features covered by each type keep changing, so check the current Microsoft documentation before choosing.
Frequently overlooked prerequisites
An installed sensor is not necessarily an effective one. Several detections depend on Windows events that the default audit policy does not generate. You need to configure advanced audit policy on domain controllers, enable NTLM auditing and, for some detections, set system access control lists (SACLs) on specific objects. Microsoft documents these settings and the portal flags gaps through health alerts.
The directory service account the product uses to query AD should preferably be a group managed service account (gMSA) with read-only rights. Finally, sensors must reach the cloud service, usually through a proxy; this is one of the few legitimate outbound flows from a domain controller.
What the product detects
Detections follow the stages of an attack against the directory:
| Phase | Examples of detected behaviour |
|---|---|
| Reconnaissance | account enumeration, reconnaissance LDAP queries, SMB session enumeration |
| Credential access | brute force, password spraying, suspicious ticket requests pointing to Kerberoasting or AS-REP roasting |
| Lateral movement | pass-the-hash, pass-the-ticket, overpass-the-hash |
| Domain dominance | DCSync, DCShadow, use of forged tickets, changes to sensitive groups |
Alerts surface in the Microsoft Defender XDR portal, where they are correlated with endpoint, email and cloud app signals to build incidents. That correlation is where the tool shines: an isolated alert on a DC means something very different when it follows a successful phishing attempt on a workstation.
Posture assessments
Beyond detection, Defender for Identity publishes identity security posture assessments, surfaced in Secure Score and in exposure management tools. They flag, for example, unconstrained Kerberos delegation, legacy protocols still in use, credentials exposed in clear text, the Print Spooler service running on domain controllers or dangerous certificate templates. These recommendations make an excellent backlog, provided someone actually owns it.
Tuning without going blind
False positives often come from legitimate tools: vulnerability scanners, identity management solutions, monitoring tools that query the directory heavily. Exclusions should be narrow (one machine or account, for one detection), documented and reviewed. A blanket exclusion for an admin server simply gives a hiding place to any attacker who compromises it.
Two settings pay off: declaring honeytoken accounts, whose any use raises an alert, and tagging as sensitive the high-value accounts and groups that are not flagged by default. Response actions, such as disabling an account, require a dedicated action account whose rights must be kept under control.
Detecting is not protecting. Defender for Identity does not replace directory hardening, the tiering model, offline backups or long-term log retention in a SIEM. It tells you an attack is under way; it does not remove the paths that make it possible.
What an audit checks
- a healthy sensor on every domain controller and on AD FS, AD CS and Entra Connect servers;
- the required event logging and SACLs, and no open health alerts;
- the nature and scope of exclusions, and their justification;
- whether posture assessments are actually worked on, and how quickly alerts are handled.