DCOM Security

Hey,

This is currently a bug which is caused by this update. We already opened up a bug ticket for our developers. Currently we need to ask you for a little patience as we don't know when the issue will be fixed.

Kind regards,
Marijan Horsky, Team Tech Support

Hello Team Tech Support,

Has the problem described above been fixed?

Best Regards, Andrey

Hi,

The issue should be fixed by Microsoft in Q1 2022.
More information about this can be found here.

Kind regards,
Marijan Horsky, Team Tech Support

Marijan, that's not what the Microsoft document says. It says: "If you find issues during testing, you must contact the vendor for the affected client or server software for an update or workaround before early 2022."

So what we are doing here, is contacting you. And you're saying Microsoft is going to fix it. All Microsoft has done is provide a registry key to disable the requirement - for the time being.

Hey,

There is not much we can do on the PRTG side, basically with the first Fix Microsoft, most probably, messed up the default auth level resolve mechanism in DCOM, which PRTG also uses, as most Software should. So on our side we cannot do much more as Microsoft needs to fix this issue and not all other software vendors.

Kind regards,
Marijan Horsky, Team Tech Support

FYI:

How does Microsoft plan to address this vulnerability?

Microsoft is addressing this vulnerability in a phased rollout. The initial deployment phase starts with the Windows updates released on June 8, 2021. The updates will enable customers to verify that any client/server applications in their environment work as expected with the hardening changes enabled.

The second phase, planned for an early Q1 2022 release, programmatically enables the hardening on DCOM servers by default that can be disabled via the RequireIntegrityActivationAuthenticationLevel registry key if necessary.

The third phase, planned for Q2 2022, enables the hardening on DCOM servers by default and will no longer have the ability to be disabled.

Are there system events available that will help me identify the client devices that will be impacted by the change?

Yes. See the New DCOM error events section of Managing changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414).

Source: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26414

Having the same issue. Do we need to wait for Microsoft to solve this? Are we waiting for an update from PRTG?

Hey,
We are also waiting for Microsoft as the issue occurs because of Microsoft.

@z2deker, @JeroenDeckers,

Where did you get this error? with which sensor? i am trying to reproduce this problem and cant figure out how to break prtg. Is it just some specific sensors?

Is there is a fix for this yet? This problem might have been caused by Microsoft but the change is due to security hardening and will not go away because is per (new) design. Paessler please provide a fix or recommendation on how to adjust windows settings.

Same here, waiting for PRTG to provide a fix.

After much testing and some back and forth; Paessler left out some info I feel would have helped clarify and reduce our angst.

PRTG is using the lowest level of authentication allowed by the OS by default but will use a higher level if the OS forces it to. (I don't personally agree with this approach but it is their right to do so.)

The registry key provided by Microsoft with the initial patch can be set to 0x00000001 on the probe which will force the system to use the higher level of authentication and stop the errors.

I can also confirm that applying the March patch to the probes resolves the issue as well as it sets the registry key to 0x00000001 instead of 0x00000000 like it did in the initial patch.

TLDR, patch your probes with March 2022 patches and you should be ok.

This situation just got more real - as pre the timeline on the Microsoft website, the June 2022 cumulative updates patch set enabled this hardening setting by default, which broke PRTG WMI monitoring in our environment.

The work around for us was to create the registry key RequireIntegrityActivationAuthenticationLevel (set it to 0) on all of the machines being monitored by PRTG via WMI.

The next phase is March 2023, when the cumulative update patches released will prevent the above registry key from working around this issue.

My understanding is that correct solution is for PRTG to release an update for the WMI monitoring application to raise the activation authentication level used to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.

This is confirmed by Microsoft in Event Logs 10037 and 10038: " To raise the activation authentication level, please contact the application vendor."

Paessler devs - can you please investigate releasing this fix asap?

Can you confirm that you recently installed this Windows Update KB5014754?

Microsoft recently rolled out a patch which hardens the DCOM authentication, which can cause authentication login attempts to fail. You can try to roll back the update or remove the registry entry as described in the official document: https://support.microsoft.com/en-us/topic/june-14-2022-kb5014699-os-builds-19042-1766-19043-1766-and-19044-1766-5c81d49d-0b6e-4808-9485-1f54e5d1bb15

As first workaround you can use the following article to disable the hardening again: 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

In addition I would like to clarify the situation here. Instead of hardcoding the DCOM Configuration, PRTG uses the System default discovery of security settings of the System. This enable users to configure the (very frustrating way to define) DCOM Security once per System instead of multiple times per application. As long as the underlying system is configured correctly, PRTG can work with all security levels. In the first couple of iteration for the bespoke hardening, due to our inhouse testing and many customer reports, Microsoft seemed to have messed up the default discovery and therefore the System PRTG used didn't work out correctly. This has been silently fixed by Microsoft with one of the patches from the September or Oktober 2021 security update packets. In a fully updated and correctly configured environment, PRTG and WMI work flawlessly with the higher security levels. For this both Systems, the system of the PRTG Probe and the target must be configured correctly appropriate to the chosen security level (via dcomcnfg.exe). Which we tested with different OS Combinations and a couple of customers.

This whole situation brings us to the stand, that PRTG is prepared for the changes to go fully live without any changes needed. We are aware, that customer may face problems with inconsistently applied patches through their infrastructure. This is caused by an outside factor, so we concluded to not be able to do much about it. Configuring the DCOM Settings per Device target is not an sufficient solution and would make the whole system much more brittle and even would open up new vulnerability path's. Customer with major problems due to update processes can install a second remote probe with a different DCOM configuration and move/copy devices if really necessary.

Hope this gives you a better understanding what Microsoft did to the authentication and how to set the packet integrity correctly per host. Or to consider rolling back the update.

Thank you for the clarification, but which configuration paramters settings is ment : "For this both Systems, the system of the PRTG Probe and the target must be configured correctly appropriate to the chosen security level (via dcomcnfg.exe)."

i cant find a case or KB about the correct configuration of the DCOM's

Hi there,

we correspond to the DCOM settings on the Windows Servers as visible here: (direct link: https://postimg.cc/xJvg2VhM)

Hi there,

Can you please upload the picture again. It cannot open.

Thanks

Hi there,

the URL still works for me. Please try to open it in another browser/private tab.

Dear support, One of our server 2019 and server 2012 experiencing the same issue. I have done setting up DCOM authentication level as per discuss earlier for both PRTG server and client but issue still occur. PRTG server version 23.1.82.2074+

Please advise.

Same issues here. PRTG server is windows 2022 trying to do WMI to 2016, 2012r2 and 2019. All servers are fully patched to yesterday which is when MS changed the DCOM to ignore the reg bypass key.

So why is PRTG still sending WMI queries wrong?

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

Hi there,

Please ensure that both servers are on the latest patch. We made the experience that a missing Windows patch makes this change not effective.

Using the WMI tester will get "Access Denied". This is after we install update as below:

1. Server 2019 update KB5023702
2. Server 2012 R2 KB5023765

Uninstall the update will resolved the issue.

Moritz - All servers are on the same patch level with all the most up to date patches from Microsoft. This did not fix the issue.

After screwing with it for many hours I found the only way to make it work for me was to use the same domain account that PRTG was installed with as credentials for wmi. Before I would install PRTG with my admin account and then use a different admin account as the wmi credientials. Once I put in my admin account in the settings on the device or probe it worked. So I built a new remote probe and logged in as my monitor account to install PRTG and moved the devices to the new probe.

Maybe the devs can figure out why I can no longer install the software as one admin and pull wmi with another admin. Both accounts are domain admins with full admin access to the servers. I am seeing this issue with 2012r2, 2016, 2019, 2022.

Hi there,

Thank you for the update.

Please let me know whether you increased the DCOM security on Probe and target device? Furthermore, did you ensured that the corresponding user has sufficient access rights? https://www.ibm.com/docs/en/tivoli-monitoring/6.3.0?topic=configuration-creating-user-windows-management-instrumentation-wmi-permissions