Microsoft Defender for Identity Alerts Not Firing: Troubleshooting Guide

Navigate to security.microsoft.com > Settings > Identities > Sensors. Each domain controller sensor shows a version number, a last communication timestamp, and a health status. A sensor that shows Running but has not communicated in more than 5 minutes is likely stuck. Click the sensor to expand health alerts: common alerts include Directory Services Object Auditing is not configured as required, Sensor failed to retrieve credentials, and Npcap is out of date. Health alerts in the portal are more reliable than the green Running status because the status reflects the last check-in while health alerts reflect real-time packet capture and event log access. For multi-DC environments, check every DC sensor individually; a misconfiguration on one DC can mask gaps in lateral movement detection coverage across the entire domain.

MDI relies on Npcap for packet capture on domain controllers. When Npcap is at an incompatible version for the installed sensor build, packet capture fails silently: the sensor shows Running but never captures network-based alerts like Pass-the-Ticket or Pass-the-Hash. Check the installed Npcap version in Control Panel > Programs > Programs and Features. MDI specifies a supported Npcap version range in the sensor release notes available at docs.microsoft.com under Microsoft Defender for Identity prerequisites. If the installed version is outside the supported range, uninstall the current Npcap version and reinstall the supported version from the MDI download link in the Defender portal (Settings > Identities > Sensors > Download sensor). The MDI sensor installer includes the correct Npcap version; reinstalling the sensor rather than Npcap alone ensures version alignment. After reinstalling, run a packet capture test: netsh trace start capture=yes and generate a Kerberos authentication event by logging into another domain resource from the DC.

MDI generates alerts based on Windows event logs. If the required event IDs are not audited on domain controllers, the alerts simply never fire even when the attack occurs. The minimum required audit policy settings for MDI are: Audit Account Logon Events (Success and Failure) for event IDs 4624 and 4625; Audit Kerberos Authentication Service (Success and Failure) for event IDs 4768, 4769, and 4771; Audit Directory Service Access (Success) for event ID 4662; and Audit Security Account Management (Success and Failure) for event ID 4720 and 4728. Verify current audit policy with auditpol.exe /get /category:* on each DC. Apply the MDI Group Policy Object from the MDI documentation to ensure consistent policy across all DCs. Check that the policy is not being overridden by a higher-precedence GPO using gpresult /h gpresult.html on the DC.

MDI honeytoken alerts fire when any account designated as a honeytoken is used for authentication. These are decoy accounts that legitimate users and systems should never touch; any usage indicates compromise or reconnaissance. Configure honeytoken accounts in the Defender portal under Settings > Identities > Honeytoken accounts. Add accounts that have no legitimate purpose but exist in AD (disabled accounts, service accounts with no actual service, accounts with names that look attractive to attackers). The accounts must be Active Directory accounts, not Azure AD accounts. After configuring, test by authenticating with the honeytoken account from a test machine; the MDI alert should fire within 2 to 5 minutes. If no alert fires after 10 minutes, check that the sensor on the DC where the authentication occurred is healthy and that event ID 4624 is being audited with Success.

MDI can detect lateral movement through VPN and remote access flows when RADIUS accounting data is forwarded to the sensor. Without RADIUS integration, remote users who authenticate via VPN are invisible to MDI's lateral movement detection. Configure RADIUS accounting in your VPN gateway (Palo Alto, Cisco ASA, Fortinet FortiGate) to send RADIUS Accounting-Request packets to the MDI sensor's IP address on UDP port 1813. In the MDI portal under Settings > Identities > the sensor > RADIUS accounting, enable RADIUS accounting integration and add the VPN gateway as a RADIUS client with a shared secret. After enabling, generate a VPN authentication event and verify it appears in MDI's network activity timeline for the authenticating user. RADIUS integration is per-sensor, so configure it on the sensor closest to the VPN termination point.

MDI includes a built-in self-test command that validates connectivity, packet capture, and event log access from the sensor. Navigate to C:\Program Files\Azure Advanced Threat Protection Sensor[version number]\ and run Microsoft.Tri.Sensor.exe selftest from an elevated command prompt. The output reports packet capture status, Kerberos ticket capture status, LDAP connectivity to the domain, and event log access. A PASS result for all checks confirms the sensor is fully functional. For connectivity issues, run Test-NetConnection -ComputerName <MDI-service-endpoint> -Port 443 to verify the DC can reach the MDI cloud service. MDI sensors require outbound HTTPS to *.atp.azure.com on TCP 443. If the self-test reports event log access as FAIL, verify the MDI sensor service account has the Event Log Readers group membership on the DC.