What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

DCOM Security

Votes:

4

Your Vote:

Up

Down

Hello,

After install update KB5004442 we have an issue with PRTG. "The server-side authentication level policy does not allow the user %user% from address #### to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

On Microsoft has an information "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"

This function cannot be deactivated for safety reasons.

Can the PRTG solution for this issue?

dcom security wmi

Created on Oct 6, 2021 8:09:26 AM by  z2deker (4) 1



16 Replies

Votes:

0

Your Vote:

Up

Down

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

Created on Oct 7, 2021 11:36:44 AM by  Marijan Horsky [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Team Tech Support,

Has the problem described above been fixed?

Best Regards, Andrey

Created on Oct 29, 2021 2:59:33 PM by  Maksim Aga (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Nov 1, 2021 9:28:08 AM by  Marijan Horsky [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Nov 2, 2021 11:06:34 PM by  duanef (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Nov 5, 2021 1:07:44 PM by  Marijan Horsky [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jan 20, 2022 5:33:50 PM by  Patrick_K (0) 1



Votes:

1

Your Vote:

Up

Down

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

Created on Feb 21, 2022 3:13:34 PM by  JeroenDeckers (10) 1



Votes:

1

Your Vote:

Up

Down

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

Created on Feb 22, 2022 2:04:26 PM by  Marijan Horsky [Paessler Support]



Votes:

2

Your Vote:

Up

Down

@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?

Created on Feb 23, 2022 2:33:45 PM by  Agnieszka Wiatr (23) 1



Votes:

1

Your Vote:

Up

Down

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.

Created on Mar 3, 2022 9:11:20 AM by  ArSo (10)



Votes:

2

Your Vote:

Up

Down

Same here, waiting for PRTG to provide a fix.

Created on Mar 15, 2022 12:40:41 AM by  petstock (20)



Votes:

1

Your Vote:

Up

Down

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.

Created on Mar 15, 2022 5:02:13 PM by  trrobinson (10)



Votes:

0

Your Vote:

Up

Down

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?

Created on Jun 24, 2022 11:31:49 AM by  woodsb02 (0)



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 28, 2022 6:03:18 AM by  Marijan Horsky [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 17, 2022 5:05:37 PM by  Johnknows (0)



Votes:

0

Your Vote:

Up

Down

Hi there,

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

Created on Jul 20, 2022 6:55:51 AM by  Moritz Heller [Paessler Support]

Last change on Jul 20, 2022 6:56:07 AM by  Moritz Heller [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.