Deploy Defender for Identity sensors on domain controllers and AD CS

To deploy Microsoft Defender for Identity, put a sensor on every domain controller (including read-only DCs) and on each online AD CS server that runs the Certification Authority role service, plus AD FS and Microsoft Entra Connect servers. On Windows Server 2019 or later with the July 2026 or later cumulative update, activate sensor v3.x from the Sensor management tab in the Microsoft Defender portal; on Windows Server 2016 or earlier, install sensor v2.x from the downloaded package with the workspace access key. Then turn on Windows event auditing and confirm the sensors show Running and that identity events appear in advanced hunting.

Who this is for and what you will have

This guide is for Active Directory and security administrators rolling out Defender for Identity across an on-premises forest. It covers the decisions that trip people up: which sensor version goes where, why AD CS servers need their own sensor and auditing, and how to prove the deployment works before you rely on it for detections.

At the end you will have:

• Sensors on every domain controller and online issuing CA, using the right version for each server.
• Windows event auditing configured for domain controllers and AD CS.
• A validated deployment, with health issues cleared and identity data visible in Defender XDR.

Defender for Identity covers the on-premises half of identity protection. For devices, the matching step is onboarding Windows devices to Defender for Endpoint with Intune.

Choose the sensor version per server

Microsoft's deployment guidance makes the decision on operating system, not server role.

Points to weigh before choosing v3.x:

• It doesn't support VPN integration or syslog notifications, and has limitations with Azure ExpressRoute.
• It can't be activated on a server that already has v2.x; use the migration flow instead.
• If you deploy v3.x only on AD FS, AD CS or Entra Connect servers, you must also have at least one v3.x sensor on a domain controller.
• It uses LocalSystem for reading Active Directory and for remediation actions. If any sensor in the workspace is v3.x, Microsoft says to select Automatically use the sensor's local system account for all sensors.

Prerequisites

Licensing and roles

Defender for Identity requires one of: Enterprise Mobility + Security E5/A5, Microsoft 365 E5/A5/G5, Microsoft 365 E5/A5/G5/F5 Security, Microsoft 365 F5 Security + Compliance, or a standalone Defender for Identity license (listed for v2.x). The F5 licenses also require Microsoft 365 F1/F3 or Office 365 F3 and EMS E3. You need a Security Administrator, or for v3.x the Unified RBAC permissions System settings (Read and manage) and Security settings (All permissions).

Server requirements

On virtual machines, all memory must be allocated to the VM at all times: turn off Enable Dynamic Memory on Hyper-V, and on VMware reserve all guest memory. For v2.x on VMware, disable Large Send Offload on the VM's NIC.

Network

Sensor v2.x needs outbound HTTPS on TCP 443 to your workspace sensor API URL, in the format https://<workspace-name>sensorapi.atp.azure.com, either directly, through a proxy (SSL inspection isn't supported), through ExpressRoute Microsoft peering with the Defender for Identity BGP community, or by allowing the AzureAdvancedThreatProtection service tag IP ranges. Internally it needs DNS (53), and for name resolution at least one of NTLM over RPC (TCP 135), NetBIOS (UDP 137) or RDP (TCP 3389) to devices on the network.

Sensor v3.x uses the same URLs as Microsoft Defender for Endpoint, so follow the Defender for Endpoint streamlined or standard connectivity URL lists instead.

Test readiness first

Run Microsoft's Test-MdiReadiness.ps1 script from the Microsoft-Defender-for-Identity GitHub repository, or from Identities > Tools (preview) in Defender XDR. It checks prerequisites including auditing, so you start with a list of gaps rather than a page of health alerts.

Path A: activate sensor v3.x

Automatic activation

In the Microsoft Defender portal, go to Settings > Identities > Advanced features and turn on Automatic sensor v3.x activation. Defender for Identity then activates the sensor on eligible domain controllers, AD FS, AD CS and Entra Connect servers as they're onboarded to Defender for Endpoint. Turn on Automatic Windows auditing configuration on the same page. Both settings appear only once the tenant has an active license that includes Defender for Identity.

Manual activation

1. Open the Sensor management tab of the On-premises page (https://security.microsoft.com/securitysettings/identities).
2. Review the action cards, for example Domain controllers ready for activation and AD CS, AD FS, or Entra Connect servers ready for activation.
3. Select the server, select Activate and confirm.

Activation doesn't install a package or require a restart. The first v3.x activation in a tenant can take up to an hour to show Running; later ones appear within five minutes.

Domain controllers that aren't in Defender for Endpoint

For an eligible DC that isn't onboarded to Defender for Endpoint and has no v2.x sensor:

1. Make sure the DC can reach the Defender for Endpoint streamlined connectivity URLs.
2. On Sensor management, select Download onboarding package, expand Windows Server 2019 or later, enter a Package name and select Generate package.
3. Download the package and copy the access key. Regenerating the key invalidates the old one.
4. Copy the package to the DC, extract it keeping the resources subfolder, and run:

Set-Location .\DfiOnboarding
.\DefenderForIdentityV3StandaloneOnboardingScript.cmd

5. Enter the access key when prompted.

AD CS servers don't have this option; onboard them to Defender for Endpoint first, then activate.

Path B: install sensor v2.x

1. On Sensor management, select Download onboarding package, expand Windows Server 2016 or earlier and save the ZIP.
2. Copy the Access key. It's a one-time registration secret; after deployment the sensor authenticates with certificates. Microsoft recommends regenerating it regularly, which doesn't affect deployed sensors.
3. Copy the ZIP to the server and extract it. Installing directly from the ZIP fails.
4. Run Azure ATP sensor setup.exe as administrator. The wizard detects whether the server is a DC, AD FS or AD CS server and installs the sensor type to match. Enter the access key and leave the default installation path.

For Server Core or software distribution, use a silent install during a maintenance window, because the installer can restart the server and the norestart flag isn't reliable:

.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<access key>"

AccessKeyFile="C:\Path\key.txt" reads the key from a file instead, and ProxyUrl, ProxyUserName and ProxyUserPassword set a proxy at install time. Installer logs are written to %localappdata%\Temp.

Extra steps for AD CS on v2.x

A v2.x sensor on an AD CS server can't use the local service account to connect to the domain, so configure a Directory Service account in the workspace. After installation, the sensor picks the closest domain controller; to change it, go to Settings > Identities > Sensors, select the sensor, add the FQDN under Domain controller (FQDN) and select Save.

Configure Windows event auditing

Detections depend on Windows events, and Defender for Identity raises health issues when auditing is wrong.

Sensor v3.x

Turn on Automatic Windows auditing configuration. It checks and fixes directory service advanced auditing, NTLM auditing, domain object auditing, AD FS auditing, AD CS auditing and Entra Connect auditing, and re-runs every 24 hours. For AD FS it covers the configuration container audit entries and the Audit Application Generated policy only; event auditing in AD FS Management and verbose logging (Set-AdfsProperties -AuditLevel Verbose) stay manual. For AD CS it writes the required value into the CA's existing audit filter but doesn't create a filter, so the CA must already have one, and the change takes effect only after the certsvc service restarts. Until then you'll see a health alert asking for the restart. GPO settings can conflict with the local settings the sensor applies.

On domain controllers running sensor version 3.0.8 or later with the July 2026 or later cumulative update, RPC auditing is also enabled automatically, so no RPC configuration tag is needed.

Sensor v2.x or manual configuration

Start with a report of the current state using the DefenderForIdentity PowerShell module from the PowerShell Gallery:

Install-Module -Name DefenderForIdentity
New-MDIConfigurationReport -Path "C:\Reports" -Mode Domain -Identity "CONTOSO\mdiSvc01" -OpenHtmlReport

To apply all domain settings through Group Policy objects the module creates and links:

Set-MDIConfiguration -Mode Domain -Configuration All

Add -CreateGpoDisabled or -SkipGpoLink if you want to review the GPOs before they take effect.

On each AD CS server, also:

1. Create a GPO for the CA servers and enable Audit Certification Services for Success and Failure under Advanced Audit Policy Configuration > Audit Policies > Object Access.
2. Enable CA auditing and restart the service:

certutil -setreg CA\AuditFilter 127
Restart-Service certsvc

Microsoft notes that auditing Start and Stop Active Directory Certificate Services can delay restarts on a large CA database. The AD CS events Defender for Identity needs are 4870, 4882, 4885, 4887, 4888, 4890 and 4896.

Validate the deployment

1. Sensor status. On Sensor management, every server should show Onboarded and a running sensor. For v2.x, the Azure Advanced Threat Protection sensor service should be running; if it isn't, read Microsoft.Tri.sensor-Errors.log under %programfiles%\Azure Advanced Threat Protection sensor\Version X\Logs.
2. Dashboard and entities. Check Identities > Dashboard, then open a DC under Assets > Devices and confirm Defender for Identity events on its timeline.
3. Advanced hunting. Confirm data is landing in the identity tables:

IdentityDirectoryEvents
| where TargetDeviceName contains "dc01.contoso.com"
 
IdentityQueryEvents
| where DeviceName contains "dc01.contoso.com"

4. AD CS. Request a certificate, then run the following and confirm successful and failed issuance events appear:

IdentityDirectoryEvents
| where Protocol == "Adcs"

5. Posture. In a test environment, Microsoft suggests setting ms-DS-MachineAccountQuota to a noncompliant value to trigger the Resolve unsecure domain configurations recommendation in Secure Score, then setting it back.
6. Alerts. In a lab, tag a honeytoken account and attempt a sign-in with it, and confirm the alert appears.

Troubleshooting

Health issues are under Settings > Identities > Health issues, split into Global health issues and Sensor health issues.

Microsoft also notes a known issue where v3.x sensors keep reporting auditing health alerts when auditing is configured manually through GPO or PowerShell. Turning on Automatic Windows auditing configuration resolves it.

Checklist

• Every DC, RODC and online issuing CA listed with its OS and chosen sensor version.
• Test-MdiReadiness.ps1 run and gaps fixed.
• v3.x servers on the July 2026 or later cumulative update; AD CS servers onboarded to Defender for Endpoint.
• Automatic sensor v3.x activation and Automatic Windows auditing configuration on, or manual auditing applied.
• CA audit filter set and certsvc restarted.
• Local system account selected for action accounts if any sensor is v3.x.
• Advanced hunting returns IdentityDirectoryEvents for each DC and Adcs events for each CA.
• Health issues page clear.

References

• Deploy Microsoft Defender for Identity sensors
• Deploy the Defender for Identity sensor v3.x
• Activate the Defender for Identity sensor v3.x
• Defender for Identity sensor v2.x prerequisites
• Install the sensor v2.x
• Configure sensors for AD FS, AD CS, and Microsoft Entra Connect
• Configure Windows event auditing
• Validate sensor deployment on domain controllers
• Microsoft Defender for Identity health issues