Set up Microsoft Defender for Identity

Introduction

After reading Defender for Identity In Depth, I decided to revise my approach to deploying Microsoft Defender for Identity (MDI). The book offered a wealth of technical insights and practical examples that genuinely changed how I look at MDI rollouts.

I wanted to share my updated deployment notes here, hoping they’ll be helpful to others working in similar environments.

If you haven’t yet, I highly recommend grabbing a copy of the book (print or e-book). It dives deep into MDI’s PowerShell module, API integration, and real-world use cases. That said, it does require a solid IT background to get the most out of the advanced scenarios.

So below are my steps I take when preparing to roll out MDI

Requirements

Permissions

Supported Server Versions

Windows 2016/2019/2022 are supported just keep in mind you use the right sensor. See below

Note: Defender for Identity Sensor v3.x is still in preview and has the following limitations:

• Requires Microsoft Defender for Endpoint
• No support for VPN or ExpressRoute
• Limited alerts, posture data, and hunting functionality

Refer to Microsoft Learn for the latest details.

Hardware Recommendations

The sizing tool hasn’t been updated for Windows Server 2016+, but here’s what works well in practice:

💡 Tip: For VMs, disable Dynamic Memory in Hyper-V or reserve all guest memory in VMware.

Audit Configuration with PowerShell

Once you’ve installed the MDI PowerShell module:

Install-Module -Name DefenderForIdentity

You can automatically configure audit settings via:

Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyCAs
Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyDCs
Set-MDIConfiguration -Mode Domain -Configuration CAAuditing
Set-MDIConfiguration -Mode Domain -Configuration DeletedObjectsContainerPermission
Set-MDIConfiguration -Mode Domain -Configuration DomainObjectAuditing
Set-MDIConfiguration -Mode Domain -Configuration EntraConnectAuditing
Set-MDIConfiguration -Mode Domain -Configuration NTLMAuditing
Set-MDIConfiguration -Mode Domain -Configuration ProcessorPerformance
Set-MDIConfiguration -Mode Domain -Configuration RemoteSAM

This will:

Automatically generate the required GPOs

Also it assigns it to a security filtering

Network

Network Requirements

Required Internet Access

Only one outbound port needs to be opened on your firewall:

All communication is outbound-only, initiated by the MDI sensor.

Network Name Resolution (NNR)

Network Name Resolution (NNR) is a critical component of Microsoft Defender for Identity. It is used by the sensor to resolve IP addresses to hostnames, enabling accurate identity correlation and threat detection.

The Defender for Identity sensor performs NNR using the following methods:

Primary Resolution Methods:

• NTLM over RPC – via TCP port 135
• NetBIOS Name Service – via UDP port 137
• Remote Desktop Protocol (RDP) – first packet of the TCP handshake on port 3389

Secondary Method:

• Reverse DNS Lookup – via UDP and TCP port 53, querying DNS servers

NNR Communication Matrix

Recommendation: Microsoft strongly recommends enabling all resolution methods for optimal detection capabilities. If full configuration is not feasible, ensure that DNS reverse lookup and at least one primary method are enabled.

Resolution Fallback Logic

• If none of the primary methods return a response, or if there is a conflict among primary method results, the sensor will fall back to the DNS reverse lookup.
• DNS is considered a secondary method and should not be relied on exclusively unless necessary.

Why NNR Matters

Accurate name resolution enables Defender for Identity to detect critical threats more effectively. NNR is essential for identifying:

• Suspected identity theft (e.g., Pass-the-Ticket attacks)
• DCSync attacks (unauthorized replication of directory data)
• Network reconnaissance using DNS lookups

Without proper NNR configuration, the MDI sensor may miss or misattribute suspicious activity, leading to reduced detection efficacy.

Action Account (gMSA Account) (recommanded)

gMSA (Group Managed Service Account) is a secured service account used by MDI to automatically perform actions in response to detected threats. The account is not necessary for MDI to function but is needed for and automated response.

What does the gMSA account actually do?

For example:

• Disable a user account during a suspected attack (e.g., Pass-the-Ticket)
• Reset a user’s password if malicious activity is detected
• Carry out actions as part of automated investigation and response (AIR)

MDI uses the gMSA account to respond automatically and securely, without requiring manual intervention.

To create a gMSA Account we can use the Powershell module for this

Use the MDI Module to create the gMSA Account

Since version 1.0.0.1 of the Microsoft Defender for Identity PowerShell module, creating a Group Managed Service Account (gMSA) has become straightforward.

The following command creates both the gMSA account and the security group specified via the -GmsaGroupName parameter:

New-MDIDSA –Identity MDIGMSA –GmsaGroupName MDIGroup

This cmdlet performs the following actions:

• Creates a gMSA account with the name provided in -Identity
• Creates a security group with the name provided in -GmsaGroupName
• Adds both the new group and the built-in Domain Controllers group to the gMSA’s PrincipalsAllowedToRetrieveManagedPassword property

This means that both domain controllers and members of the custom group can retrieve the gMSA’s managed password — which is required for secure authentication and automated actions.

Handy Checklist

Task	COmmands
🔧 KDS Root Key created	Get-KdsRootKey Add-KdsRootKey -EffectiveImmediately
👥 Host group created	New-MDIDSA –Identity MDIGMSA –GmsaGroupName MDIGroup
🔐 gMSA created	Already part of the New-MDIDSA command above, or: New-ADServiceAccount -Name MDIGMSA ...
📂 Deleted Objects permissions granted	Get-ADServiceAccount -Identity MDIGMSA -Properties PrincipalsAllowedToRetrieveManagedPassword
🧪 gMSA validated with All on true	Test-MDIDSA -Identity MDIGMSA –Detailed
📄 gMSA registered in Defender XDR	IIn Microsoft Defender XDR: Go to Settings > Identities > Directory Service accounts > Add credentials – Account name: MDIGMSA$ – Select: Group managed service account – Enter full domain: corp.contoso.com
🔒 Log on as a service granted (GPO/local)	To check local policy: secpol.msc To check GPO policy: rsop.msc Navigate to: Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Log on as a service Add: DOMAIN\MDIGMSA$ and NT SERVICE\ALL SERVICES if needed

Readiness Script

You can use the powershell module to check if your GPO configuration is correct

New-MDIConfigurationReport -Path C:\Scripts\MDI -Mode Domain -OpenHtmlReport

To see if all the gpo are applied check –> >https://github.com/microsoft/Microsoft-Defender-for-Identity/tree/main/Test-MdiReadiness

Conclusion

This is a basic configuration of Microsoft Defender for Identity — designed to get you up and running with the essential components. While MDI offers powerful detection and response capabilities out of the box, its true value comes when combined with proper auditing, gMSA integration, and robust network visibility.