Server 2019 update KB5005568 (Sept 2021) forcing new DCOM authentication prematurely

Chuck Badeau 41 Reputation points

We recent applied KB5005568 (Sept 21 update) to one of our Server 2019 DCs. After applying, we started receiving many DCOM error events 10036 (Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application) for a user id function on our Palo Alto FW (It uses a service account to resolve user identification from AD). Having read up on Microsoft's transition to a minimum of Packet Integrity for DCOM authentication (see June's KB5004442 and the DCOM issue described in CVE-2021-26414), it would appear that, at least in Server 2019, this feature has been enabled prematurely (Supposed to be Q1 2022 based on the timeline in the KB5004442) and the described reg entry to temporarily bypass the DCOM update does not work (it is supposed to be valid all of 2022 after the feature is enabled).

Our only solution has been to roll back the patch on our DC. I found one reference to someone else encountering the same. They have mixed OS's for DCs and are only seeing the issue on 2019 (

Is anyone else seeing this behavior with the pending DCOM update?

First time posting here and really just trying to see if this is on MS's radar at all.


Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management, data storage, applications, and communications.
2,671 questions
{count} votes

18 answers

Sort by: Most helpful
  1. Limitless Technology 37,786 Reputation points

    Hello ChuckBadeau

    Could you confirm that you have installed the Prerequisite for this security update:


    You must install the August 10, 2021 SSU (KB5005112) before installing the LCU.

    As always if you have any questions please don't hesitate to contact us.

    1 person found this answer helpful.

  2. wrr 6 Reputation points

    Having exactly the same issue here. Tons of events starting exactly on August 27 in the Windows 2019 Domain controllers. Not affecting Windows 2016 DCs

    1 person found this answer helpful.

  3. Michael R. Dowless 6 Reputation points

    Can confirm we are getting the same error on 2016 DCs. Started 9/26/2021 at 4:39:45am. Looks like an LDAP call from our Palo Alto PA5250 firewall service account.

    The server-side authentication level policy does not allow the user <Domain>\svc_PA5250LDAP SID (SID Value) from address <IP Address> to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

    1 person found this answer helpful.
    0 comments No comments

  4. Frank van den Bogaard 6 Reputation points

    We have the same problem with our Nagios monitoring system on Windows servers.

    removing KB5005568 did not solve the issue.

    and raising the authtentication level on dcom did also not resolve it.

    1 person found this answer helpful.
    0 comments No comments

  5. Carson Wilson 6 Reputation points

    I have just spent days struggling with this new DCOM message on several newly-built Windows Server 2022 platforms. My finding is that, although the 10036 events being logged appear to indicate actual failures regardless of how I set my RequireIntegrityActivationAuthenticationLevel registry entry, testing with New-CimSession shows that the registry entry actually does control hardening.*

    Currently on my Windows 2022 servers, I find that:

    • Without the registry entry, hardening is not enabled, but error 10036 is logged regardless;
    • With the registry entry set to 1, hardening is enabled and the same 10036 error is logged.

    More briefly, I think much confusion is being caused because Windows Server 2022 is logging the exact same error regardless of whether the new DCOM hardening is being enforced.

    Caveat: this article explains that as of Q2 2022 this will no longer be the case, and hardening will be in effect regardless of the registry setting.

    *New-CimSession -ComputerName mycomputer -SessionOption (New-CimSessionOption -Protocol Dcom) -Credential "MYDOMAIN\mylogin" fails when the registry entry is set to 1, and otherwise succeeds.

    1 person found this answer helpful.
    0 comments No comments