DCOM hardening on Windows Server June CU

[dasfliege]

We're scanning all our server if they are ready to get upgraded with the June cumulative update for Windows Server, as this CU contains a "fix" for a DCOM related vulnerability described here: https://support.microsoft.com/en-us/top ... ed901c769c

What we've found is, that servers that are backed up by veeam agent raise the following DCOM warning:
"The server-side authentication level policy does not allow the user domain\veeam-backup SID (S-1-5-21-2778164257-2245742617-1178902439-1604) from address x.x.x.x to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application."

Is veeam aware that installing this CU may could lead to problems? Is there anything we need to do, prior to install the CU?

[dasfliege]

Case #02680592

[johan.h]

This has to do with RPC communication. This updates forces a specific Authentication Level. This is a staged change by Microsoft. You can bypass this by changing the RequireIntegrityActivationAuthenticationLevel key.

I believe this will be addressed in line with VBR v12.

[kevlahau]

And this key would be under which hive?

[Origin 2000]

Its HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat as described in the MS KB.

[KoflerTx]

Why does it take Veeam so long to fix it? The change was announced by Microsoft a year ago, now it went live, but with workaround available.
No word from Veeam about it and customers running against the wall?

[dasfliege]

This is what i got from veeam support. So there seems to be no impact on backups even when the hardening is enabled.
But as the workaround will only be functional until march 23 and because it isn't that nice to have those false-positive events logged, i asked them to keep working on that "problem" and fix it. If Johan can confirm that it is on track for v12, then that may be well on time.

I've spoken to my colleagues and during their testing they haven't seen any issues happening with the backups. While the event still shows up in Event Viewer, there seems to be no functional issues due to it. In addition, we haven't seen any issues being reported by other customers who have went through with the update.

As far as we can see, the update doesn't seem to be causing issues with agent backups so it should be fairly safe to go through with it on any agent machines. If you run into any issues, you can also use the registry key provided in the KB in order to disable DCOM Hardening:

[ktsaved]

Upgraded the server Veeam is installed on to 2019 Std from 2012R2.
Immediately after this got errors that Veeam could not access the hosts to backup the VMs on them.

Applied the registry fix listed to the host with VMs to be backed up, rebooted the host then access was restored.

The hosts are 2012R2. No events were raised in Event Viewer.

Veeam will you be applying a solution for this as this registry change has no effect after March 2023?

[Dima P.]

Ken,

Can you please raise a support case and share the case ID with us?

Immediately after this got errors that Veeam could not access the hosts to backup the VMs on them.

Can you please also share the error text you got? Thank you in advance!

[_james]

Are there any news when a patch from Veeam could be expected?

For us Veeam One is no longer able to connect to Veeam VM; unfortunately for security reasons we cannot make a registry key change.

[HannesK]

Hello,
https://www.veeam.com/kb4376 - the software is already compatible. If you see problems, then it is caused by Windows.

Best regards,
Hannes

[_james]

Hello Hannes, thank you for the swift reply. You are correct, after updating our systems all Veeam components are able to communicate with each other again.

[masonit]

Hi!

Ran into this issue (https://www.veeam.com/kb4376) when trying to add a new hyper-v to one of our vbr. The hyper-v server has the lastest available updates (June 14, 2022 Hardening changes are enabled by default but with the ability to disable them using a registry key) with hardenend enabled. I know there is a workaround but that is not an option. If we would update vbr to same version then it should work fine to a add this hyper-v host. But could other things in the vbr environment stopp working then? Let's say that the vbr is updated but the proxy servers are not. What happens then? Or is it only communication to hyper-v that is affected?

Our hyper-v backup jobs are using "On-host backup" as proxy so that should be fine. But the repository is on a windows server. Does that Windows server also need this update? I understand that it is best to just update all Windows servers. But I try to understand what could happen if some are updated and some are not updated in the vbr environment..

\Maso

[HannesK]

Hello,

I understand that it is best to just update all Windows servers

Great Please install the security updates on all involved components. We don't test all possible bad practice combinations

Best regards,
Hannes