Microsoft Defender for Identity Deployment: My top 10 practical recommendations from real environments – Part 1

Deploying Microsoft Defender for Identity effectively takes more than just installing sensors and watching alerts appear in the portal. The service provides powerful visibility into Active Directory activity, but realizing its full value depends on careful planning, some maintenance, and integration with the broader on-premises Microsoft identity ecosystem. I’ve gathered a set of recommendations that help ensure a reliable and secure deployment across different environments.

In this post, I’ve summarized my top ten practical recommendations to help administrators get the most out of MDI and avoid some of the common pitfalls I’ve seen in real-world implementations.

What is MDI?

Microsoft Defender for Identity (MDI) is a cloud-based security solution that helps protect on-premises Active Directory environments from advanced attacks. It works by analyzing network traffic, security events, and user behavior to detect suspicious activities such as credential theft, lateral movement, and privilege escalation. MDI integrates with Microsoft Defender XDR to provide correlated detections across identities, endpoints, and cloud workloads. The service is included with Microsoft 365 E5 and Security E5 licenses (now called Microsoft Defender Suite), or it can be purchased as a standalone add-on product. Once the tenant is licensed, administrators deploy lightweight sensors on domain controllers (and optionally on related servers such as AD FS or AD CS) to collect telemetry that feeds into the Microsoft Defender portal for continuous monitoring and threat detection.

Ok, now that you know what MDI is and how the architecture looks (logically), let’s get into my tips:

1. Run the MDI Sizing Tool

Before installing the sensors on your domain controllers, it’s recommended to make sure they have enough resources. The sensor will never hog the resources from the domain controller, leaving authentications and Kerberos ticket issuance at risk, but rather the MDI sensor will stop and restart again to free up resources for the domain controller. This could mean, however, that the sensor misses important events and therefore won’t alert on something untoward. It’s therefore recommended to run the TriSizingTool (downloadable from https://aka.ms/mdi/sizingtool) for 24 hours and review the results.

I guess this goes without saying. Increase the resources on domain controllers if the tool recommends it. I have seen instances where important events were being missed on the PDC emulator because it didn’t have enough resources. The results were incomplete information in the XDR portal about service account usage for example.

2. Ensure all Domain Controllers have the sensor installed

MDI relies on sensors on all of your Domain Controllers, and they need to be operating without any “Health Issues”

Periodically review the sensors page in the defender portal to ensure all domain controllers have a sensor installed and that they are healthy.

3. Evaluate sensor version 3.x

Try out the recently announced unified sensor on a few domain controllers since the new sensor version is now generally available.

The new unified Defender for Identity sensor (v3.x) is built directly into Windows Server 2019 and later, removing the need to download and deploy the classic standalone agent. Because the sensor now ships with the OS, activation becomes a simple toggle rather than a full installation, and updates flow through normal Windows Update instead of a separate channel. When domain controllers are already onboarded to Defender for Endpoint, the new sensor can be enabled with a few clicks in the Defender XDR portal (Automatic activation), and both products share the same logs and network endpoints for easier operations.

While support today focuses on domain controllers, future releases will extend to other identity infrastructure roles and allow onboarding without requiring Defender for Endpoint. Existing deployments on the classic sensor should stay in place for now until Microsoft provides guided migration tooling, but new deployments, especially those already using Defender for Endpoint, are encouraged to adopt the new built-in sensor for easier management, unified updates, and improved reliability.

See the pre-requisites for the new unified sensor here.

4. Deploy sensors on AD CS, AD FS and Entra Connect Sync servers

When suitable hardening is complete, be sure to deploy the sensors to these servers.

Anything that shapes or validates identity in your environment sits firmly in the Tier 0 space, even if it isn’t a domain controller. That’s why AD CS, AD FS, and your Entra Connect Sync servers all count as part of the control plane. They issue certificates, validate tokens, and move identities around, so if one of them goes down or gets compromised, everything else feels it. Give them the same hardening you would a DC: lock down access, minimise what runs on them, and keep their admin paths clean. Once they’re in a good state, install Microsoft Defender for Identity sensors on them so you get the same visibility and threat detection you rely on everywhere else in Tier 0.

5. Enable appropriate auditing on Domain Controllers, Active Directory, AD CS, AD FS and Entra Connect servers

Microsoft’s deployment documentation covers the auditing configuration requirements quite extensively, but it can be quite confusing. Essentially, auditing configuration has to be enabled for Domain Controllers, and this includes the Domain Object (SACL) auditing. To check the SACL auditing configuration on a Domain you can run* the following PowerShell command:

(Get-MDIConfiguration -Configuration DomainObjectAuditing -Mode Domain).Details |<br>ConvertTo-Json | Out-File "C:\Reports\DomainObjectAuditing.json"

*Requires the installation of the Defender for Identity PowerShell module.

In addition to the domain and domain controller auditing, there are separate auditing configuration requirements for the other identity related roles in your environment. I recommend following Microsoft’s official documentation to configure auditing for each of these roles before proceeding with sensor deployment – https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection#configure-auditing-on-ad-fs

Thomas Verheyden has created a GUI based wrapper around the Defender for Identity PowerShell module that can verify the auditing config and apply the correct auditing configuration via GPO or Local policy. Check out the tool here on GitHub.

The new v3.x sensor can automatically configure auditing on Domain Controllers – Configure audit policies for Windows event logs – Microsoft Defender for Identity | Microsoft Learn

That wraps up the first half of my top 10 practical recommendations for deploying Defender for Identity. We’ve covered a solid foundation so far, and in part 2 we’ll dig into the next set of real-world tips, from using multiple DSA accounts and tagging sensitive identities to VPN integration and Unified RBAC.

Ready to continue? Jump to Part 2 here.