Microsoft DCOM update|Classic OPC: DA, A&E, HDA, XML-DA, etc.|Forum|OPC Foundation

Microsoft DCOM update

MS has released a patch for DCOM that will impact all vendors selling OPC DCOM based products:

https://support.microsoft.com/…..ed901c769c

Key dates:

June 8, 2021 – Hardening changes disabled by default but with the ability to enable them using a registry key.

March 8, 2022 – Hardening changes enabled by default but with the ability to disable them using a registry key.

[Latest information from MS – Date has been revised to June 14,2022]

June 14, 2022 – Hardening changes enabled by default with no ability to disable them. By this point, you must resolve any compatibility issues with the hardening changes and applications in your environment.

[latest Information from MS – date has Been revised to March 14,2023]

What it actually does:

 Requires Authentication-Level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation.

Key point:

DCOM security will be enforced, so application that chose no security will no longer work.  (this problem can also apply to application that picked inappropriate security settings, or have a hardcoded security setting that does not match or exceed the required level)

 Effect on OPC Classic Clients :

Client permissions are set using a function called CoInitializeSecurity. This function can be called only once per instance; subsequent calls will not be executed and will return an error. If the OPC Classic client calls this function, the settings are based on the parameters included in the call. If the client does not call this function, the OS will call it on the application’s behalf based on the Default DCOM settings. Any client calling this function may require changes to its source code to set the required security object (Authentication Level) to the required value (Packet Integrity) (if this is not available as configuration input to the application). Clients that do not call CoInitializeSecurity apply the default configuration when they call the CoCreateInstanceEx, but the default level will be raised Packet Integrity.  The application cannot override this (i.e.  Applications which explicitly set the authentication level in their CoCreateInstanceEx call however must ensure that they either remove this setting or ensure that it is at least packet integrity as the setting in CoCreateInstanceEx will override.)

Effect on OPC Classic Servers :

Server applications may also call CoInitializeSecurity but most servers typically specify the permissions for establishing communication in the DCOMCNFG utility. Modifying the Custom permissions in DCOMCNFG  therefore determines the security settings to be used. As long as a server Uses the DCOMCNFG utility, any issues are more manageable.   Application setting will still need to be checked.

Other options:

Instead of updating a classic application – update it  to use OPC UA

Think about adding a proxy / wrapper to push an application toward OPC UA (proxy/Wrappers eliminate DCOM from a classic product – they use COM and then use OPC UA for the network communication.)