Microsoft DCOM Hardening (CVE-2021-26414, KB5004442) Technical Resources (2024)

To address the vulnerabilities inCVE-2021-26414, Microsoft released updates listed in their advisoryKB5004442that are commonly known as DCOM Hardening updates. The updates were included inWindows Updates rolled out to affected operating systems since June 8, 2021, but it was optional to enable the change using a registry entry described in the advisory KB after they were installed by Windows updates.

Starting with Windows Updates on June 14, 2022, the hardened settings will be enabled by default with the option to disable them with a registry entry, which will require a system restart. There arerisks to operational uptime increase for OT systems that have not been prepared properly. Starting In March 2023, the DCOM hardening settings will be mandatory on supported operating systems, and you will not be able to turn them off.

Who is affected?

Applies to: Users of OPC Classic standards: DA, HDA, A&E, that are connecting their OPC Clients and Servers over a network between the client and server, using Windows Server 2008 or newer, Windows 10 or 11 on either side of the DCOM connection will be affected and MUST be aware of these Microsoft changes. Full OS list is inKB5004442. Using an older, unaffected Windows Operating System may prevent outages, but we do not endorse, recommend, condone, or otherwise support using unsupported software of any type.

Does NOT apply to:

• Users of OPC Classic who are making local connections, meaning the client and server are on the same computer.
• Users of OPC Classic who have already implemented a tunneling solution to communicateacross a network.
• Users already using OPC UA for your OPC client to server connections are NOT affected by KB50004442.

Support from our team for this FAQ and related FAQs

• Is prioritized for Software Toolbox customers on active Support & Maintenance Agreements
  • Reinstatement of support is available. Contact us to check your support status or if you need to reinstate. Be sure and provide products, license #s and any identifying information you can. Our team will review, get back to you promptly and, if necessary, get you a quote on reinstating support.
  • We reserve the right to charge hourly support fees for Software Toolbox customers not on support and you will be prioritized behind users on active agreements. Reinstating support will move your needsto the priority queue in the next available position after others already in queue for assistance.
• If you are not using Software Toolbox products, you are welcome to use this information to assist you and we suggest you consider our DCOM replacement options, but we cannot support other party's products or custom applications.
  • We are happy to assist you with the evaluation of our solutions for OPC UA/DA conversion or OPC Tunnelingto replace DCOM in your applications.
• This FAQ is provided subject to our terms and conditions.

What is DCOM?

DCOM, also known as Distributed COM, is a Microsoft technology built into computers running the Windows Operating system. It is not something you add or install separately -it's automatically there and is used by many Windows applications including OPC Classic DA, HDA & A&E Clients and Server softwarewhen communicating to each other over network connections.

DCOM is NOT used in communications to PLCs or other control devices. We sometimes hear users say their "PLC supports OPC DA". PLCs are not running a Windows OS, so they cannot be running OPC DA or DCOM. Typically when we hear that, the user means they have an OPC Classic DA server software application running on a computer or virtual, that is communicating to the PLC or control device using that device's specific serial or Ethernet protocol.

What Changes Is Microsoft Making & Why?

This information is not a substitute for reading the fullMicrosoft's KB5004442advisory.

Microsoft is making this change to increase the security of DCOM and thus patch the vulnerabilities described inCVE-2021-26414. The patches installed by Windows Update as described in their KB50004442 advisory changethe minimum required security settings for remote procedure calls (RPC) which will impact any application that uses RPC for inter-machine communications. DCOM is a RPC techonology. Specifically, the required DCOM "Authentication Level" is being changed and the operating system will enforce the higher security level, overriding what you have set in Component Services->DCOM Config for the system or a specific OPC server. This can be confusing because you will experience the system operating differently than what you see in your DCOM config settings.

• DCOM Serversand,thus,OPC Classic (DA, HDA, A&E) Servers will reject connections withan authentication level of “None”, “Connect”, “Call” or “Packet”
• DCOM Clientsand,thus,OPC Classic (DA, HDA, A&E) Clientsmust be configured to use an authentication level of “Default”, “Packet Integrity” or “Packet Privacy”. If configured for Default, the system Default Authentication Level in Component Services->My Computer->Properties, must be set to Packet Integrity or Packet Privacy and match what the target OPC Server computer is using.

There are 2 ways that OPC Classic Clients and Servers will get the DCOM Authentication Level that they will use, and they always get it AT LAUNCH. That means if you CHANGE something in DCOM settings, you MUST restart the client or server respectively so that it can get its security settings again

1. The application will respect settings found in Component Services in the operating system. It will either respect the system Defaults, or there will be an entry for the application under DCOM Config in Component Services that either says Default, or has been configured to override system defaults for that application. Either way, it will be the easiest to mitigate the effects described in KB50004442 for these applications.
   
2. The application makes a call called Co-Initialize Security with internally hard coded settings, or at best, with settings configured in the application. This call overrides anything set in Component Services and no changes to Component Services will affect the behavior. These cases will be the hardest because they will require an update from the application developer. If that is not possible, available, or practical, then conversion of the interface to OPC UA using a OPC DA/UA Gateway or use of OPC tunneling, will be the fastest most robust solution, although it will mean the purchase of additional software.

Why this Matters and the Impact the Changes Can Cause

You could have systems that use Distirbuted COM (DCOM) stop communicating unexpectedly if you have not planned for this. OPC Classic (DA, HDA, A&E) clients and servers could stop communicating, resulting in operational downtime if you are not ready for Microsoft's timeline.You can apply the registry entry described in advisory KB5004442for a short term fix, but must then make your longer term plan.

Although disruptive, from a cybersecurity perspective, this is a good change as it ensures increased security at a time where industrial control systems are becoming increasingly attractive targets for cyberattacks. Usersmay not be aware that the RPC calls an application is making using DCOM are not secure enough without the application and enabling using the registry change in advisoryKB5004442.

At the heart of the issue is that an application, specifically OPC Classic Servers or Clients,that may havehistorically overwritten the default DCOM security parameters for the operating system as described previously, could now potentially be impacted if those settings do not meet the minimum requirements set by Microsoft. Over the years we've seen users in their efforts to make DCOM work, make DCOM settings using the Windows Component Services application, under DCOM Config, or the older DCOMCnfg utility,that are insecure. We've seen some vendor and customwritten user applications that hard coded the DCOM security settings instead of allowing the settings found in Component Services or DCOMCnfg to rule.

What changes should I make to be ready or mitigate these issues?

We expect that most of the issues with this update will be on the side of OPC Client applications. After June 14, 2022 and before March 2023, the fastest mitigation will be to disable the DCOM hardening, recognizing this does leave open the security risk described inCVE-2021-26414. Software Toolbox is not advocating you do something that creates an unacceptable security risk for your environment and business, butMicrosoft'sKB5004442advisory provides a technical solution with a registry entry to disable DCOM hardening which you will have to do on both the client and server machines.

Assuming your OPC Client & Server applications respect Component Services Default DCOM settings, then on BOTH your Server and Client machines make the following changes which will set the DEFAULT DCOM authentication level to what is required by advisory KB5004442.You may alsorequest our free detailed Remote OPC DA Classic (DCOM) Configuration Guide herewith recommendations for DCOM setting configuration on OPC DA client and server machines where connections will be remote (client and server on separate machines).

1. Launch Component Services
2. Go to Component Services -> Computers -> My Computer and right click on My Computer and select Properties.
3. On the Default Properties tab, change the Default Authentication Level to“Packet Integrity” or “Packet Privacy” Whatever you choose must be the SAME on the client AND server computer. Generally users are setting this to Packet Integrity and that is our standard recommendation at this time.

If your OPC Client or Server have their own entries under the DCOM Config part of the Component Services tree, you will need to make the same change on the General Tab, Authentication Level.

These changes at a MINIMUM will require you to restart your client and server applications, though we recommend a machine restart to ensure that the changes take effect.

Some applications, typically custom applications, make a call within their code called Co-Initalize Security, that overrideany of the settings in Component Services. Sometimes those applications will have a setting to follow DCOM Config settings instead of their internal settings. If the application does not have any settings to allow the application to follow the Component Services settings, then you must contact the vendor and ask them if their OPC Client follows the Component Services settings. If they do not, and are using hard coded settings, then ask themfor an update to their application, or switch to using OPC UA if availble, add an OPC UA/DA Gateway, or add an OPC Tunneler such as DataHub Tunneling.

See the Software Toolbox product specific FAQs for further information for our products. We have carefully detailed how each product could be affected and what steps to take.

A word on OPCEnum

OPCEnum is a process that is typically found on OPC Server machines. It's sole purpose is to provide an interface for OPC Classic client applications to browse for available OPC Classic Servers on the machine and convert the friendly names (ProgIDs)you see to the underlying CLSID which is a big ugly number/string that is used in the communications.The connection between the client and server uses DCOM to access OPCEnum.

For this reason, you must also address the Component Services DCOM Config Settings for OPC Enum.

What if my OPC Classic clients and servers stop communicating on or after the June 14th,2022, Windows Updates are Applied? How can I know DCOM hardening is the reason?

Your first action if you have an outage will be to apply the registry entry found in advisoryKB5004442and restart your systems toget service going again.

IMPORTANT: When you make the registry change listed in the KB5004442 advisory, it will NOT change the settings in your Component Services system Default Authentication Level or OPC Server specific authentication levels. It will only change what the operating system enforces.

• For example, if you had Default Authentication Level set to Packet Integrity, but disabled enforcement with a registry entry value of 0, you will find that your system is still enforcing the Default Authentication Level of Packet Integrity. You would have to change that setting back to one of the less secure options if you were trying to bypass the June 14, 2022 automatic enforcement.
• The same would apply to any OPC server specific settings you made and to settings for OPCEnum.
• Similarly, if you set the registry entry value to a "1" but your Default Authentication Level showed "Connect" you will find that Windows will be enforcing the requirement ofPacket Integrity, even though you might think otherwise.
• If you have applied Windows Updates on or after June 14, 2022, and are having DCOM issues, you MUST assume thatPacket Integrity level authentication is being enforced by the operating system.
• Always keep in mind that it has been optional to enforce thePacket Integrity requirement since June 2021, and your IT department could have pushed out a group policy change that forced the registry entry to be set to 1 earlier than June 14, 2022. In that case you will not be able to override that change and will need to work with your IT department.

Based on informationfound in advisoryKB5004442, we would also expect to see the following new Events in the Windows Event Log for certain NEWER versions of Windows listed in the KB advisory. If your OS does not support these added Event Log messages, but you know that Windows Updates on an affected OS were applied on or after June 14, 2022, you most likely are affected by the changes described in advisory KB5004442 .

Server Side - Event 10036

"The server-side authentication level policy does not allow the user %1\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application."
(%1 – domain, %2 – user name, %3 – User SID, %4 – Client IP Address)

Client Side - Event 10037

"Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with explicitly set authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor."

Client Side - Event 10038

"Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with default activation authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor."
(%1 – Application Path, %2 – Application PID, %3 – CLSID of the COM class the application is requesting to activate, %4 – Computer Name, %5 – Value of Authentication Level)

Alternative Solutions to Using DCOM

If you cannot change your applications to directly use OPC UA, you can enable further future-proofing that eliminates the need for DCOM, using several solutions. Free trials and getting started videos are available for all solutions.

• DataHub OPC Gateway - convert OPC DA servers into OPC UA servers orOPC DA clients into OPC UA clients
• DataHub Secure Tunneling - replace DCOM in OPC DA client to DA server connections with secure, encrypted, DMZ, Proxy-friendly tunneling that automatically recovers from network interruptions
• TOP Server OPC Client Suite - great for situations where you are using dynamic tags with TOP Server or OmniServer, such as with AVEVA solutions such as InTouch, System Platform, or Historian.
• MQTT - if you are considering migrating to MQTT, although that is more of an architectural change, the DataHub Smart MQTT SparkplugB Client and MQTT SparkplugB Broker solutions provide secure and automatic conversion from OPC to MQTT.

Software Toolbox Product Specific FAQs

• Free detailed Remote OPC DA Classic (DCOM) Configuration Guide
• TOP Server
• OPC Quick Client (Included with TOP Server)
• OmniServer
• Software Toolbox OPC Test Client (Included with OmniServer and available standalone)
• OPC Data Client
• Cogent DataHub
• OPC Router
• OPC Data Logger
• SLIK-DA

Disclaimer: You are ultimately responsible to work with your IT/OT teams on handling the changes to your systems. Software Toolbox support cannot and will not make changes to customer systems for them. This information is provided for reference and is based on our best commercially reasonable efforts to gather, validate and aggregate this knowledge and is provided under and subject to our standard terms and conditions.