Microsoft Defender for Identity Enterprise Deployment and Operations Guide

Overview

Microsoft Defender for Identity is a cloud-delivered security service that monitors Active Directory signals to detect identity-based attacks such as reconnaissance, credential theft, lateral movement, and domain dominance. Enterprises use it to improve visibility into identity attack paths, reduce mean time to detect, and integrate identity telemetry with Microsoft Defender XDR and Microsoft Sentinel.

It is especially valuable in hybrid environments where Active Directory remains critical for authentication, privileged access, and legacy application support. By analyzing authentication traffic, directory queries, security events, and entity behavior, Defender for Identity helps security teams detect attacks like Pass-the-Hash, DCSync, Kerberoasting, and suspicious LDAP enumeration.

Architecture

Microsoft Defender for Identity consists of several core components:

• Defender for Identity cloud service for analytics, detections, and investigation.
• Defender for Identity sensor installed directly on domain controllers.
• Defender for Identity standalone sensor for environments using port mirroring, though direct sensor deployment is the standard model.
• Microsoft 365 Defender portal for incident triage, alerts, and secure score integration.

Deployment model

In most enterprises, sensors are installed on every writable domain controller and, where needed, on AD FS servers. Sensors inspect domain controller traffic locally and securely send telemetry to the Microsoft service over outbound HTTPS.

Data flow

1. Domain controller processes authentication and directory activity.
2. Sensor collects Windows Event Log data, ETW, and network inspection signals.
3. Telemetry is encrypted and sent to the Defender for Identity cloud service.
4. Alerts and incidents are surfaced in Microsoft 365 Defender and can be streamed to SIEM platforms.

Implementation Guide

1. Validate prerequisites

• Azure AD tenant with Microsoft Defender for Identity licensing.
• Global Administrator or Security Administrator permissions.
• .NET Framework and supported Windows Server versions on domain controllers.
• Outbound access to required Microsoft endpoints over TCP 443.

2. Create the Defender for Identity instance

From the Microsoft 365 Defender portal, enable Defender for Identity and download the sensor package and access key.

3. Install the sensor silently

Run on each domain controller from an elevated PowerShell session:

MicrosoftDefenderForIdentitySensorSetup.exe /quiet NetFrameworkCommandLineArguments="/q" AccessKey="YOUR_ACCESS_KEY"

4. Verify service status

sc query AATPSensor
Get-Service AATPSensorUpdater, AATPSensor

Expected state is RUNNING.

5. Configure proxy if required

Create or update the sensor proxy configuration:

SensorProxyConfiguration:
  Url: http://proxy.corp.contoso.com:8080
  UserName: CONTOSO\\mdi_proxy_svc
  Password: "<secure-password>"

Apply proxy settings according to Microsoft sensor guidance and restart the service:

Restart-Service AATPSensor

6. Configure event collection for enriched detections

Enable advanced audit policy on domain controllers:

auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

7. Integrate with Microsoft Sentinel

Use the Microsoft 365 Defender data connector in Sentinel to ingest incidents and alerts for centralized SOC workflows.

Code Examples

Example 1: Silent sensor deployment script

$accessKey = "YOUR_ACCESS_KEY"
$installer = "C:\Install\MicrosoftDefenderForIdentitySensorSetup.exe"
Start-Process -FilePath $installer -ArgumentList "/quiet AccessKey=\"$accessKey\"" -Wait
Get-Service AATPSensor | Select-Object Status, Name, DisplayName

Example 2: GPO-backed audit baseline

auditPolicy:
  accountLogon:
    credentialValidation: success,failure
  logonLogoff:
    logon: success,failure
  dsAccess:
    directoryServiceAccess: success,failure

Example 3: Query Microsoft 365 Defender incidents API

import requests

tenant_id = "<tenant-id>"
client_id = "<app-id>"
client_secret = "<secret>"
resource = "https://api.security.microsoft.com/.default"

token = requests.post(
    f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token",
    data={
        "client_id": client_id,
        "client_secret": client_secret,
        "scope": resource,
        "grant_type": "client_credentials"
    }
).json()["access_token"]

resp = requests.get(
    "https://api.security.microsoft.com/api/incidents",
    headers={"Authorization": f"Bearer {token}"}
)
print(resp.status_code)
print(resp.json())

Security Hardening

• Install sensors on all writable domain controllers to avoid visibility gaps.
• Restrict local administrator access on domain controllers using tiered administration.
• Use TLS-inspecting proxies only if explicitly supported; avoid breaking certificate validation.
• Store deployment packages and access keys in a privileged access vault.
• Forward Defender alerts into Sentinel or another SIEM with immutable retention.
• Review directory service account exposure and reduce unconstrained delegation, legacy NTLM, and excessive replication rights.

Comparison

Troubleshooting

Error 1: Sensor service fails to start

Log sample:

Service Control Manager Event ID 7000: The Azure Advanced Threat Protection Sensor service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.

Fix:

• Confirm supported OS and patch level.
• Check proxy reachability and outbound 443.
• Review C:\Program Files\Azure Advanced Threat Protection Sensor\Logs\Microsoft.Tri.Sensor-Errors.log.

Error 2: Connectivity failure to cloud service

Log sample:

2024-11-18 09:14:22.781 Error CommunicationWebClient: Request failed. System.Net.WebException: The remote name could not be resolved: 'contoso.atp.azure.com'

Fix:

• Validate DNS resolution from the domain controller.
• Allow required Defender for Identity URLs through firewall and proxy.
• Test with Test-NetConnection and Resolve-DnsName.

Error 3: Missing event data

Log sample:

2024-11-18 10:02:44.113 Warn EventReader: Security event 4624 was not found in expected volume. Detection quality may be reduced.

Fix:

• Enable advanced audit policy via GPO.
• Increase Security log size on domain controllers.
• Verify no conflicting audit baseline disables required subcategories.

Best Practices

Do

• Deploy to every writable domain controller to ensure complete identity visibility.
• Integrate with Defender XDR and Sentinel for incident correlation.
• Tune sensitive accounts and honeytoken entities to improve alert fidelity.
• Use least privilege for administrators managing the platform.

Don't

• Do not deploy to only a subset of critical sites; attackers often target weaker regional infrastructure.
• Do not ignore audit policy dependencies; several detections rely on complete event coverage.
• Do not leave legacy protocols unchecked; NTLM and unconstrained delegation increase identity attack surface.

A strong enterprise rollout combines complete sensor coverage, validated audit telemetry, SIEM integration, and regular review of identity posture recommendations.