Emerson Exchange 365

Connecting to OPC.DeltaV.1 | Access is denied | 80070005

DeltaV 13.3.1

I am attempting to connect to OPC.DeltaV.1 on one of our application stations.  I am using OPCWatchit and no matter which machine i try from (other application station or proplus) i get the following.

Status: Server init failed: hr=80070005
Error Msg: Access is Denied

When I browse the OPC Server Names, the list populates correctly so they are enumerating, i just can't make the connection.

Naturally it appears to be an authentication issue but I haven't found any guidance for things to check.
DeltaVAdmin account is a local and domain account.

Ideas?

Invalid String

• 6 Feb 2023 10:15 PM
• Cancel

4 Replies

• Andre Dicaire

  

  • 6 Feb 2023 10:51 PM

  There are DCOM hardening changes in microsoft OS security patches. Emerson has released a DeltaV KBA NK-2200-0042 dealing with this. It indicates that local OPC client connections are not impacted, but remote connections could be impacted. The MS KB5004442 provides information on disabling the new hardened rules, which deal with "authenticalionlevel".
  
  you can access a copy of the KBA via Guardian.
  
  The OPCWatchit client is connecting with the interactive user. DCOM has user authentication settings that determine who can launch the server. If you'v applied a Microsoft security update to your v13 system, this may be the issue. Basically, what has changed since the last time OPC WATCHIT was working on other stations?

  Andre Dicaire

  • Cancel
• Invalid String

  

  • 6 Feb 2023 11:06 PM

  In reply to Andre Dicaire:

  Man, you are spot on!

  I was digging in the event logs and found where DCOM was not allowing the remote user to activate the DCOM server.
  It said to please raise the authentication level to RPC_C_AUTH_LEVEL_PKT_INTEGRITY in the client application.
  Instead,  followed the guidance here and disabled the hardening in the registry.
  Updates were applied some time back but connections to this particular OPC server are new so we didn't know it was "broken"
  
  Just rebooted and the connection came up just fine.

  Thanks Andre!!

  • Cancel
• Randy Pratt

  

  • 7 Feb 2023 2:24 PM

  In reply to Invalid String:

  In this case, it would seem that the DeltaV OPC Server machine was at a MS Patch level of after May 2022, and the client machine was at a MS patch level before November 2022.

  This solution may break again (or not).  The March 2023 MS security updates will disable the registry setting that disables the hardened mode.  With the March 2023 update, packet level integrity will be the minimum allowed with no way to override, ie. that registry setting will cease to work.

  But it probably doesn't matter.  If the client isn't somehow coded in a strange fashion, the November 2022 MS updates were to silently escalate to a minimum of packet level integrity in spite of what the client might initially ask for.

  So as per Microsoft KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)  

  "In response to your feedback, the November 8,2022 update includes a client-side (device, application, or service acting as a DCOM client) patch. This patch automatically raises the authentication level of all non-anonymous activation requests to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. If you use third-party Windows DCOM client applications and are dependent on the software providers to raise the activation authentication level to support DCOM hardening changes, this patch removes the dependency. This allows the activation authentication level to be raised automatically at the Windows OS level. This prevents the activation requests from being rejected by DCOM servers that have enabled DCOM hardening changes."

  As I interpret this, If we'd have waited until the November MS patches, no changes at all would have been necessary to most clients, other than the client side machine had to be updated to the November security updates.

  • Cancel
• Invalid String

  

  • 7 Feb 2023 5:25 PM

  In reply to Randy Pratt:

  Thanks Randy. You're correct, the machines were at a different patch level.
  This will be good to remember moving forward with our patch roll outs.

  • Cancel