Event 10036 on Domain Controllers that have Active Directory WMI polling in InsightIDR

After installing KB5004442 on our domain controllers (September Security Update from Microsoft addressing CVE-2021-26414 - “Windows DCOM Server Security Feature Bypass”), our domain controller logs are flooded with Event 10036:

The server-side authentication level policy does not allow the user *DOMAIN\DOMAIN_ADMIN* SID (%%%%%%) from address to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

(domainname, domain\domain_admin, SID%%%%%%,

We use WMI polling to connect to our domain controllers in InsightIDR to collect log entries. With this Microsoft security update, the logs are now telling us the IDRCOLLECTOR server is trying to activate the DCOM server on our domain controllers with a low authentication level (there are currently 7, from 0 - 6). According to Microsoft, the only one that should still be used to avoid any issues is levels 5 (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY), because eventually (Q2 2022), the low level authentication will be deprecated (see Timeline).

There’s a couple ways to stop the logs from generating:

  1. Create and disable “RequireIntegrityActivationAuthenticationLevel” registry setting - which would be less secure and will eventually be deprecated.
  2. Use the Insight Agent for Domain Controllers exclusively (do away with WMI polling).

Neither of these options are appealing to us. Is Rapid7 aware of this issue and making the necessary changes to make WMI more secure?


Other vendors with this issue:

Hello Jason, just wondering if you have verified wmi permissions. maybe something changed or was removed? and that user has permissions, I believe since it is a DC it would need DA or built in administrator rights.

Hi Jason,

Thanks for getting in touch.

I can confirm that the Developers are well aware of this issue and are in fact in the final stages of preparation to roll out an update to event sources that utilise the WMI component; so they can interact without error with Windows assets that have the DCOM hardening applied.

This has been confirmed to work within all of the testing environments and I’d be happy to update this post when the release has been deployed.

All the best,

1 Like


Thanks for the update. Please update this post when the release is deployed.

Thank you,

Likewise, we are also getting reports of the same event on our domain controllers with the Microsoft update applied. It would be good to know when the release has been deployed so that we can confirm that the issue has been resolved.

Hi Guys,

While we all wait for the fix for this to be ready, if you wanted to prevent the constant Event 10036 logs you have the option to install the Insight Agent on your Domain Controllers and stop the AD event sources, seeing as it can collect the same default event codes.

If you aren’t already using this feature you can enable it in settings by going to Insight Agent> Domain Controller Events.

However in scenarios where you are using the Active Directory event source and have ticked "Send Unparsed’ to gather events not on the default list, this is not possible with the Agent method.


@sean_stanley1, any updates on when we can expect this to be fixed?

Hi Jason, this issue is currently in the UAT phase on the backend now so while we have no eta just yet, this is indeed nearing completion at this point.

Hi All,

Thank you for your patience while the Engineering team worked on implementing this fix for the DCOM authentication errors.

This has now been deployed publicly to all Collectors and event sources that use the WMI method of collection.

If you have opted to use Agents to collect the Security logs from Domain Controllers and temporarily stopped Active Directory event sources you can now start the event sources and report back if you are continuing to see errors in Event Viewer.