When Raven and I are out in my backyard, she's always on high alert, her keen senses picking up on every subtle change in her environment. Just like Raven, Microsoft Defender for Identity (MDI) is constantly on the lookout, sniffing out potential threats to your network. Whether it's an unusual login attempt or a suspicious movement within your system, MDI is there to detect and alert you to any signs of trouble.

Raven's ability to sense danger is akin to MDI's advanced threat detection capabilities. She can differentiate between a harmless passerby and a potential predator, much like how MDI distinguishes between normal user behavior and potential security breaches. This vigilant monitoring ensures that any threat is identified and addressed before it can cause harm, keeping your network as safe as Raven keeps our home.

Just as I trust Raven to protect us from unseen dangers, you can rely on MDI to safeguard your network from cyber threats. With its continuous monitoring and real-time alerts, MDI acts as your loyal guardian, always ready to spring into action at the first sign of trouble. The following blog will help you roll out MDI, whether you are new to MDI or a seasoned expert. So, as you enjoy the peace of mind that comes with having Raven by your side, you can also rest easy knowing that MDI is tirelessly working to keep your digital environment secure.

 

Update for 2025+: Defender for Identity Sensor Architecture (v2 vs v3) and SAM-R Removal

Two Defender for Identity sensor models

Classic sensor (v2.x)

• Installed manually using an installer and access key
• Required for:
• Windows Server 2016 Domain Controllers
• AD FS
• AD CS
• Microsoft Entra Connect servers
• Requires ongoing sensor lifecycle management

Unified sensor (v3.x)

• Activated, not installed
• Integrated with Microsoft Defender for Endpoint
• Supported on:
• Windows Server 2019, 2022, and 2025 Domain Controllers (with required cumulative updates)
• No MSI, no access key, no reboot required

This architectural change simplifies deployment on modern Domain Controllers but introduces an important planning step: choosing the correct sensor model per server.

Deployment Decision Guide: Which Sensor Should I Use?

Use the following guidance when planning or updating your Defender for Identity deployment, remember that the MDE agent must be deployed on the Domain Controller first.

Domain Controllers

• Windows Server 2019 / 2022 / 2025 → Defender for Identity sensor v3.x
• Windows Server 2016 → Defender for Identity sensor v2.x

Other Identity Infrastructure

• AD FS → v2.x
• AD CS → v2.x
• Microsoft Entra Connect → v2.x

Introduction to Microsoft Defender for Identity (MDI) 

Microsoft Defender for Identity (MDI) is a security solution designed to help protect your organization from advanced threats, compromised identities, and insider actions. By leveraging on-premises Active Directory signals, MDI provides comprehensive monitoring and analysis to detect suspicious activities and potential security breaches. This tool is essential for maintaining the integrity and security of your network infrastructure.

Deploying MDI involves several critical steps, starting with a thorough performance and sizing review to ensure your Domain Controllers (DCs) can handle the additional load. The MDI agent collects and analyzes data from your DCs, which requires adequate processing power and network capacity. Proper planning and execution of this deployment will help you maximize the effectiveness of MDI in safeguarding your environment.

This guide will walk you through the entire deployment process, from initial preparation to the final configuration. Whether you are an experienced administrator or new to MDI, this document provides the necessary information and resources to successfully deploy and manage Microsoft Defender for Identity in your organization.

MDI Documentation

Microsoft Defender for Identity documentation - Microsoft Defender for Identity | Microsoft Learn

Monitored Activities

Monitored activities - Microsoft Defender for Identity | Microsoft Learn

Security alert name and mapping with MITRE

https://learn.microsoft.com/en-us/defender-for-identity/alerts-overview#security-alert-name-mapping-and-unique-external-ids

Integration with the XDR Portal

Microsoft Defender for Identity in the Microsoft Defender portal - Microsoft Defender XDR | Microsoft Learn

Note 1: MDI data is available for advanced hunting using KQL queries within the XDR portal.

Note 2: The name of this product started out as Advanced Threat Analytics (ATA). The ATA reference may pop up, but it is now MDI.

Deploying MDI

This guide is designed to assist administrators who are deploying Microsoft Defender for Identity for the first time, using the new Defender for Identity PowerShell Module.

Performance and Sizing Review

Before deploying, it's crucial to ensure that your Domain Controllers (DCs) can handle the load imposed by the Defender for Identity (MDI) agent. To assist with this, Microsoft provides a load/performance testing tool. This sizing tool can be executed on either a desktop or a DC and must be run by a domain administrator.

You can find the MDI sizing tool at the following locations:

GitHub - microsoft/Microsoft-Defender-for-Identity-Sizing-Tool

Plan capacity for deployment - Microsoft Defender for Identity | Microsoft Learn

The tool should be run 24 hours to capture data from all DCs globally. It only needs to be executed on a single device, and the results will be compiled into a single .xlsx file.

To run the sizing tool against a single domain, extract the tool and use the following command in a command prompt, after navigating to the directory where the tool is located:

C:\temp\TriSizingTool.exe -UseCurrent=UserDomain

 

 

The screen grabs below are from a simple domain within my lab environment, providing a sample of what the output file looks like (with 2 tabs). The tool only ran for a couple of hours, so the sample size is smaller than recommended.

ATA Summary tab can be ignored.

Azure ATP Summary tab

Please walk through the findings and identify any recommendations within the Azure ATP summary tab. Make adjustments where necessary.

Enabling Defender for Identity within the XDR Portal

The first time an administrator browses to the “Identities” section:

They will get an error on the Dashboard

 

• Browse to System > Settings

• Identities

 

This will bring up a screen notifying the administrator the environment is now being configured.

Once complete, you should see a Defender for Identity configuration page.

 

Prerequisites

Once the hardware is confirmed to be sufficient, configuration changes need to be made. Initially, deploying Microsoft Defender for Identity (MDI) required multiple configuration changes, which increased the risk of human error. However, the recent release of a PowerShell module for MDI has greatly simplified this process.

Manual configuration of the Active Directory Domain Services (AD DS) environment involves numerous steps. As the complexity of these steps increases, so does the potential for human error. Utilizing the PowerShell module can help mitigate these risks by streamlining the configuration process.

Prerequisites - Microsoft Defender for Identity | Microsoft Learn

Configure audit policies for Windows event logs - Microsoft Defender for Identity | Microsoft Learn

 

Updated Prerequisites for Defender for Identity v3

The unified sensor introduces several new prerequisites that should be reviewed before activation:

• Microsoft Defender for Endpoint must be onboarded on the Domain Controller
• Supported OS: Windows Server 2019 or later
• Required cumulative updates must be installed
• Defender Antivirus may run in active or passive mode
• Some features (for example VPN integration and syslog forwarding) behave differently compared to v2

 

MDI PowerShell Module

Introducing the new PowerShell Module for Microsoft Defender for Identity

PowerShell Gallery | DefenderForIdentity 1.0.0.2

DefenderForIdentity Module | Microsoft Learn

Note: To use the MDI PowerShell module, it must be run on a server or Domain Controller with both the Active Directory and Group Policy modules installed. This new module simplifies the configuration of auditing and permissions within your environment, automating the entire process for the administrator. The steps outlined in this process are designed for a single domain.

Install-Module DefenderforIdentity

After downloading and installing the PowerShell module, the administrator should import it using the following command:

Import-Module DefenderForIdentity

Once the module is imported, the administrator can test the AD DS environment for MDI readiness.

From an administrator PowerShell command line, run:

• New-MDIConfigurationReport -Path C:\Temp -OpenHtmlReport

Note: If you are prompted for the Identity name, this is the Identity to be used to run the installed sensor.

This will generate an HTML report.

Now that a report has been generated, there are a number of PowerShell commands for the DefenderForIdentity module. This list can be found from the link above, or you can just run a get-command for a list.

Get-Command -module DefenderForIdentity

Service Account Creation and Installation

Note: If using the version 3 agent, a service account is NOT needed.

Even though the example above reports that changes need to be made, it doesn't account for the user or service account that will be used. Using a user account with elevated permissions is discouraged. Instead, a group Managed Service Account (gMSA) with limited permissions is recommended. The only permissions needed are:

• Read Only for Active Directory
• Read Only for Deleted Objects Container

In the first example, I ran a test against my Domain Administrator account. Notice that there are two "False" returns; ideally, everything should be set to "True" when running the specific test for the identity.

Test-MdiDSA -Identity pbbergs -verbose -detailed

 

While it's possible to set up a group Managed Service Account (gMSA) manually, using the DefenderForIdentity PowerShell cmdlet ensures that all configuration settings are completed correctly. This cmdlet also creates a group that grants Domain Controllers the ability to access the gMSA password.

• New-MDIDSA -Identity “gMSA-MDI” -GmsaGroupName “gMSA-MDI-Grp” -Verbose

Once I set up a new gMSA account, I re-ran the Identity test. As shown below, the gMSA account is not overly privileged and passes the test.

https://learn.microsoft.com/en-us/defender-for-identity/deploy/create-directory-service-account-gmsa#prerequisites-grant-permissions-to-retrieve-the-gmsa-accounts-password

Note: If you plan on using Active Directory Federation Services (ADFS) or Active Directory Certificate Services (ADCS), the security group created in the previous step will need to include the ADFS and/or ADCS servers.

Next, the gMSA identity needs to be added to the Identity blade within the XDR portal.

• Security.microsoft.com > Settings > Identities > General > Directory Service Accounts

• Click on “+ Add Credentials”

• Complete the Information to update the new Identity
• Click “Save”

The portal is now ready to accept Domain Controllers, ADFS and/or ADCS servers.

Validate the Network Infrastructure

Note: If using the version 3 agent. The MDE agent already has established connectivity to XDR. So, there is nothing to do in this section.

Before deploying the sensor, it's important to complete tests to ensure that the sensors can communicate with Azure and its logging engine. To facilitate this, we can use the new PowerShell cmdlet from the MDI PowerShell module, Test-MDISensorApiConnection.
Test-MDISensorApiConnection (DefenderForIdentity) | Microsoft Learn

Before running the PowerShell command, you will need to know the “WorkspaceName” since this is used within the parameter “-SensorApiURL”. It is built via the following:
"https://<your_workspace_name>sensorapi.atp.azure.com"

To find “your_workspace_name”

• XDR portal > Settings > Identities > General > About

If the device has the MDI sensor installed, then the -BypassConfiguration is not needed.

The parameter then is concatenated to the result of:

https://mngenvmcap99999sensorapi.atp.azure.com

To complete the validation test

• Bring up an administrative PowerShell command box

o   Enter Test-MDISensorApiConnection -Verbose -SensorApiUrl https://mngenvmcap99999sensorapi.atp.azure.com -BypassConfiguration

The result should return a value of “True” if the device has access to Azure.

If the device has the MDI sensor installed, then the -BypassConfiguration is not needed.

Configuration Changes to Prepare for the Deployment of the MDI Sensor

Let’s do a test of the auditing settings of the domain. This can be completed by running:

• Test-MDIConfiguration -Mode Domain -Configuration NTLMAuditing

If we look at the Active Directory Group policy GUI, we can see that there are no policies in place for MDI at this time within the domain.

We could manually go in and build the policies needed -or- we could use the Set-MDIConfiguration and let the PowerShell cmdlet do the work for us.

There are other configuration settings that can also be configured which include:

• ADFSAuditing
• AdvancedAuditPolicyCAs
• AdvancedAuditPolicyDCs
• CAAuditing
• ConfigurationContainerAuditing
• DomainObjectAuditing
• NTLMAuditing
• ProcessorPerformance

• All (The complete list from the above bullets)

Configuring the Power Option to High Performance

One of the MDI PowerShell Module options (If used) can change the Domain Controller’s Power Option to “High Performance” via GPO. This is recommended for optimal performance when running the MDI sensor.

Updating the Auditing Configuration of the Active Directory Environment

Instead of changing these configurations one at a time, the “All” setting can be used which will configure the environment and build the GPOs as needed.

• Set-MDIConfiguration -Mode Domain -Configuration All -Identity gMSA-MDI -verbose

 

Note: In my environment I don’t have Exchange, ADFS or Certificate Services installed.

Taking another look at the Group policy shows that there is now a complete set of policies in place for auditing.

Notice that the system isn’t aware of whether or not a CA is installed so it added a CA policy to the base of the domain. If you aren’t using a CA these can be left as is or the link removed from the root of the domain.

 

Lateral Movement detection via SAM-R has been removed

Microsoft disabled SAM‑R–based collection for lateral movement path mapping in Defender for Identity in May 2025. This was automatic and required no admin action. The feature that relied on SAM‑R (remote enumeration of local admins) is no longer actively used to build lateral movement maps.

Configure SAM-R to enable lateral movement path detection - Microsoft Defender for Identity | Microsoft Learn

 

Review the Configuration

Running the following cmdlet will show that ADFS fails, causing the entire test to fail. This failure occurs because ADFS requires manual linking of the GPO to the appropriate OU. If you aren’t using ADFS, you can skip this step. However, ensure that the 'Microsoft Defender for Identity – Remote SAM Access' GPO is correctly configured and linked. Once this is done, the Remote SAM Access test should pass successfully.

• Test-MDIConfiguration -Mode Domain -Identity gMSA-MDI -Configuration All -Verbose

In my instance, it indicates that Entra Connect is not set up to be monitored. However, this is irrelevant since I am not using it in my environment. Therefore, the Domain Controllers' (DCs) sensors are now ready for deployment.

I want to run my HTML report one more time to have a hard copy for later use if needed. This report will verify that everything is ready for completion and can be saved for historical purposes.

• New-MDIConfigurationReport -Path C:\temp -OpenHtmlReport

Note: If you are prompted for the Identity, this is the Identity to be used to run the installed sensor.

As can be seen this warns about Entra Connect not being monitored, but we already knew that.

Installing the Sensor

Installing the Sensor with the GUI (V2 Agent)

For this example, the installation of the sensor will be done manually via the GUI. In a corporate environment, this process can be automated using a Device Management tool.

Note: You may still see legacy "Azure ATP" naming in tools and installers; this is expected and supported.

Browse to:

• Security.microsoft.com > Settings > Identities > General > Sensors
• Click on “+ Add sensor”

A new box will pop up, this will provide the agent installation software and “Access key”.

• Click on “Download installer” and save to a location that can be accessed by the DC(s)
• Copy the “Access key” and place it in a secure location that is also accessible by the DC(s)

• Login to the DC that you want to install the MDI agent on to
• Start up an administrative command shell and browse to the MDI agent location
• Execute “Azure ATP Sensor Setup.exe”

An installation window should pop up

• Select your “Language”
• Select “Next”

• Verify that the sensor is installed on the correct service type
• Select “Next”

• Copy and paste the “Access key” (Copied earlier when downloading the Sensor binary)
• Click “Install”

 

Installation should begin

• Click “Finish”

The sensor has now been successfully installed. Repeat this process for any other Domain Controllers (DCs), ADFS, or ADCS servers. Be sure to update the security group with the server names related to ADFS and ADCS.

In the next screen grab, you will notice that I now have two DCs being monitored. The first was installed yesterday, and the second was installed a few minutes ago. If you look at the “Health status,” you can see that the most recent installation is going through a review process and initially reports as “Not healthy.” If everything is functioning correctly on the device (DC, ADFS, or ADCS), the health status should change to “Healthy” within a few minutes. In my case, it took approximately 5 minutes.

Installing the Sensor from a Deployment Tool

There is the ability to install via a management tool the Sensor which includes the ability to be in “Silent” mode. Complete details and parameter options can be found at:
https://learn.microsoft.com/en-us/defender-for-identity/deploy/install-sensor#commands-for-running-a-silent-installation

 

PowerShell syntax:
.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"

Proxy Configuration

If your enterprise uses a proxy, the MDI Sensor can be configured to utilize this appliance. Although I don't have a proxy environment available, I can still walk you through the steps to configure your MDI Sensor to use it.

To configure a \ silent installation of the MDI sensor with a proxy, you need to include the proxy configuration in the command line using the appropriate parameters.

"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<access key>" ProxyUrl=http://: ProxyUser="" ProxyPassword=""</access key>

 Explanation of Parameters:

• AccessKey="<Access Key>": Your MDI instance access key.
• ProxyUrl="http://<proxy-address>:<port>": The full URL of your proxy server.
• ProxyUser="<username>": (Optional) Username for proxy authentication.
• ProxyPassword="<password>": (Optional) Password for proxy authentication.

Important: Make sure to replace the placeholders (<Access Key>, <proxy-address>, etc.) with your actual values. Also, be cautious with storing credentials in plain text—consider using secure methods for deployment like encrypted scripts or managed identities if possible.

 

If you want to add the Proxy after deployment:

As of this writing, there isn't a Group Policy setting to control the MDI Proxy Configuration, so we will use PowerShell. If deploying the sensor via a management tool, the sensor configuration can be added as an additional step in its deployment.

Let’s verify that there isn’t currently any proxy configuration at this time.

• Get-MDISensorProxyConfiguration -Verbose

As can be seen, there is no configuration set up.

Now we can configure the Sensor to:
## Insert a proxy server into the Sensor deployment
$proxyServer = http://proxy.contoso.com:8080
$Credential = "FakeCredentials"
Set-MDISensorProxyConfiguration -ProxyUrl $proxyServer -ProxyCredential $Credential -Verbose

The Sensor tried to connect to the proxy and failed, but we can still verify the configuration worked.

• Get-MDISensorProxyConfiguration -Verbose

Note: For readability the window was reduced in size

If you ever need to clear the Proxy settings

• Clear-MDISensorProxyConfiguration -Verbose

Once again, let’s look at its Proxy configuration

• Get-MDISensorProxyConfiguration -Verbose

It is once again clean from any Proxy configuration settings.

 

Installing the Sensor with the GUI (V3 Agent)

For Domain Controllers running Windows Server 2019 or later, Defender for Identity is now deployed using a portal‑based activation model.

High-level v3 deployment flow

1. Domain Controller is onboarded to Microsoft Defender for Endpoint
2. Defender for Identity automatically detects the DC as eligible
3. Administrator activates Defender for Identity from the Microsoft Defender portal
4. Sensor becomes active without:
• MSI installation
• Access keys
• Server reboot

Browse to Settings > Identities > Sensors

• Add Sensor
• "Activate servers"

Once activated there is the option to either have the system automatically add all eligible servers or manually select servers to activate.

Chose the option, in the example below manual is chosen.

Select "Activate"

Sensor status can now be verified. In the screenshot below it can be seen that the new agent is onboarding the DC. Also note the version of each DC.

 

Post Deployment Configuration for both agents

Threshold Configuration for Alerts

Threshold configuration in Microsoft Defender for Identity (MDI) allows administrators to customize the sensitivity of specific alerts to better align with their organization's security needs. By adjusting alert thresholds, you can control the volume of alerts generated, reducing false positives and focusing on more critical threats. The thresholds can be set to High, Medium, or Low, with High being the default setting that minimizes false positives. Medium and Low settings increase the number of alerts, which can be useful during comprehensive testing or in environments with higher security requirements. These configurations help ensure that MDI provides relevant and actionable alerts, enhancing the overall security posture of the organization.

To configure the available alerts:

• Settings > Identity > General > Adjust alerts thresholds

Entity Tags 

Entity tags in Microsoft Defender for Identity (MDI) are crucial for enhancing the security and monitoring capabilities within an organization. These tags help categorize and prioritize different entities, such as users, devices, and servers, based on their sensitivity and role within the network. By appropriately tagging entities, MDI can more effectively detect and respond to potential threats, ensuring that high-value assets receive the necessary attention and protection. The primary types of entity tags include Sensitive, Honeytoken, and Exchange server tags, each serving a unique purpose in the overall security strategy.

Sensitive Tags

Sensitive tags are used to identify high-value assets that require heightened security measures. These tags are automatically applied to entities that are part of critical Active Directory groups, such as Administrators, Domain Admins, and Schema Admins. Additionally, administrators can manually tag other users, devices, or groups as sensitive to ensure they receive appropriate monitoring and protection

Honeytoken tags

Honeytoken tags are a strategic tool used to detect malicious activity by setting traps for attackers. Honeytoken accounts are typically dormant and have no legitimate activity associated with them. Any authentication attempt involving a honeytoken account triggers an alert, allowing security teams to quickly identify and respond to potential threats. These tags are particularly useful for identifying lateral movement and other suspicious behaviors within the network.

Exchange server tags

Exchange server tags are automatically applied to devices running Microsoft Exchange Server, recognizing them as high-value targets due to their critical role in email communication and data storage. By tagging these servers, MDI ensures they are closely monitored for any signs of compromise or unauthorized access. Administrators can also manually tag other devices as Exchange servers if needed.

 

Actions and Exclusions

The "Actions" and "Exclusions" settings are essential components for customizing the security response and detection framework. The "Actions" setting enables administrators to define automated responses to identified threats, ensuring timely and consistent mitigation efforts. Meanwhile, the "Exclusions" setting allows for the exclusion of specific entities from detection rules, helping to minimize false positives and streamline threat management.

Actions

The "Actions" setting in Microsoft Defender for Identity is pivotal for automating the response to security threats. By configuring automated responses, administrators can ensure that predefined actions are taken immediately when a threat is detected. This can include actions such as isolating a compromised device, disabling a user account, or triggering an alert to the security team. Automated responses help in minimizing the time between detection and mitigation, thereby reducing the potential impact of security incidents. This proactive approach is essential for maintaining a secure and resilient identity infrastructure.

Exclusions

The "Exclusions" setting allows administrators to exclude specific entities, such as IP addresses, devices, or user accounts, from certain detection rules. This is particularly useful for reducing false positives that can arise from legitimate activities being flagged as suspicious. For example, security scanners or certain administrative tasks might trigger alerts that are not indicative of a real threat. By configuring exclusions, these benign activities can be ignored, allowing the security team to focus on genuine threats. Exclusions can be set globally or by specific detection rules, providing flexibility in managing the security landscape.

Notifications

Health Issue Notifications

Users can be notified of health issues. This is configured in the settings page.

• Portal > Settings > Notifications > Health issues notifications > Add recipient email

Alert Notifications

Administrators can be notified of Alerts. This is configured in the settings page.

• Portal > Settings > Notifications > Alert notifications > Add recipient email

Updated Guidance (November 2025)

Microsoft Defender for Identity (MDI) continues to be a critical component for detecting identity-based threats in hybrid environments. While the fundamentals remain the same, several enhancements introduced in 2025 simplify deployment and improve coverage. This update highlights what’s new.

1. Unified Sensor (v3.x)

• • The Unified Sensor is now generally available for Windows Server 2019 and later.
    • It combines identity and endpoint protection into a single component, reducing complexity.
    • If Defender for Endpoint for Servers is already deployed, enabling MDI is now a one-click activation.

2. Expanded Sensor Coverage

• • Sensors can now be installed on AD FS, AD CS, and Microsoft Entra Connect servers.
  • This ensures visibility across critical identity infrastructure beyond domain controllers.

3. Identity Scoping

• • Granular scoping by Organizational Units (OUs) and domains is now supported.
  • Useful for large enterprises and government environments where segmentation is required.

4. Security Posture Integration

• • MDI now integrates with Microsoft Secure Score to surface posture checks:
    • Leaked credentials
    • Inactive service accounts
    • Weak or discoverable passwords

5. Unified Alerting Experience

• • Alerts now follow the Microsoft Defender XDR format, providing consistency across security products.

6. Sensor Management API

• • A new API allows remote sensor management:
    • List sensors
    • Update settings
    • Retrieve deployment packages
  • Ideal for automation and large-scale deployments.

Deployment Recommendations

• Include AD CS and Entra Connect servers in your sensor deployment plan.
• Review identity scoping options for better segmentation.
• Leverage Secure Score posture insights to strengthen identity hygiene.
• Update operational scripts to use the Sensor Management API for automation.

Mixed Environments Are Normal (and Supported)

Most organizations will operate in a mixed sensor environment during Domain Controller modernization—and this is fully supported.

It is expected to see:

• v3 sensors on Windows Server 2019 / 2022 / 2025 Domain Controllers
• v2 sensors on Windows Server 2016 Domain Controllers
• v2 sensors on AD FS, AD CS, and Entra Connect servers

Important clarification:
A single server cannot run both v2 and v3 sensors, but different Domain Controllers in the same forest can run different sensor versions.

This allows organizations to:

• Introduce new DCs using v3 immediately
• Retire older DCs over time
• Avoid forced upgrades or re‑architecture

 

Server 2025 and Directory Service Object Auditing

If you deployed Microsoft Defender for Identity (MDI) before the unified v3.x sensor was available, it is expected to later see health issues such as:

• Directory Service Object Auditing is not enabled as required
• Directory Services Advanced Auditing is not enabled as required

This behavior is by design and is not related to Windows Server 2025 specifically.

Root Cause: Legacy (v2.x) Sensor Did Not Auto‑Configure Auditing

The original, standalone Defender for Identity sensor (v2.x) did not automatically configure Windows auditing or directory service SACLs. Instead, administrators were required to manually configure:

• Advanced Audit Policy subcategories
• Directory Service auditing
• System Access Control List (SACL) entries on the domain root and specific containers

If any of these were missing, Defender for Identity would surface health issues but would not remediate them automatically. [learn.microsoft.com]

As a result, environments that:

• Installed the sensor years ago
• Relied on partial GPO configuration
• Drifted over time due to GPO changes

often functioned “well enough” until auditing validation became stricter.

What Changed With the Unified Sensor (v3.x)

Beginning in November 2025, Microsoft introduced an opt‑in feature called Automatic Windows auditing configuration for Defender for Identity unified sensors (v3.x).

When enabled, this feature automatically:

• Detects missing or incorrect audit policies
• Configures required Advanced Audit Policy subcategories
• Adds required SACL entries to:
• The domain root
• The Configuration container
• Other required directory objects
• Clears related Defender for Identity health issues

This capability does not exist for the legacy v2.x sensor and only applies to domain controllers running the unified sensor.

Why the Error Appears After Upgrading or Adding New Domain Controllers

Many customers first notice these auditing errors when they:

• Promote a new domain controller (for example, Windows Server 2025)
• Upgrade from the legacy MDI sensor to the unified v3.x sensor
• Enable stricter health validation in Defender for Identity

At that point, Defender for Identity validates auditing against current requirements, not historical configuration. Any missing Directory Service Object Auditing settings are surfaced as health issues until corrected.

Important Clarification About Windows Server 2025

Windows Server 2025 is not the cause of the auditing error.

Defender for Identity auditing requirements are based on Active Directory auditing, which is consistent across supported Windows Server versions. A Windows Server 2025 domain controller running the unified sensor behaves the same as Server 2019 or 2022 in this context.

Recommended Resolution

Microsoft now recommends enabling Automatic Windows auditing configuration in the Defender portal for environments using the unified sensor. Once enabled, Defender for Identity automatically remediates auditing gaps and dismisses related health issues without requiring manual GPO or PowerShell changes.

Why SAM‑R Auditing Was Previously Recommended — and Why It’s No Longer Required

In earlier versions of Microsoft Defender for Identity (formerly Azure Advanced Threat Protection), guidance often included enabling SAM‑R (Security Account Manager Remote) auditing as part of the recommended prerequisites. If you deployed Defender for Identity prior to the unified sensor (v3.x), you may still see references to this requirement in older documentation and blog posts—including my own.

This recommendation has since changed, and that change is intentional.

Why SAM‑R Auditing Was Originally Required

The legacy Defender for Identity sensor (v2.x) relied heavily on network-based protocol inspection, including SAM‑R traffic, to detect identity reconnaissance and enumeration techniques. At the time:

• SAM‑R was commonly used by attackers to enumerate users and groups in Active Directory.
• Monitoring SAM‑R activity provided visibility into suspicious discovery behavior.
• Enabling SAM‑R auditing helped Defender for Identity generate detections based on these legacy techniques.

As a result, early deployment guides recommended ensuring SAM‑R activity was observable and auditable rather than restricted.

What Changed

Over time, Microsoft identified that SAM‑R itself represents a legacy attack surface. While monitoring it provided detections, allowing or auditing SAM‑R also meant leaving a weaker protocol accessible in the environment.

With the introduction of the Defender for Identity unified sensor (v3.x)—built on the Microsoft Defender for Endpoint platform—the detection model fundamentally changed:

• The unified sensor no longer relies on SAM‑R network inspection for detections.
• Identity signals are now derived from endpoint telemetry, kernel signals, and modern Windows auditing, not legacy protocols.
• Microsoft’s security guidance shifted from monitoring unsafe protocols to reducing or eliminating their use entirely.

As part of this shift, SAM‑R auditing is no longer required and is no longer recommended.

Why You May See SAM‑R‑Related Warnings During Upgrades

Organizations that deployed Defender for Identity before v3.x, especially when introducing new domain controllers (such as Windows Server 2025), may notice health warnings or auditing messages related to SAM‑R.

This is not caused by Windows Server 2025.

Instead, it is the result of:

• Stricter health validation in modern Defender for Identity deployments
• A move away from legacy protocol dependency
• Detection logic that now assumes SAM‑R should be restricted rather than observed

In other words, these warnings reflect Defender for Identity hardening, not an operating system regression.

Current Recommendation

For modern deployments:

• Do not enable SAM‑R auditing
• Restrict or eliminate SAM‑R access where possible
• Use the Defender for Identity unified sensor (v3.x) on supported domain controllers
• Rely on modern identity detections rather than legacy protocol monitoring

Microsoft Defender for Identity now provides stronger, safer detections without SAM‑R, reducing exposure to downgrade and reconnaissance techniques while aligning with current identity security best practices.

Where to Find the SAM‑R Setting

The SAM‑R (Security Account Manager Remote) configuration is not managed in Microsoft Defender for Identity. It is a Windows security policy that exists on the endpoint or is applied through Group Policy.

Domain‑wide (Group Policy)

Use Group Policy Management Editor (gpmc.msc):

Computer Configuration
→ Windows Settings
→ Security Settings
→ Local Policies
→ Security Options
→ Network access: Restrict clients allowed to make remote calls to SAM

Single Server / Local Device

Use Local Security Policy (secpol.msc):

Security Settings
→ Local Policies
→ Security Options
→ Network access: Restrict clients allowed to make remote calls to SAM

Registry Location (Verification Only)

This policy maps to the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value name: RestrictRemoteSAM

Summary of SAM-R Recommendation

SAM‑R auditing was once recommended because early Defender for Identity sensors depended on it. Today, that dependency no longer exists. The unified sensor architecture intentionally moves away from SAM‑R in favor of modern, secure telemetry.

If you are updating older deployment guidance, removing SAM‑R auditing is not only safe—it is the correct and recommended approach.

Summary of Microsoft Defender for Identity Deployment

Deploying Microsoft Defender for Identity (MDI) involves several critical steps, from verifying hardware capabilities to configuring the environment and installing sensors. By following this comprehensive guide, administrators can ensure a smooth and efficient deployment process. The use of the MDI PowerShell module significantly reduces the complexity and risk of human error, streamlining the configuration of auditing and permissions within the Active Directory Domain Services (AD DS) environment.

The initial phase of the deployment focuses on performance and sizing reviews to confirm that your Domain Controllers (DCs) can handle the load imposed by the MDI agent. This step is crucial to ensure that the deployment does not negatively impact the performance of your network. The MDI sizing tool provides valuable insights and helps administrators make informed decisions about their infrastructure.

Once the hardware is verified, the configuration phase begins. The PowerShell module for MDI simplifies this process by automating many of the necessary steps, reducing the potential for human error. This includes setting up a group Managed Service Account (gMSA) with the appropriate permissions, ensuring that the account is not overly privileged and meets the security requirements.

The installation of the MDI sensors is the next critical step. This guide covers both manual installation via the GUI and automated deployment using a Device Management tool. Ensuring that the sensors are correctly installed and configured is essential for effective monitoring and threat detection. The guide also addresses the configuration of proxy settings if your enterprise uses a proxy, providing a comprehensive approach to deployment.

The value of deploying MDI lies in its ability to provide robust security monitoring and threat detection. By leveraging on-premises Active Directory signals, MDI helps protect your organization from advanced threats, compromised identities, and insider actions. The automated processes and detailed configuration steps outlined in this guide ensure that your environment is well-prepared to handle potential security breaches, ultimately enhancing the overall security posture of your organization.

In summary, the deployment of Microsoft Defender for Identity is a critical step in safeguarding your network infrastructure. By following this guide, administrators can ensure a thorough and efficient deployment, leveraging the power of MDI to detect and respond to security threats effectively. The streamlined processes and automation provided by the PowerShell module make this deployment accessible and manageable, even for those new to MDI.

 

In conclusion, just as Raven's vigilant presence in our backyard ensures our safety, Microsoft Defender for Identity (MDI) provides robust protection for your network. By continuously monitoring and analyzing activities, MDI helps you stay ahead of potential threats, ensuring your digital environment remains secure. Whether you're new to MDI or a seasoned expert, implementing this powerful tool can significantly enhance your organization's security posture.

Additionally, it's important to note that if you own a Microsoft 365 E5, A5, F5 Security, or G5 license, you already have access to MDI. This means you can leverage its advanced threat detection capabilities without any additional cost. So, take advantage of this valuable resource and ensure your network is as well-guarded as my home is with Raven on patrol.

 

Note:
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 

Thanks to David Loder for proof reading and edit checks for this blog.