Microsoft Defender for Identity (MDI, formerly Azure ATP) is the sensor layer that gives Defender XDR visibility into on-prem Active Directory. It reads domain-controller traffic and Windows events to detect what EDR cannot see cleanly: pass-the-ticket, DCSync, golden-ticket forgery, and reconnaissance walks across the directory. The license is bundled with E5 / standalone, but it does nothing until you deploy sensors, give it a directory service account (DSA), and tune the noise out. This guide is the rollout I run on tier-0 environments: sensors on DCs / AD CS / AD FS, honeytoken traps, ISPM remediation, and lateral-movement investigation feeding XDR incidents.
A correction up front, because it trips people: MDI runs almost entirely on the sensor installed on the domain controller itself. The old “standalone sensor + port mirroring” story is deprecated for new deployments — plan for the unified sensor on every writable DC.
1. Architecture: what the sensor actually covers
The MDI sensor is a Windows service that runs locally on the server it monitors. It captures traffic to/from that machine (Kerberos, NTLM, LDAP, DNS, RPC) and parses Windows events, then ships parsed activity — not raw packets — to the cloud service. One sensor type covers multiple roles:
| Role | What MDI detects there | Notes |
|---|---|---|
| Domain Controller | Pass-the-ticket, DCSync, golden ticket, recon, brute force | Install on every writable DC; RODCs are supported too |
| AD CS (Certificate Services) | Certificate-based attacks (ESC1/ESC8-style abuse, suspicious enrollments) | Sensor on the CA server |
| AD FS | Password spray / brute force against federation, suspicious sign-ins | Install on AD FS and WAP servers |
| Entra Connect | Detections around the sync server as a tier-0 asset | Sensor on the Entra Connect host |
Rule of thumb: any server holding tier-0 identity material (DC, CA, AD FS, Entra Connect) gets a sensor. Coverage gaps are blind spots an attacker will find first.
The sensor self-throttles and backs off rather than starve the DC — that design is what lets you put it directly on production DCs without a separate capture appliance.
2. Plan: directory service account and network
Before any install, create the Directory Service Account. MDI uses it to query AD/AD CS over LDAP for entity enrichment (resolving SIDs, group membership, lateral-movement paths). A read-only group Managed Service Account (gMSA) is the supported best practice — no static password to rotate or leak.
# 1. KDS root key (only once per forest; takes effect after 10h, or use -10h in a lab)
Add-KdsRootKey -EffectiveImmediately
# 2. Security group whose members may retrieve the gMSA password = the DCs/CA/ADFS sensors
$sensors = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -SearchBase "OU=Domain Controllers,DC=corp,DC=contoso,DC=com"
New-ADGroup -Name "gMDI-Sensors" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "gMDI-Sensors" -Members $sensors
# 3. Create the gMSA the sensors will run the query account as
New-ADServiceAccount -Name "svc-mdi" -DNSHostName "svc-mdi.corp.contoso.com" `
-PrincipalsAllowedToRetrieveManagedPassword "gMDI-Sensors"
Then register corp\svc-mdi$ in the Defender portal under Settings > Identities > Directory service accounts. If you also monitor AD CS or run object auditing, the DSA needs read permission on the relevant containers (it does not need Domain Admin — that is an anti-pattern).
For deleted-object recon detection, grant the DSA read on the Deleted Objects container:
$deletedObjects = "CN=Deleted Objects,DC=corp,DC=contoso,DC=com"
dsacls $deletedObjects /takeOwnership
dsacls $deletedObjects /g "corp\svc-mdi:LCRP"
Network requirements: each sensor needs outbound HTTPS (443) to its regional MDI cloud endpoint (*.atp.azure.com). It does not need inbound. Confirm name resolution and that any proxy passes the sensor’s traffic. For environments with strict egress, the sensor supports a configured proxy at install time.
3. Install sensors and enable auditing
Download the sensor package and access key from Settings > Identities > Sensors > Add sensor. Install silently on each DC; the same binary detects whether it is on a DC, CA, or AD FS host.
# Run from the extracted package; quiet install with the workspace access key
.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<workspace-access-key>"
Detections depend on Windows event auditing being on. MDI relies on specific Security events (e.g., 4726, 4728/4729, 4670, 7045, 8004 for NTLM). Configure advanced audit policy and NTLM auditing via Group Policy so the sensor sees the events it parses:
Computer Configuration > Policies > Windows Settings > Security Settings >
Advanced Audit Policy Configuration:
Account Management -> Audit Security Group Management: Success+Failure
Account Management -> Audit User Account Management: Success+Failure
DS Access -> Audit Directory Service Changes: Success+Failure
Detailed Tracking -> Audit Process Creation (4688) on tier-0 hosts
Network security: Restrict NTLM: Audit NTLM authentication in this domain -> Enable all
The portal surfaces audit-policy health warnings per sensor — act on them. Silent gaps in audit policy are the most common reason a detection “doesn’t fire.”
4. Tune the high-value detections
Out of the box MDI watches for the credential-theft chain. The four you should validate first, because they map directly to real intrusions:
- Pass-the-Ticket — a Kerberos TGT/TGS used from a different source than it was issued to. MDI correlates the ticket across machines.
- DCSync (suspected DCSync attack) — a non-DC principal issuing replication requests (
DRSGetNCChanges). This is how Mimikatz/secretsdump pulls the KRBTGT and every hash. There is almost no legitimate reason for a workstation to replicate. - Golden Ticket — anomalies in TGT lifetime, encryption downgrade, or forged tickets after a KRBTGT compromise.
- Reconnaissance — SAMR/LDAP enumeration of users, groups, and admins (BloodHound-style sweeps).
Validate DCSync coverage safely with a benign replication call rather than running real attack tooling. Confirm the alert lands in the portal and in AlertInfo/IdentityDirectoryEvents. To suppress known benign replication (your actual DCs, Entra Connect), add them as exclusions rather than disabling the rule — covered in section 8.
A genuinely useful hardening step is forcing KRBTGT rotation after any golden-ticket suspicion. Rotate twice, with a gap longer than the max ticket lifetime, so old forged tickets die:
# Use Microsoft's New-KrbtgtKeys.ps1; rotate, wait > max TGT lifetime (default 10h), rotate again
.\New-KrbtgtKeys.ps1 # run once, wait the replication + ticket-lifetime window, then run again
5. Deploy honeytokens and entity tags
Honeytokens are the highest signal-to-noise control MDI gives you. A honeytoken is a dormant account that no human or service should ever touch — so any authentication or query against it is, by definition, suspicious. Create a believable but unused account (looks privileged, named like a real admin), leave it disabled-but-tagged or enabled-with-no-logon, and tag it in MDI.
# A plausible-looking but unused account. Strong random password, no SPNs, never used interactively.
New-ADUser -Name "svc-backup-admin" -SamAccountName "svc-backup-admin" `
-AccountPassword (ConvertTo-SecureString (([System.Web.Security.Membership]::GeneratePassword(24,6))) -AsPlainText -Force) `
-Enabled $true -PasswordNeverExpires $true `
-Description "Backup service (do not use)" -Path "OU=Service Accounts,DC=corp,DC=contoso,DC=com"
Then tag it in the Defender portal: Settings > Identities > Entity tags > Honeytoken, add svc-backup-admin. MDI raises Honeytoken activity alerts on any auth, Kerberos request, or LDAP query referencing it. Pair this with Sensitive tags so MDI treats your true tier-0 accounts/groups as crown jewels in lateral-movement-path math:
| Entity tag | Use it for | Effect |
|---|---|---|
| Honeytoken | Decoy accounts/devices | Any activity raises an alert |
| Sensitive | Tier-0 admins, DAs, Backup Operators, Exchange roles | Prioritized in LMP and exposure scoring |
| Exchange server / VPN | Known infra | Reduces false positives, contextualizes traffic |
MDI auto-flags built-in sensitive groups (Domain Admins, Enterprise Admins, etc.), but it does not know about your custom tier-0 group named Corp-Server-Admins — tag it explicitly.
6. Remediate identity posture (ISPM)
MDI feeds Identity Security Posture Management assessments into Microsoft Secure Score (Defender portal > Secure score, identity recommendations) and exposes them under Identities > Health issues / posture. These are standing misconfigurations attackers exploit before they ever throw an exploit:
- Unsecure Kerberos delegation (unconstrained delegation on non-DC hosts — a tier-0 escalation path)
- Accounts with reversible-cleartext passwords or
DES/RC4-only encryption - Print Spooler enabled on DCs (PrinterBug / coercion)
- Dormant/stale privileged accounts and SID-history risks
- Weak certificate templates (ESC misconfigurations) when AD CS sensors are present
Hunt the worst offender — unconstrained delegation — directly, then remediate by switching to constrained (or resource-based constrained) delegation:
# Find computers/users trusted for unconstrained delegation (excluding DCs)
Get-ADObject -Filter {(UserAccountControl -band 0x80000) -eq 0x80000} `
-Properties UserAccountControl,servicePrincipalName |
Where-Object { $_.DistinguishedName -notlike '*OU=Domain Controllers*' } |
Select-Object Name,DistinguishedName
# Remediate: remove the TRUSTED_FOR_DELEGATION flag and pin to specific SPNs (constrained)
Set-ADComputer -Identity "APP01" -TrustedForDelegation $false
Set-ADComputer -Identity "APP01" -Add @{ "msDS-AllowedToDelegateTo" = @("HTTP/web01.corp.contoso.com") }
Work the recommendations as a backlog with owners and target dates. The score is a proxy; the goal is shrinking the tier-0 attack surface.
7. Investigate lateral-movement paths and tier-0 exposure
The feature that earns MDI its keep is the Lateral Movement Path (LMP). MDI computes, from logon and admin-rights data, the chain by which a non-sensitive account that an attacker might compromise could reach a Sensitive account — e.g., a help-desk user who is local admin on a workstation where a Domain Admin logged on. Open any sensitive user/device in the portal and review the Lateral movement paths tab (and the time-bounded LMP report under reports).
The fix is almost always credential hygiene: stop tier-0 accounts logging on to tier-1/2 assets (clean-source / tiered admin), and remove standing local-admin overlaps. Validate where a DA has authenticated recently with hunting:
// Where have tier-0 accounts authenticated? Surface tier-0 creds landing on non-DC hosts.
IdentityLogonEvents
| where Timestamp > ago(7d)
| where AccountUpn in~ ("da-alice@corp.contoso.com", "da-bob@corp.contoso.com")
| where LogonType in ("Interactive", "RemoteInteractive")
| where DeviceName !contains "DC"
| summarize Logons = count(), Devices = make_set(DeviceName) by AccountUpn
| sort by Logons desc
Each result on a non-DC host is a path to collapse — either an LMP MDI already drew, or one to feed back into your tiering model.
8. Wire into Defender XDR: incidents, hunting, exclusions
MDI alerts don’t live in a silo — they correlate into Defender XDR incidents alongside MDE device alerts and Entra ID Protection risk, so a pass-the-ticket from MDI and a suspicious process from MDE collapse into one incident with a unified graph. No connector to configure: enabling MDI surfaces it in the unified portal automatically. (If you forward to Sentinel, use the Microsoft Defender XDR connector to pull incidents + raw Identity* tables, not a legacy per-product connector.)
The MDI advanced-hunting tables you will live in:
// Recent identity alerts with the entities involved (great for an incident triage hunt)
AlertInfo
| where Timestamp > ago(24h)
| where ServiceSource == "Microsoft Defender for Identity"
| join kind=inner AlertEvidence on AlertId
| project Timestamp, Title, Severity, Category, EntityType, AccountName, DeviceName
| sort by Timestamp desc
// Directory changes to sensitive groups — catch privilege escalation as it happens
IdentityDirectoryEvents
| where Timestamp > ago(7d)
| where ActionType in ("Group Membership changed", "Account Password changed")
| where TargetAccountDisplayName has_any ("Domain Admins", "Enterprise Admins", "Corp-Server-Admins")
| project Timestamp, ActionType, AccountUpn, TargetAccountUpn, TargetDeviceName
Operational tuning to fight alert fatigue. The deployment is not done until the noise is gone:
- Exclusions, not disables. For each detection (DCSync, recon, honeytoken, etc.), add the legitimate sources under Settings > Identities > <detection> > Exclusions — your real DCs and Entra Connect for replication; vuln scanners for recon. Keep the detection on; scope out the known-good.
- Benchmark coverage. Run controlled, safe tests per technique (a benign replication call, an authorized BloodHound run in a window, a logon to the honeytoken) and confirm each lands in
AlertInfo. Track which MITRE ATT&CK techniques you can actually detect — gaps usually trace back to missing audit policy (section 3) or an unmonitored DC. - Tune severity by tagging. Sensitive/honeytoken tags raise signal; correctly tagging known infra (VPN, Exchange) cuts false positives at the source.
- Watch sensor health. Under Settings > Identities > Sensors, every writable DC should report healthy and current; a silent unhealthy sensor is an invisible coverage gap.
Verify
Run this end-to-end before calling the deployment production-ready:
# 1. Every writable DC has a running, healthy sensor service
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
Get-Service -Name "AATPSensor" -ErrorAction SilentlyContinue |
Select-Object @{n='DC';e={$env:COMPUTERNAME}}, Status, StartType
}
# 2. The gMSA installs and the sensor hosts can retrieve its password
Test-ADServiceAccount -Identity "svc-mdi" # run on a sensor host; expect True
// 3. The pipeline is alive: identity activity is reaching the cloud (run in advanced hunting)
IdentityDirectoryEvents
| where Timestamp > ago(1h)
| summarize Events = count(), DCs = dcount(DeviceName)
- Portal: Settings > Identities > Sensors — all writable DCs + CA/AD FS/Entra Connect green and on the current version.
- Trigger a honeytoken logon and confirm a “Honeytoken activity” alert appears within minutes and correlates into an XDR incident.
- Confirm DSA status is healthy under Directory service accounts (no LDAP-bind errors).
- Secure Score shows MDI identity recommendations and the count is trending down week over week.
Enterprise scenario
A retail platform team (~30k seats, single forest, 14 DCs across 3 regions) ran MDI for a year but kept getting paged on a recurring suspected DCSync alert every night at 02:10. The on-call assumption was “false positive, ignore it” — exactly the alert-fatigue failure mode MDI is meant to prevent. The constraint: they could not simply disable the DCSync rule, because DCSync is the single highest-value detection they had against KRBTGT theft, and compliance required it stay active.
Investigation in advanced hunting showed the replication source was a host named BKP-VEEAM01 — a backup appliance running an AD-aware backup job that legitimately issued DRSGetNCChanges. It looked identical to secretsdump to the sensor. The wrong fixes (disable the rule; give the appliance Domain Admin to “make it stop”) were both on the table.
The correct fix was a scoped exclusion plus tighter least-privilege, leaving the detection fully armed for every other source:
// Confirm the only DCSync replicator is the known appliance before excluding it
IdentityDirectoryEvents
| where Timestamp > ago(30d)
| where ActionType == "Directory Services replication"
| summarize Count = count() by AccountUpn, DeviceName
| sort by Count desc
They added BKP-VEEAM01 to the DCSync detection exclusion list (Settings > Identities > Suspected DCSync attack > Exclusions), reduced the appliance’s replication rights to the minimum its job required, and left DCSync detecting on every other principal. Nightly false pages went to zero, and three weeks later the rule fired on a workstation during an actual red-team engagement — caught precisely because they had tuned instead of disabled.