UPDATE 21.07.2022: Prosys Sentrol OPC UA & Classic SDK has now been fixed.

UPDATE 21.06.2022: Prosys OPC Classic Client has now been fixed.

Microsoft has found a vulnerability (KB5004442, CVE-2021-26414) in DCOM and have decided to enforce hardening changes that will be applied over the next Windows updates.

The change affects OPC classic applications that use remote connections and the OPC Foundation has also released a notification about the issue.

The timeline for the updates is as follows:

The changes will affect usage of OPC classic client applications that connect to OPC classic servers running in another computer (using Distributed COM). Connections within the same computer are not affected (they are using COM).

The hardening will become effective, when Windows is updated in the server computer. As a result, client applications running in other computers will need to be updated.

Prosys OPC products affected

The hardening changes affect directly

• OPC UA Gateway version 1.5.8 and earlier
• Prosys OPC Classic Client version 2.0 and earlier
• OPC Classic client applications built with Prosys Sentrol version 7.4.0 or earlier

Fixed products

• OPC UA Gateway version 1.5.9
• Prosys OPC Classic Client version 2.1.0
• Prosys Sentrol version 7.5.0

Overcoming the problems in your own Sentrol applications

Prosys Sentrol 7.5.0 and later will initialize COM with the required alPacketIntegrity security level by default, so you only need to recompile your applications with the new Sentrol libraries.

If you are still using Prosys Sentrol 7.4.0 or earlier, you must add the following to the Project Source code of your OPC Classic client applications:

program Xxx;

uses
  PsComUtils,
  ...

begin
  PsInitComSecurity(alPacketIntegrity, ilIdentify);
  ...

ComSecurity is initialized by default with alConnect level in these versions. That used to be enough to make remote connections, but after the Windows hardening, the servers will not accept connections with that level any more.

Note that as long as your applications connect over OPC Classic only within the same computer, the connections should work despite this setting.

Move to OPC UA

An alternative way to overcome the issue is to avoid remote DCOM connections between the OPC applications. Instead, you should consider moving the connections to use OPC UA, by applying OPC UA Gateway as a tunneler, for example.

Or, you should consider supporting OPC UA in your own applications, which is also possible with Prosys Sentrol.

Enabling and disabling the hardening

The changes can be enabled and disabled (until March 14, 2023) using the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\
RequireIntegrityActivationAuthenticationLevel (DWORD value)

The value of 1 means that the hardening is enabled and 0 means that it’s disabled.

Note that you have to restart the computer for the changes in the registry key to take effect.

The feature has already been made available in June 8, 2021, so if you have the latest updates in your Windows operating systems, you can try it out.

Testing

You should be able to see the effect, for example, by connecting remotely with Prosys OPC Client version 2.0 to Prosys OPC Simulation Server. (NOTE that the latest version 2.1 is already initializing COM properly, so it will be able to connect to a hardened server as well.) If the hardening is disabled in the server and you have configured DCOM and firewall to enable connections, you should be able to see the list of servers and connect to the Simulation Server.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\
RequireIntegrityActivationAuthenticationLevel=0 (DWORD value)

(Reboot after change)

Make sure you have opened access to the OpcEnum service in the DCOM Configuration of the server computer. It must also run at least with ‘Connect’ Authentication Level.

When the hardening is enabled in the server, you should get an ‘Access denied’ error in the client application.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\
RequireIntegrityActivationAuthenticationLevel=1 (DWORD value)

(Reboot after change)

Alternatively, you can try to just connect to the server. If it is also installed in the client computer, you can use the ProgID, e.g. ‘Prosys.OPC.Simulation’; otherwise you will need to use the CLSID, e.g. ‘{EB3A5F8E-7938-464C-AEFA-898335B1E6B5}’ in the Server field.

This should also fail with ‘Access denied’, if the hardening is enabled.

You can also enable logging of DCOM errors in the server computer to validate this. To do this, add the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\
CallFailureLoggingLevel=1 (DWORD Value)

After this, you should see the following error in the Event Viewer - Windows Logs-System (You can start it by typing ‘Event Viewer’ in the Start Menu):

(Click to open larger)

And finally, when you have an application that initializes COM Security properly, you should be able to connect again.