Microsoft’s unified Defender for Identity sensor is GA: What DFIR teams should change today

4n6 Beat
6 min read

Microsoft announced general availability of a unified Microsoft Defender for Identity sensor that correlates identity and endpoint telemetry across on‑premises Active Directory, Microsoft Entra ID, and even third‑party identity providers (e.g., Okta), improving incident correlation and enabling automatic attack disruption with richer identity context. The post also signals migration guidance for existing customers in the coming months. Microsoft Security Blog, 2025‑10‑23.

Why this matters to DFIR: identity evidence that used to be scattered (AD security events, Entra sign‑ins, endpoint logons) is now designed to land in one incident and one hunting surface (Defender XDR), with contain/disable actions tied directly to identity context. That reduces dwell time and speeds attribution and scoping. Microsoft Security Blog.

Deployment notes for practitioners

If you plan to turn on the unified sensor on domain controllers (DCs), validate these before activation:

  • OS and patch level: Windows Server 2019 or later, with the October 2025 cumulative update or later. Minimum 2 cores and 6 GB RAM. Time sync within 5 minutes. Requires Defender for Endpoint (MDE) on the DC. MDI v3.x prerequisites.
  • Activation path: in the Defender portal go to System > Settings > Identities > Activation, select eligible DCs, and Activate. First activation can take up to an hour to show Running; subsequent activations typically appear in ~5 minutes. No reboot required. Activate sensor.
  • Existing deployments: Microsoft says existing customers with classic sensors do not need to take action now; migration guidance is coming. Microsoft Security Blog.
  • Event auditing: ensure required Windows auditing is in place on DCs/AD FS/AD CS/Entra Connect so the sensor sees what it needs (e.g., 4624/4625, 4776, 4662, 5136, 7045, 8004; AD CS and AD FS event families). Event collection overview.
  • Network/ports: pay attention to localhost TCP 444 (sensor updater) and required outbound/inbound ports if you run classic/standalone sensors. Prerequisites and ports.
  • Okta integration (Preview): connect via the Unified Connectors experience to ingest Okta system logs once and share across Microsoft security products; note the duplication caveat if you already integrate Okta with Defender for Cloud Apps. Connect Okta to MDI (Preview).

Documentation nuance: Some Learn pages still refer to v3.x as preview and list limitations; the 2025‑10‑23 Microsoft blog is the authoritative statement of GA status. Validate tenant‑specific feature availability before switching sensors at scale. MDI deploy overview and Microsoft Security Blog.

Where evidence shows up (artefact map)

  • Defender XDR Advanced Hunting tables now centralize most identity telemetry:
    • IdentityLogonEvents: on‑prem AD auth and Microsoft online interactive sign‑ins (legacy protocol coverage noted); non‑interactive sign‑ins remain in Entra audit logs. IdentityLogonEvents.
    • IdentityDirectoryEvents: AD directory state changes (e.g., password changes, group updates) and certain DC system events. IdentityDirectoryEvents.
    • IdentityQueryEvents: LDAP/AD queries and enumerations (user/group/computer lookups). IdentityQueryEvents.
    • IdentityInfo: unified identity inventory and attributes across sources. IdentityInfo.
    • IdentityEvents (Preview): events from third‑party IdPs like Okta when connected. IdentityEvents (Preview).
    • DeviceLogonEvents/DeviceNetworkEvents/DeviceEvents: endpoint‑side logons, network flows, and response actions (e.g., containment). DeviceLogonEvents • DeviceNetworkEvents • DeviceEvents.
  • MDI classic sensor host artefacts for v2.x: logs under C:\Program Files\Azure Advanced Threat Protection Sensor\<version>\Logs (e.g., Microsoft.Tri.Sensor.log). Useful during sensor issues or timeline reconstruction. Troubleshooting using logs.

Automatic attack disruption: what to look for

Microsoft maps identity signals into automatic attack disruption, which can contain users, contain devices, and disable accounts when confidence is high. Analysts can track these actions in the incident, Action center, and Advanced Hunting. Automatic attack disruption • Action results & hunting.

  • Contain user: MDE blocks network logon/RPC/SMB/RDP from a contained identity on onboarded endpoints; DCs receive GPO updates when containment is enforced there. Only available automatically (not manual). Contain user behavior.
  • Disable user: MDI can disable AD accounts (and synced Entra identities) as part of disruption. Automatic attack disruption.

Hunting the response actions:

// List contain/disable actions associated with Automatic Attack Disruption
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType contains "ContainedUser" or ActionType contains "ContainedDevice"
| summarize count() by ActionType, DeviceName

Action results & hunting.

Ready‑to‑use hunts (cross‑domain)

  1. LDAP clear‑text binds (simple binds) observed by MDI
IdentityLogonEvents
| where Timestamp > ago(7d)
| where LogonType == "LDAP Cleartext" // simple bind
| summarize Attempts=count(), Hosts=make_set(DeviceName, 10) by AccountUpn, AccountDomain
| order by Attempts desc

IdentityLogonEvents.

  1. Suspicious AD enumeration preceding lateral movement
// Find bursts of AD queries from single hosts and pivot to endpoint logons
let lookback = 24h;
let noisyHosts = IdentityQueryEvents
  | where Timestamp > ago(lookback)
  | summarize qps=count() by DeviceName
  | where qps > 200; // tune to your baseline
IdentityQueryEvents
| where Timestamp > ago(lookback)
| where DeviceName in (noisyHosts)
| summarize Queries=count(), Targets=make_set(QueryTarget, 20) by DeviceName
| join kind=leftouter (
    DeviceLogonEvents
    | where Timestamp > ago(lookback)
    | summarize dcount(AccountUpn) by DeviceName
  ) on DeviceName
| order by Queries desc

IdentityQueryEvents • DeviceLogonEvents.

  1. Contained identities still attempting access (scope lateral movement)
DeviceEvents
| where Timestamp > ago(3d)
| where ActionType contains "ContainedUser"
| extend User=tostring(AdditionalFields.AccountUpn)
| join kind=leftouter (
    DeviceNetworkEvents
    | where Timestamp > ago(3d)
  ) on $left.DeviceId == $right.DeviceId
| project Timestamp, DeviceName, User, ActionType, RemoteIP, RemotePort, Protocol
| order by Timestamp desc

Action results & hunting • DeviceNetworkEvents.

  1. Okta signals unified into XDR (Preview)
// Explore volume and types as your connector goes live
IdentityEvents
| where Timestamp > ago(7d)
| summarize Events=count() by ActionType
| top 20 by Events desc

IdentityEvents (Preview) • Okta connector (Preview).

  1. Rapid review of identity‑linked changes on DCs
IdentityDirectoryEvents
| where Timestamp > ago(24h)
| summarize Count=count() by ActionType, TargetDeviceName
| order by Count desc

IdentityDirectoryEvents.

Response guidance and playbook updates

  • Single‑incident triage: the Identity page in Defender now correlates identities, related devices/apps, and alerts inside the incident; posture recommendations are surfaced via Exposure Management for pre‑emptive hardening. Use this view to keep the timeline coherent. Microsoft Security Blog • Exposure Management integration.
  • Containment workflow: when disruption triggers, review the incident banner and Action center to see which users/devices were contained or disabled; only release after eradication. Action results & hunting.
  • GPO side‑effects: containing a user on a DC updates Default Domain Controllers Policy; your GPO monitors will see this churn—expected and reversible when you undo containment. Contain user behavior.
  • Conditional access tie‑ins: for cloud access, enforce device risk/compliance and user risk via Conditional Access so compromised identities have fewer avenues during an incident. Conditional Access overview • Configure CA with MDE.

Practical configuration checklist

  • Patch DCs to the October 2025 CU baseline and verify MDE is onboarded on DCs. MDI v3.x prerequisites.
  • Enable/validate required Windows audit policies for MDI detections (4624/4625/4776/4662/5136/7045/8004, plus AD FS/AD CS families). Event collection overview.
  • Activate the unified sensor on eligible DCs; confirm status on the Sensors page. Activate sensor.
  • Connect Okta via Unified Connectors (Preview) if applicable; beware duplicate ingestion if DCAs integration already exists. Okta connector (Preview).
  • Validate automatic attack disruption settings and get your team comfortable with Action center and advanced hunting traces for contain/disable actions. Automatic attack disruption • Action results & hunting.
  • If you still run classic v2 sensors, keep host‑side logs for troubleshooting: C:\Program Files\Azure Advanced Threat Protection Sensor\...\Logs. Troubleshooting using logs.

Takeaways

  • Turn on the unified sensor on eligible DCs after validating OS/MDE prerequisites; keep classic sensors where required until migration guidance lands. Prereqs • GA announcement.
  • Centralize your hunting in Defender XDR using the Identity* tables and join with Device* tables for rapid scoping. Advanced hunting tables.
  • Embrace automatic attack disruption—treat containment and disable actions as pivot points, and instrument playbooks to review and release from the Action center after eradication. Auto disruption • Action results.
  • If you run Okta, connect it to Defender for Identity via Unified Connectors (Preview) to enrich incidents and hunts without duplicate API pulls. Okta connector (Preview).

Sources / References