Comments
11 comments
-
Hi @further,
TLDR You will need to apply the Windows June 2022 patch to the base monitor server and then it will be able to communicate with the monitored entities you have updated.
Please see my comment here for more infohttps://forum.red-gate.com/discussion/comment/168333/#Comment_168333
Kind regards,
Alex -
I patched the redgate server to equal the monitored server and that did not fix the problem.
-
Hi @further
What Windows version is the base monitor on and what was the patch you applied?
Did you previously apply the registry workaround to disable the hardening on either the monitored server or the base monitor server? And if so, have you re-enabled the hardening changes?
Kind regards,
Alex -
Windows Server 2016 is the base server. I did not edit the registry on the base server, but the monitored server was edited and then removed only to be needing to be edited again to fix it.
KB5004442 is the offending patch which I was told is rolled up into KB5014702.
Do I need to edit the registry on the base server? -
Hi @further,
Just to confirm, you applied the monthly KB5014702 (which includes the KB5004442) to the base monitor server as well? Was the server was restarted during the patching?
The registry change to disable the hardening shouldn't be needed on either server after both servers are on the same patch version, this is what we've seen with other customers who have run into this, updating the base monitor server as well got things working.
Also, do you have the base monitor and web service on the same server?
Kind regards,
Alex -
Server was restarted. The base monitor and web service is on the same server.
-
Is this only happening on one monitored entity? And what is the error you are seeing on it? Also what OS and SQL Server version is it.
And what version of SQL Monitor are you currently using?
-
It's happening on every monitored SQL server that was patched with the June 2022 patch set from Microsoft. Multiple versions of SQL Server (2019, 2017, 2016) on Windows 2016 and 2019.
I believe this is the error, i x'd out our server names:
The server-side authentication level policy does not allow the user xxxx x\redgate SID (S-1...... ) 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.
-
Sorry I should have been more clear - what error are you seeing in SQL Monitor for connecting to those entities?
SQL Monitor uses Packet Privacy to connect, and in all other cases we've seen so far of this once the update was applied to the base monitor server everything connected in SQL Monitor (showing that it is using Packet Integrity or higher as otherwise it would still get the error).
-
well... my coworker who reported this issue has just now tried to replicate it to grab the error and it now works as it's supposed to. thank you for your assistance!
-
Great stuff, glad it's all working now!
Add comment
Please sign in to leave a comment.
The server-side authentication level policy does not allow the user xxxx x\redgate SID (S-1...... ) 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.
Turns out KB5004442 security update changed the default from disabled to enabled.
June 14, 2022
Hardening changes enabled by default but with the ability to disable them using a registry key.
Workaround:
Registry setting to enable or disable the hardening changes
During the timeline phases in which you can enable or disable the hardening changes for CVE-2021-26414, you can use the following registry key:
Note You must enter Value Data in hexadecimal format.
Important You must restart your device after setting this registry key for it to take effect.
Note Enabling the registry key above will make DCOM servers enforce an Authentication-Level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation.