Issues with regard to DCOM Security.

In the Windows Update KB5014754 Microsoft rolled out a patch which hardens the DCOM authentication, which can cause authentication login attempts to fail (usually a "access is denied" error is shown).

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 enables 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 October 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. To configure 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 paths. Customer with major problems due to update processes can install a second remote probe with a different DCOM configuration and move or copy devices if necessary.

Hope this gives a better understanding what Microsoft did to the authentication and how to set the packet integrity correctly per host.

We correspond to the DCOM settings on the Windows Servers as visible here: https://postimg.cc/xJvg2VhM