How the Defender for Identity cloud service and its sensors fit together, what the classic v2.x sensor and the MDE-integrated v3.x sensor collect on domain controllers, AD FS, AD CS and Entra Connect servers, what leaves the server, how the Directory Service Account is used, and how to size, connect and keep sensors healthy.
Deploy the Defender for Identity sensor on domain controllers, AD FS, AD CS and Entra Connect servers, pick v2.x or the MDE-based v3.x sensor, set up the directory service account and audit policy, and run response actions from the Defender portal.
The Defender for Identity alert catalogue by kill-chain phase, what replaced lateral movement paths, entity tags, exclusions versus alert tuning, identity posture assessments, response actions and the action account, and the Identity* Advanced Hunting tables with ready KQL.
Every documented product-to-product link in the Defender family, where each switch lives, what it needs, what it unlocks, and how to prove it is working.
What Defender for Identity detects that an MDE-onboarded domain controller cannot, how the v3.x sensor rides on the MDE agent, what the classic v2.x sensor still does better, licensing, and a three-way comparison table.
Page-by-page walk of Settings in the Defender portal, which product owns each page, which toggles reach across products, how device groups drive automation and RBAC, and how to audit who changed what.
A diagnostic workflow for Defender for Identity, from sensor install failures and services stuck starting, through every documented health issue and its fix, to the audit policies that feed detections and why a known-bad action raised no alert.
The three permission layers in the Defender portal, Entra global roles, the legacy per-product RBAC for MDE, MDO, MDA and MDI, and unified RBAC with its permission groups, data sources, scoping, activation, import and the 2026 auto-enablement.