Microsoft Defender for Identity (MDI) secures the on-premises Active Directory (AD) against identity threats as a cloud-based security solution. By thoroughly analyzing user activities and detecting complex attack vectors, Microsoft Defender for Identity (MDI) ensures comprehensive protection against identity compromises.
Microsoft Defender for Identity goes beyond simple security incident detection by recognizing, identifying and analyzing comprehensive attack scenarios such as Pass-the-Hash, Pass-the-Ticket and reconnaissance techniques. The integrated threat analysis leverages machine learning and heuristic algorithms to identify unusual behavior within the IT infrastructure, such as sudden privilege escalations. Thanks to these analyses, security teams can respond more quickly to potential attacks.
Prerequisites and Licensing
Licenses
To use Microsoft Defender for Identity, one of the following licenses is required:
- Enterprise Mobility + Security E5/A5
- Microsoft 365 E5/A5
- Microsoft 365 E5/A5/F5 Security Add-On*
- Microsoft 365 F5 Security + Compliance Add-On*
- Standalone Defender for Identity license
* additional licenses are required.
An overview of Microsoft licensing packages and their features can be found at https://m365maps.com/.
Roles
The following roles are provided for the configuration and management of Microsoft Defender for Identity (MDI), based on the principle of least privilege:
Role | Description |
Security Administrator | Deployment and Management of Microsoft Defender for Identity |
Security Operator | Configure settings for Microsoft Defender for Identity Manage Microsoft Defender for Identity security alerts and activities |
Security Reader | View Microsoft Defender for Identity settings |
Additional roles and permissions are described in the following article:
Role groups – Microsoft Defender for Identity | Microsoft Learn
A group managed service account (gMSA) is used to connect sensors to the on-premises Active Directory. To create a gMSA account, either a domain administrator account or permissions to create msDS-GroupManagedServiceAccount objects are required.
Operating Systems
Microsoft Defender for Identity requires the following operating systems as desktop or core versions:
- Windows Server 2016, fully patched
- Windows Server 2019, fully patched
- Windows Server 2022, fully patched
- Windows Server 2025, fully patched
Installations are supported for Domain Controllers, Active Directory Federation Services (AD FS) and Active Directory Certificate Services (AD CS).
Microsoft recommends migrating Active Directory Federation Services (AD FS) to Microsoft Entra ID. For more information, visit: AD FS Decommission Reference | Microsoft Learn
Network
For smooth operation, the following network ports are required for communication. For detailed information, visit:
Prerequisites – Microsoft Defender for Identity | Microsoft Learn
Internet Ports
Protocol | Transport | Port | From | To |
SSL | TCP | 443 | MDI sensor | Defender for Identity cloud service |
The connection can be tested as follows: The required workspace name for the test can be found in the Microsoft Defender Portal (https://security.microsoft.com) > Settings > Identity > General > about.

The following PowerShell command tests the connection.
1 | invoke-WebRequest https://%Arbeitsbereichsname%sensorapi.atp.azure.com/tri/sensor/api/ping |
The expected result should be an HTTP status code 200.

Internal Ports
Protocol | Transport | Port | From | To |
DNS | TCP/UDP | 53 | MDI sensor | DNS Server |
Netlogon | TCP/UDP | 445 | MDI sensor | all devices on the network |
Radius | UDP | 1813 | Radius | MDI sensor |
SSL | TCP | 444 | Sensor service | Sensor updater service |
Localhost ports* |
*Required for the Sensor Service Updater: Traffic between localhost and localhost is generally allowed unless restricted by a custom firewall rule.
Network Name Resolution (NNR)
Protocol | Transport | Port | From | To |
NTLM over RPC | TCP | 135 | MDI sensor | all devices on the network |
NetBIOS | UDP | 137 | MDI sensor | all devices on the network |
RDP* | TCP | 3389 | MDI sensor | all devices on the network |
*Only the first Client Hello packet is required.
Preparing the Domain for Microsoft Defender for Identity
Creating a Group Managed Service Account (gMSA)
Two options are available for connecting sensors to the on-premises Active Directory domain:
- Directory Service Account (AD user account and password)
- Group Managed Service Account (automatically managed, gMSA)
For security reasons, signing in with a Group Managed Service Account (gMSA) is prioritized. Below, a Group Managed Service Account (gMSA) will be created. This is a domain account used for running services. A security benefit of a gMSA is that password management is automated and does not need to be performed manually.
If a Group Managed Service Account (gMSA) has not yet been created on the domain controller, a KDS Root Key must first be created. This is required to securely generate and manage the gMSA passwords. The following PowerShell command is used for this purpose:
1 | Add-KdsRootKey -EffectiveImmediately |

A Group Managed Service Account (gMSA) can be created using PowerShell. To do this, PowerShell must be run on a domain controller with a user account that either has domain administrator privileges or the permission to create msDS-GroupManagedServiceAccount objects.
Adjust the following parameters:
- Name: Name for the service account, e.g. MDI-SvcAccount
- DNSHostName: FQDN of the service account, e.g. MDI-SvcAccount.int.cloudcoffee.ch
- PrincipalsAllowedToRetrieveManagedPassword: Specify all domain controllers to grant sensors access to the password.
1 | New-ADServiceAccount -Name MDI-SvcAccount -DNSHostName MDI-SvcAccount.int.cloudcoffee.ch -KerberosEncryptionType AES256 -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword cclvsrdc001$ |

The properties of the Group Managed Service Account can be retrieved using the following PowerShell command:
1 | Get-ADServiceAccount -Identity MDI-SvcAccount |

The following PowerShell command checks access to the Group Managed Service Account from the local server.
1 | Test-ADServiceAccount -Identity MDI-SvcAccount |

Permissions for Group Managed Service Account
Microsoft Defender for Identity (MDI) requires read access to objects in Active Directory to perform its tasks. Additionally, access to the Deleted Objects container is necessary for detecting deleted users. Access to deleted objects requires that the Active Directory Recycle Bin is enabled.
Active Directory Administrative Center > Tasks > Enable Recycle Bin

In the following PowerShell script (source: Configure a DSA for Defender for Identity with a gMSA – Microsoft Defender for Identity | Microsoft Learn), the variables $Identity and $groupName must be adjusted and the script should then be executed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | # Declare the identity that you want to add read access to the deleted objects container: $Identity = 'MDI-SvcAccount' # If the identity is a gMSA, first to create a group and add the gMSA to it: $groupName = 'MDI-SvcAccountGroup' $groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD' if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) { $groupParams = @{ Name = $groupName SamAccountName = $groupName DisplayName = $groupName GroupCategory = 'Security' GroupScope = 'Universal' Description = $groupDescription } $group = New-ADGroup @groupParams -PassThru Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity) $Identity = $group.Name } # Get the deleted objects container's distinguished name: $distinguishedName = ([adsi]'').distinguishedName.Value $deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName # Take ownership on the deleted objects container: $params = @("$deletedObjectsDN", '/takeOwnership') C:\Windows\System32\dsacls.exe $params # Grant the 'List Contents' and 'Read Property' permissions to the user or group: $params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity)) C:\Windows\System32\dsacls.exe $params # To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones: # $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity)) # C:\Windows\System32\dsacls.exe $params |
The permissions for the Group Managed Service Account (gMSA) have been successfully set.

Group Policies for Advanced Audit Policies
The configuration report of Microsoft Defender for Identity (MDI) checks the Security Access Control Lists (SACLs) of the domain as well as the required group policies. If any deviations from the requirements are found, the report highlights them.
The PowerShell module DefenderForIdentity is required to generate the report.
1 2 | Install-Module -Name DefenderForIdentity Import-Module DefenderForIdentity |

To generate the configuration report, change the Path option to the desired location for the report.
1 | New-MDIConfigurationReport -Path C:\Scripts\MDI -Mode Domain -OpenHtmlReport |
After running the PowerShell command, you will be prompted for the Identity. Enter the hostname, e.g. CCLVSRDC001.

The HTML report clearly shows which configurations are already met and which still need adjustment. For unmet settings, the corresponding PowerShell commands are provided to simplify the configuration. Those seeking detailed information on the events considered by Microsoft Defender for Identity (MDI) can find them at the following link:
Event collection overview – Microsoft Defender for Identity | Microsoft Learn

Excerpt from Group Policy:

Sizing Tool
The Sizing Tool analyzes the performance requirements for Microsoft Defender for Identity (MDI) by collecting data on network traffic, CPU utilization, memory requirements and more. Based on this information, it generates a report with recommendations for optimal resource allocation.
Download the TriSizingTool from GitHub, extract it and run the TriSizingTool.exe file. The tool will then run for 24 hours to collect the data.

After 24 hours, the performance report for Microsoft Defender for Identity (MDI) will be available as an Excel file. The Azure ATP Summary sheet contains detailed results in the Sensor Supported column, along with recommendations for performance assessment. Further information on the results can be found here: Plan capacity for deployment – Microsoft Defender for Identity | Microsoft Learn

Check Readiness
The PowerShell script Test-MdiReadiness.ps1 checks all essential requirements for setup. If specific conditions are not met, it provides helpful links to relevant Microsoft Learn articles that offer detailed guidance on resolving the identified issues. The areas checked include, among others:
- Domain Services Readiness
Verification of the configuration for object, Exchange and AD FS monitoring, as well as other relevant settings. - Domain Controller Readiness
Analysis of the configuration for advanced monitoring, NTLM settings, operating system version, server resource requirements and more. - Certification Authority Server Readiness
Examination of monitoring policies for Certification Authority servers, as well as the up-to-dateness of root certificates and other configurations.
Download and execute the PowerShell script Test-MdiReadiness.ps1 from Github.
1 | .\Test-MdiReadiness.ps1 -OpenHtmlReport |

The PowerShell script checks the preparation of the Active Directory environment for integration with Microsoft Defender for Identity (MDI) and opens the HTML report in the browser. Configuration guidance, in case certain prerequisites are missing, is directly accessible via the link in the header.

Configure Microsoft Defender for Identity
Microsoft Defender for Identity (MDI) is configured in the Microsoft Defender Portal.
Microsoft Defender Portal (https://security.microsoft.com) > Settings > Identities

Upon the first launch, the workspace is set up and will be available within a few minutes.

Group Managed Service Account
Add the previously prepared group managed service account under Directory services accounts > Add credentials.
- Specify the Name of the group managed service account
- Enable the Group Managed Service Account option
- Specify the local Domain
- Complete the inputs by clicking Save

Sensors
Download the installation package for the sensors under Sensors > Add sensors > Download installer (1).
Note the Access key (2)

Extract the downloaded file Azure ATP Sensor Setup.zip on the server and start the installation with Azure ATP Sensor Setup.exe.

Select the Language (1) and click Next (2).

Select the deployment type Sensor (1) and click Next (2).
For virtual guest systems on VMware, Large Send Offload (LSO) should be disabled. For more details, refer to Sensors on VMware Virtual Machines.

Insert the Access key (1) and click Install (2).

The installation is successfully completed after a short time.

The domain controller is displayed under Sensors in the Microsoft Defender Portal.

Install the sensor on each relevant server.
Notifications
Notifications can be triggered for health issues and newly detected alerts, sent to email recipients.
Notifications about Health Issues
Add email recipients under Notifications > Health issues notifications.

Notifications about Alerts
Add email recipients under Notifications > Alert notifications.

Functionality Check
Microsoft Defender for Identity (MDI) offers a test mode to validate the configuration. This sets all alert thresholds to low, resulting in a higher number of alerts being sent.
Open Microsoft Defender Portal (https://security.microsoft.com) > Settings > Identities > General > Adjust alerts thresholds, enable the option Recommended test mode (1) and save it by clicking Apply changes (2).

After enabling the test mode, assign a privileged role to a user, such as an Enterprise Administrator.

This action triggers the notification Suspicious Additions to Sensitive Groups. If email notifications are enabled, the following message will appear in the inbox:

A more detailed investigation of the alert can be performed in the Microsoft Defender Portal.
Microsoft Defender Portal (https://security.microsoft.com) > Incidents & alerts > Alerts and click on the incident.

Detailed information about the incident will now be displayed.

After a successful functionality check, remove the privileged role from the user and disable the test mode.
Open Microsoft Defender Portal (https://security.microsoft.com) > Settings > Identities > General > Adjust alerts thresholds, disable the option Recommended test mode (1) and save it by clicking Apply changes (2).

Troubleshooting
Sensors on VMware Virtual Machines
In Microsoft Defender for Identity, sensors on VMware virtual machines may trigger the warning Some network traffic is not being analyzed.
Solution: In the network adapter configuration of the guest system, set IPv4 TSO Offload to Disabled.
The following PowerShell command checks if Large Send Offload (LSO) is enabled:
1 | Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*" |

Execute the following PowerShell command to disable Large Send Offload (LSO). This will cause a brief network connection interruption.
1 | Disable-NetAdapterLso -Name %NameNetzwerkAdapter% |

Large Send Offload (LSO) is now disabled.
1 | Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*" |

Good to Know
Delay Sensor Update
The sensor regularly checks for updates, downloads them and installs them automatically. By enabling the Delayed Update feature, this process is postponed by 72 hours. This allows administrators to implement update rings for the Microsoft Defender for Identity (MDI) sensor within the infrastructure.
Select Device (1) under Microsoft Defender Portal (https://security.microsoft.com) > Settings > Identities > General > Sensors and click Enable delayed update (2).

Follow me on LinkedIn and Bluesky to always stay updated on my recent posts.
Was this post helpful to you? Show your enthusiasm with the delightful aroma of a freshly brewed coffee for me!