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

Chuck Badeau 41

Hi,
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 (https://www.reddit.com/r/paloaltonetworks/comments/pl5dm7/new_2019_dc_event_log_messages_from_panos_userid/).

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.

Thanks,
Chuck

Adams, Bill 6 Reputation points

2021-09-28T02:31:26.71+00:00

Same issue - Verified that we did install the KB5005112 on 8/19/21 - did not begin to see errors until application of KB5005568 on 9/26/21. began to see the errors shortly after the 2am application (2:00:52)- Errors are now continuous. Still no resolve that I have found other than rollback - ANYBODY find anything?
sabasigh 6 Reputation points

2021-10-01T12:47:07.193+00:00

Having the same issue on 2019DC's when we are querying WMI for events (errors/warnings) nightly. We get the error but the Powershell script that runs from a remote server is still able to pull the events. And so far no other clients appear to be creating this error when talking to the DC's
SimSama 11 Reputation points

2021-10-04T23:53:58.437+00:00

The fix related to this didn't work?

https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c

Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel set to 0x00000000 and Reboot server.

The other is go to dcomcnfg, My Computer -> Properties -> Default Properties --- Reverse of what others said, set Default Authentication Level to Connect, and Default Impersonation Level to Identify.

Also go to COM Security, Edit Limits on both options, make sure user is manually added to local and remote access, local launch, remote launch etc.

Give those a go and see if any stick?
Peter Attwood 1 Reputation point

2021-10-05T06:33:10.187+00:00

Also my first time here. Have the same issue on a 2019 DC which is replacing an SBS 2011 DC which is causing the error - The server-side authentication level policy does not allow the user (sbs user) from address SBS 2011 address to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
10036 Error Microsoft-Windows-DistributedCOM
Tried the various suggestions but nothing gets rid of this. Does anyone know how to solve it? I pland to remove the sbs 2011 from the domain but wanted to get my new server error free first.
MJ Coronel 1 Reputation point

2021-10-08T01:11:07.897+00:00

This update KB5005568 also broke WMI Polling method in our monitoring. (SolarWinds)
WMI Polling fails all the time and we are getting"RPC server is unavailable" when testing WMI connectivity using wbemtest. Uninstalling the update resolved the issue, but we'd like to have the update installed without getting any WMI polling issues at all. Does anyone have this resolved from their end, can you share us what steps were taken to fix it? It would be greatly appreciated.

Keep safe everyone!
Talal Al-Mazrui 1 Reputation point

2021-10-09T18:56:57.77+00:00

Anyone had any luck with this so far? Getting the same as OP (Palo alto service account).
Micael Carlsson 1 Reputation point

2021-10-17T12:30:44.36+00:00

Hi the solution for me was to update the client server with the same patches and also using your tip:
Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel set to 0x00000000 and Reboot server.

Many thanks
Klein-Wiele, Jonathan 11 Reputation points

2021-10-18T05:49:12.17+00:00

Hi micaelc,

can you explain some more how you resolved it finally?
We are having same issues with 2019.

Do i get it right that you uninstalled the CU of September, then set the Regkey, then installed the small update kb5004442 and then again the CU and then it worked without errors?
Micael Carlsson 1 Reputation point

2021-10-18T06:42:51.057+00:00

Hi.

I didn't uninstalled the patch, the error was created from another server that wasn't updated with the latest windows patches, when I updated that server too the error in eventlog disapered. Before that i did the following:
Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel set to 0x00000000 and Reboot server.

But that didn't solve the issue, installing all patches on the server that created the event did. I saw the ip-adr in the event so I knew what server that I needed to patch also.

Hope this answer helps you?

BR

Micael
Micael Carlsson 1 Reputation point

2021-10-18T06:52:45.833+00:00

This is the error that was created in the eventlog for me, I could see the ip-adr from where it come, I updated that server too with the latest patches and the error went away:

The server-side authentication level policy does not allow the user DOMAIN\useraccount SID (S-X-X-XX-XXXXXXXXXX-XXXXXXXXXXX-XXXXXXXXX-XXXXXXX) from address XX.XX.XX.XX to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

BR

Micael
Klein-Wiele, Jonathan 11 Reputation points

2021-10-18T07:59:07.577+00:00

Ok thanks for your reply that makes sense but that doesn't work for any appliances like Firewalls (Checkpoint) which basically have no patch available. Any idea how to fix it with that kind of servers?
Micael Carlsson 1 Reputation point

2021-10-18T08:38:38.293+00:00

No sorry, the fix for us was only regarding Windows server 2016 and 2019.
Andy Wodarczyk 1 Reputation point

2021-10-19T04:13:27.32+00:00

Had this issue first appear for me at the beginning of 2021. Determined that this registry key on the client HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\LegacyAuthenticationLevel was created and set to 1 (meaning no authentication) by an app. From what I read if the key is not present authentication requirements are connect (equal to a value of 2). I updated the registry key value to 2. Additionally we were also seeing the Windows 10 search bar on the client be non-functional (black box). That issue was also solved by updating the above key value. Note that connect (value of 2) does not appear to meet the requirements of the event viewer log which states packet integrity which should be 5, but none the less this did clear the error on the server and resolve the Win 10 search bar on the client.
Jason 1 Reputation point

2021-10-19T18:12:21.69+00:00

We are experiencing the same issue. Hard fail, no work-around. We are trying to remove the patch now.
Heonmin Lim 1 Reputation point

2021-10-22T22:18:07.953+00:00

Updating client Windows machines with a recent OS patche (10/12/2021 Update package) just resolved this problem. No registry hacks were needed.
Jason 1 Reputation point

2021-10-25T12:54:23.187+00:00

You may need to try a beta firmware. Our vendor happened to release a beta that patches this issue the same day we started seeing the problem.
Jason 1 Reputation point

2021-10-25T12:55:21.58+00:00

You may need to try a beta firmware. Our vendor happened to release a beta that patches this issue the same day we started seeing the problem.
Jason 1 Reputation point

2021-10-25T12:57:07.997+00:00

The issue is not so much of a problem if you have a Windows only environment, but if you have network devices that use AD or RADIUS, a Windows Update will not resolve the issue.

18 answers

Limitless Technology 39,351 Reputation points

2021-09-24T11:00:25.12+00:00

Hello ChuckBadeau

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

Prerequisite:

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

https://support.microsoft.com/en-us/topic/kb5005112-servicing-stack-update-for-windows-10-version-1809-august-10-2021-df6a9e0d-8012-41f4-ae74-b79f1c1940b2

As always if you have any questions please don't hesitate to contact us.
Please sign in to rate this answer.

1 person found this answer helpful.
Jordan Burch 1 Reputation point

2021-09-24T13:53:53.177+00:00

I am having a similar issue with PRTG monitoring other devices using WMI. I will try to update the PRTG remote probe with the security update to see if it fixes this issue.

Chuck Badeau 41 Reputation points

2021-09-24T16:45:08.513+00:00

Hi,
Yes, KB5005112 was installed successfully last month.

Thanks,
Chuck

NP 1 Reputation point

2021-09-30T13:52:27.767+00:00

Had the same thing here but have since uninstalled KB5005568.

Raised a ticket with PRTG who advised to start dcomcnfg, choose "Component Services" > "Computers" > "My Computer" > "Properties". Set "Default Properties" Change "Default Authentication Level" to "Packet Integrity" rather than "Connect"

Not tested this yet.

Chuck Badeau 41 Reputation points

2021-09-30T13:57:26.663+00:00

We were advised of the same work-around by Palo Alto. We tried and it did not resolve. Will be curious what your results are.

NP 1 Reputation point

2021-09-30T14:04:01.373+00:00

Interesting, will keep you posted. FYI, our DCs are Server 2016.
Sign in to comment
wrr 6 Reputation points

2021-09-27T16:56:49.103+00:00

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
Please sign in to rate this answer.

1 person found this answer helpful.
wrr 6 Reputation points

2021-09-27T18:22:46.93+00:00

Adding more info, servers completely updated up to September 2021
Sign in to comment
Michael R. Dowless 6 Reputation points

2021-09-27T23:44:03.49+00:00

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.
Please sign in to rate this answer.

1 person found this answer helpful.
Shan 0 Reputation points

2023-06-15T00:22:45.89+00:00

Hi Did you find the solution for this ? I'm getting the same error on my both DCS from PaloAlto account.
Sign in to comment
Frank van den Bogaard 6 Reputation points

2021-09-30T06:06:24.373+00:00

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.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment
Anonymous

2021-12-03T19:58:56.293+00:00
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.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment