Event log message

[pjayme]

Can someone provide some direction with this please?
Thanks.

The server-side authentication level policy does not allow the user DPS\038815 SID (S-1-5-21-2260375648-3386735697-1685888974-3386) from address 10.51.107.48 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

[Bruce_B · Accepted solution]

As we received a question via email that referred to this topic, we've added our response below. It may be of interest to others affected by this issue.

We've performed internal testing and checks and have also validated our response to the recent DCOM hardening changes performed by Microsoft. 

Firstly to contextualize this fully. In June of this year we discovered that Microsoft was planning to make changes that directly impact the way Lansweeper connects to Windows computers in context of agentless scanning. Lansweeper uses DCOM to set up an RPC connection with Windows computers. 

This change was introduced in the June monthly update, as an optional registry change that was disabled by default. When setting this registry key as enabled, any agentless scanning was met with RPC or WMI access denied errors, and RPC authentication level errors in the eventviewer of the scanning server. This was the case regardless of the RPC authentication level we set our application to (counter to what the error in the eventviewer indicates).

Our developers investigated this issue internally and set up communication with Microsoft developers. The ending conclusion was that a change in Microsoft's implementation was necessary, and no Lansweeper change. Starting with the August monthly update KB5005033, the registry key can be activated without impacting Lansweeper agentless scanning.

Our internal testing has consistently shown that scanning a remote computer without an agent is successful if the following is true:

• The computer is running the September monthly update (or October preview)
  
• The scanning server is running the September monthly update
  
• The registry key is set to 1 or 0 (or doesn't exist, which currently should mean it's set to 0)

We've found no circumstance where all components are on the latest patch level, and all scanning requirements are met, that the RPC_C_AUTHN_LEVEL_PKT_INTEGRITY errors are thrown (or RPC/WMI access denied errors in Lansweeper). As such our current recommendation is to ensure the servers involved are fully up to date and meet the agentless scanning requirements: https://www.lansweeper.com/knowledgebase/domain-scanning-requirements/

Since this was also mentioned in the forum post, the update from Lansweeper version 8.4 to 9.0 can ordinarily not be involved in this, as there have been no changes to the way Lansweeper authenticates with Windows computers.

As an aside as well, we have seen mention in a non-Lansweeper context that users are running into this RPC authentication level error in unexpected circumstances, for example in the microsoft community post linked below. This does make it appear as though there's something going on with the latest Windows updates. Though again, we could not reproduce it.

https://docs.microsoft.com/en-us/answers/questions/564347/server-2019-update-kb5005568-sept-2021-forcing-new.html

[masterblaster]

This is 100% being caused only by Lansweeper application. I have tested PDQ inventory, Deploy, Dell scanning apps, HP, etc and none produce this error after the recent Windows update.

Website Version: 9.0.10.2

35000 errors are present in our event logs over all devices in our environment.

[jean_meyer]

pjayme wrote:
Can someone provide some direction with this please?
Thanks.

The server-side authentication level policy does not allow the user DPS\038815 SID (S-1-5-21-2260375648-3386735697-1685888974-3386) from address 10.51.107.48 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

I am seeing the same since I upgraded from version 8 to 9.0.0.17.
It does not affect anything from working and I am not 100% sure yet that it is the upgrade or something else, but it seems to be related to a Jun update:
https://www.csoonline.com/article/3622168/how-to-test-the-impact-of-new-windows-dcom-server-authentication.html
Still busy investigating, would like some more feedback to help find the solution/reason for the events popping up all over my clients.