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

Penny Bristow 6 Reputation points

2021-11-04T21:07:26.99+00:00

I have an old dc 2012 R2 and am also seeing it as it was also in the Oct 14th patch
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Alex 1 Reputation point

2021-11-10T02:12:12.463+00:00

Hey all,

For anyone still seeing this issue, you have to make sure both the server doing the scanning and the server being scanned are both up to September or newer patch. If you updated your DC's but the server or collector scanning them is not patched, it will generate these errors. Updating both sides to September or newer patch should fix it.

Thanks
Please sign in to rate this answer.
Hunor Miklós 1 Reputation point

2021-11-10T07:41:07.993+00:00

It's ok if you have a >2016 server! But what do you do if you only have 2008R2 on other side and 2019 in this situation?

Jenny Chen (Pactera Technologies Inc) 1 Reputation point

2021-11-10T07:47:09.417+00:00

same issue repro on win2016 DC, even installed the lasted Nov updates.
Application C:\Program Files (x86)*.exe with PID 1190 is requesting to activate CLSID {D99E6E74-FC88-11D0-B498-00A0C90312F3} on computer *DOM.NET with default activation authentication level at 2. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.

Scott Owens 1 Reputation point

2021-11-10T14:16:28.137+00:00

I am still seeing this error on the DC and the DC is patched. The other side is not a DC, but a Palo Alto firewall.

Alex 1 Reputation point

2021-11-10T19:58:55.403+00:00

I'll admin I haven't looked as closely at this situation and patches for 2008 R2 since we only have a few dozen 2008 R2 servers left and none of them would be polling over WMI, so updating the 2008 R2 side doesn't work? The CVE that kicked off this change, CVE-2021-26414, does list the June update as a fix for 2008 R2 so I would expect patching up to September would also work for it. Not that I would be surprised if it doesn't work however, as we've seen with other recent security fixes in patches, Microsoft is perfectly content leaving 2008 R2 and 7 in a non compatible or not working state, either on purpose or because of a technical limitation.

If both sides are updated to newer patches (probably at least September but definitely at least June), I would perhaps at least try setting that RequireIntegrityActivationAuthenticationLevel registry key to disabled on both sides (restarts also required after changing it). I know people have said this doesn't work but I don't know if I've seen anyone say they have tried it on both sides. Do note that even if this works however, when Microsoft starts enforcing these hardening changes and disables the ability to disable them in Q2 2022, the errors might not only come back but WMI queries might actually fail at that point.

If also patching the 2008 R2 doesn't work I would maybe also suggest opening a support ticket with Microsoft and seeing what they have to say about it.

Let me know how it goes!
Thanks

Alex 1 Reputation point

2021-11-10T20:22:47.247+00:00

So we don't have Palo Alto firewalls ourselves but if that's what the other side is that's doing the WMI polling, my understanding is that it's recommended to disable Client Probing, which is likely what's doing the WMI probing, and possibly changing to WinRM over Kerberos. Palo Alto actually recommends disabling this feature and recommends some other options here- https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/user-id/user-id-concepts/user-mapping/client-probing.html.

If you can't disable it for some reason and definitely need WMI probing on, I'm not really sure what the answer there is. Maybe opening a support ticket with Palo Alto and seeing if they have plans to increase the authentication level but my guess is that they would just say that they don't recommend using this feature anymore.

Apologies if this isn't the right info for you, as I said I don't work with these in my current role and this is just what I gathered from some online digging.

Let me know if that did the trick for you though!
Thanks

Scott Owens 1 Reputation point

2021-11-10T20:37:56.2+00:00

I am now using the Palo Alto User-ID Agent installed on the DC instead of the WMI polling and no longer seeing the DistributedCOM errors on in the Event Viewer.
Sign in to comment
Manish Chaudhary 6 Reputation points

2022-02-03T20:41:05.94+00:00

This isn't an issue only with Server 2019 but with all 2012 R2 and above. 2019 was observed first coz the update or patch was released for it in Sep2021 and 2012 R2 in Oct 2021 CU.

Don't do registry changes recommended here, that will just bring back the issue in consecutive patches as this is a needed security patch of a vulnerability and Server hardening done by Microsoft. WMI hardening in effect is optional until March 2022, and by June 2022, you cant change it, it will again cause the same issues and flaring Event logs in System on all Windows server.

You've to go to your vendor who is using WMI to poll servers for Event logs, to give you either WinRM Over Http, WInRM over Http using Kerberos for encryption as well, WinRM over Https using kerberos etc methods.

Here is a nice article from users from Palo Alto vendor which highlights the issue and what consumers have tried so far to resolve it. Registry fixing is very temporary.
https://live.paloaltonetworks.com/t5/general-topics/i-am-having-pan-os-integarted-user-id/td-p/439686
Please sign in to rate this answer.

0 comments No comments
Sign in to comment