Defender for Identity is crucial for capturing events, alerting on MDI threats, and collecting information from on-premises systems through the installed sensor. For environments still running on-premises, ensuring Defender for Identity is running optimally is key for effective attack disruption and complete visibility related to identity threats.
One of the most common issues with Defender for Identity is policy misconfiguration. While installing the sensor itself is straightforward, the real challenge lies in configuring the correct Windows Event audit policies to enable full detection capabilities. Without the correct Windows Event policies, it will not give full visibility.
Why event auditing for MDI?
Event auditing plays a vital role in effective threat detection, as Microsoft Defender for Identity depends on specific Windows security events to identify identity-based attacks. Audit settings are frequently overlooked. Administrators either forget to configure them or assume the default settings are enough.
To reliably capture high-value security signals, Defender for Identity requires the following audit policies and subcategories to be enabled:
| Audit Category | Audit Policy / Subcategory | Event ID(s) |
|---|---|---|
| Account Logon | Audit Credential Validation | 4776 |
| Account Management | Audit Computer Account Management | 4741, 4743 |
| Account Management | Audit Distribution Group Management | 4753, 4763 |
| Account Management | Audit Security Group Management | 4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758 |
| Account Management | Audit User Account Management | 4726 |
| DS Access | Audit Directory Service Changes | 5136 |
| DS Access | Audit Directory Service Access | 4662 |
| System | Audit Security System Extension | 7045 |
When health issues appear, something is not configured correctly. Via the health issues in the Defender portal all of the open health issues are visible:
V3.X agent?
Some months ago, it was finally announced: the unified identity and endpoint sensor. This is by far one of the most asked questions from customers. Why are Defender for Endpoint and Defender for Identity running on two separate agents? It has been known for some years that Microsoft is working to get a unified single sensor for Defender (All was NDA for years)
Like many security solutions, Microsoft Defender relies on sensors to gain visibility into the endpoints and on-premises identity infrastructure within your environment.
Differences?
When Microsoft talks about the v2.x version, it means that it is focusing on the Defender for Identity sensor, which needs to be installed as seperate agent and configured on the system. V3.x is the latest version, which uses the Defender for Endpoint/ EDR-sensor.
V2.x agent:
Good to know the new V.3.x sensor changes the initiatingProcessFileName to Senseidentity.exe. When the svchost.exe is still used in the result, you most likely have a conflict with Group Policy. Check the following file when things aren’t working as expected: “C:\Windows\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv”
The automatic configuration runs automatically every 24 hours to ensure the configuration remains intact, even when the configuration is changed via tooling or as part of malicious activities to bypass local audit policies.
Activating
Before activating the Defender for Identity sensor v3.x, keep these considerations in mind before activating the sensor:
- Requires that Defender for Endpoint is deployed and that the Microsoft Defender Antivirus component is running in either active mode or passive mode.
- Can’t be activated on a server that has a Defender for Identity sensor V2.x already deployed.
- Doesn’t currently support VPN integration.
- Doesn’t currently support ExpressRoute.
Good to know the domain controller must have been running on Windows Server 2019 or later and is installed with the October 2025 CU or later. And Defender for Identity sensor V2.x is not deployed. When the V2.x sensor is deployed, it will not work.
When the Defender for Endpoint sensor is installed on a Windows Server 2019 or later, the server can be enabled via the activation wizard in Microsoft Defender for Identity via: Settings -> Identities -> Activation.
Automatic event configuration
With the V2 sensor, all of the audit configs need to be configured manually; this includes audit events, NNR, and a specific audit policy for additional detections. Automatic windows auditing performs all configuration tasks automatically:
- Checks the current Windows event auditing configuration.
- Identifies any gaps in the configuration.
- The sensor applies any necessary changes, including all of the steps in the manual configuration:
- Directory services advanced auditing: Adds audit entries to the domain root object’s System Access Control List (SACL) to enable required directory service auditing.
- NTLM auditing – Uses standard Windows Registry APIs to configure the required NTLM auditing registry values.
- Domain object auditing – Modifies the SACL on the Configuration partition to capture changes to directory service configuration objects.
- ADFS auditing – Adds audit entries to the object’s System Access Control List (SACL) of the AD FS configuration container, to enable auditing of AD FS-related directory objects.
- Windows audit policy – Configures the local Windows audit policies using the Windows Local Security Authority (LSA) audit policy APIs.
- Applies auditing settings directly to the local system policy of the domain controller.
The good news – it is all deployed automatically, so no auditing policies via GPO anymore for V3.x versions. The audit policies are directly deployed via Defender as a local audit policy via the Defender agent.
How to enable automatic Windows auditing?
In the Microsoft Defender portal, go to Settings, and then Identities. In the General section, select Advanced features.
Turn on Automatic Windows auditing configuration.
If you don’t turn on automatic Windows auditing, you must configure Windows event auditing either manually or using PowerShell. Both V.2 and V.3 versions need to be configured with the correct audit policies. When automatic Windows auditing is enabled, V3 will be configured automatically.
RPC auditing?
RPC auditing is additional and improves security visibility and unlocks more identity detections. By default, RPC auditing is not enabled. Enabling RPC is currently only possible via the device tagging mechanism; this can be enabled via the manual device tag assignment or via the rules management.
Personally, I would recommend using the rule management to be sure the RPC audit tag is included for all devices and upcoming devices. Once applied, the configuration is enforced on all existing and future devices that match the rule criteria. The tag would be visible in the device inventory.
Tag name: Unified Sensor RPC AuditAsset rule
In the Microsoft Defender portal, navigate to: System > Settings > Microsoft Defender XDR > Asset Rule Management. In the portal of Defender we need to create a new rule.
Rule conditions can be created with the use of Device name, Domain or device tag to target the desired domain controllers. When the tag is assigned to the device, the RPC auditing will be enabled. It will take some time before RPC auditing is enabled.
Sources
Microsoft: Configure Defender for Identity to collect Windows events automatically (Preview)
1 Comment
Leave a Reply
I have some questions of you dont mind mind. Does v3 still need the GMSA & does the permissions for GMSA on recycle bin/deleted object still need to be set? What happens if DC got the GPO’s and also the new Auto Audit Config? What will test-mdireadiness & new-mdiconfigurationreport show of you only have the Auto Audit Config enabled and not the GPO?