Defender Blank Initiator : LDAP queries searching for all groups or network configuration objects

⚠️ Warning: If you are enabling the registry keys for the following sections:

• Enable LDAP query auditing (above Value of 3)
• Enable LDAP bind auditing

Enable them only during your investigation. Once complete, disable them. Do not leave these settings running on all your domain controllers, as this will have an adverse effect on performance.

Recently, I ran into a frustrating situation in Microsoft Defender for Identity:

Actors on <server> sent suspicious LDAP queries to <dc> searching for all groups or network configuration objects. The initiator was blank.

The fact that the initiator field was empty meant I had no clear picture of who actually ran the query or which process generated it. Without this, the alert was only half useful.

I decided to dig into why the initiator was missing and how to configure both Domain Controllers and clients so that these alerts become fully actionable.

Step 1: Checking the Domain Controllers

On a Domain Controller, LDAP auditing relies on a mix of registry keys and audit policy settings. Here’s what I checked.

LDAP Query Auditing (Event 1644)

This is controlled by the 15 Field Engineering registry key:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' |
Select-Object '15 Field Engineering'

• 0 = Disabled (default)
• 1-5 = Increasing verbosity (5 = log all queries, including expensive ones)

LDAP Bind Auditing (Event 2889)

This is controlled by the 16 LDAP Interface Events key:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' |
Select-Object '16 LDAP Interface Events'

If missing or 0, you won’t see bind events like 2889 (which log client IPs and insecure bind attempts).

Directory Service Access (Event 4662)

Finally, I checked whether auditing for directory service access was enabled:

auditpol /get /subcategory:"Directory Service Access"

Step 2: Checking the Clients

Even if the DC logs LDAP queries, you still need visibility on the client side to know which process actually made them.

I ran:

auditpol /get /category:*

What I found:

• Logon/Logoff → Logon (4624) = Disabled
• Account Logon → Kerberos (4768, 4769, 4771) = Disabled
• Detailed Tracking → Process Creation (4688) = Disabled

That explained why Defender couldn’t correlate the initiator: the client wasn’t recording process-level details, so the DC’s logs couldn’t be linked to anything useful.

Step 3: Fixing the Gaps

Depending on what is enabled or disabled this is the plan to fix the blink spots and get the data required into the Defender alerts.

On Domain Controllers

1. Enable LDAP query auditing (Event 1644):

   Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' `
   -Name "15 Field Engineering" -Value 5
   

   ⚠️ Caveat: Setting this to 5 is very verbose and can flood logs. In production, 3 is a more balanced value unless you’re actively investigating.

2. Enable LDAP bind auditing (Event 2889):

   Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' `
   -Name "16 LDAP Interface Events" -Type DWord -Value 2
   

   ⚠️ Caveat: Event 2889 only appears for unsigned/simple binds. You won’t see all binds, only the insecure ones.

3. Restart the AD DS service or reboot for changes to take effect.

On Clients

Configure via Group Policy:

• Audit Logon/Logoff → Logon = Success + Failure
• Audit Account Logon → Credential Validation = Success + Failure
• Audit Detailed Tracking → Process Creation = Success

To ensure process command-lines are recorded:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" `
/v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Step 4: Validation

After rebooting the DC and updating the client’s audit policies, I ran a test LDAP query:

Get-ADGroup -Filter *

This time I saw:

• DC → Event 1644 (LDAP query), Event 4662 (object access), Event 2889 (if bind unsigned).
• Client → Event 4688 (process creation with command line), Event 4624 (logon).

When Defender surfaced the next LDAP alert, the initiator field was finally populated.

Conclusion

The “initiator = blank” issue comes down to missing logging on both the Domain Controller and the Client workstation:

• On the DC, you need 1644 + 2889 enabled to see LDAP queries and binds.
• On the client, you need 4624, 4688, and optionally Sysmon, to see who/what initiated the traffic.

Without both sides, Defender simply doesn’t have enough data to tell you who the actor was, then remember once you found the perpetrator/cause you need to disable verbose logging on your domain controllers.