Adjust DCOM settings to meet DCOM hardening

Creation date: 2/7/2023 3:08 PM    Updated: 3/10/2023 2:01 PM   dcom hardening

To meet DCOM hardening requirements Authentication Level must be set to Packet Integrity for all servers/client participating in DCOM communication. 

This applies where Microsoft DCOM Hardening Patch described in article KB5004442 (CVE-2021-26414)

Exactly what updates KB5004442 applies to depends on Windows version and might be hidden in  Servicing stack updates. In practice all installed updates after June 8, 2021.

On March 14, 2023, where updates after June 8, 2021, are installed. Hardening changes are 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.

What to do, depending on environment

First, identify all OPC Classic (DA, HDA, AE) servers and clients in your system.

On recently updated systems with In DCOM Config, clarify whether active Authentication Level Is set to Packet Integrity, on both server and client side. Try to follow procedure described in Recommended DCOM settings section of thit article.


When adjusting DCOM configuration note that it might affect other applications depending on DCOM, like some SQL connections. 

Possible solutions:

1. No updates - Unhardened server and client computers (no updates after June 8, 2021)

No action needed until updates are installed.

2. Hardened client computer  - Updated OPC Classic Client computer (Client computer updated after June 8, 2021)

See Recommended DCOM settings below

  • If only the Server Computer is updated, the OPC Classic Client will not be able to connect by default, since they are typically using the Connect Authentication Level.
  • If the OPC Classic Client is updated to use the Packet Integrity Authentication Level, then it can connect again.


3. Hardened Server & Client Computer (Client and Server computer updated after June 8, 2021)

  • If you apply the latest Windows updates both to your Server Computer and Client Computer, the connections should run smoothly, since the client update will raise the used Authentication Level to Packet Integrity, even if the applications are not updated.


4. Impossible to harden server Computer, Client Computer is hardened. Use OPC UA as gateway

  • Install OPC DA/UA gateway on unhardened server.  
  • If it is impossible to install OPC DA/UA gateway on unhardened server, an alternative solution is to establish “new” unhardened server in environment and install OPC DA/UA gateway.



Conclusion in brief:

  • On servers where Authentication Level raised to Packet Integrity, clients must raise Authentication Level to least Packet Integrity
  • It seems that clients with Authentication Level raised to Packet Integrity can connect to servers where Authentication Level is less than Packet Integrity. (No recent updates are installed)  
  • If the DCOM server allows anonymous activation, it will still be allowed even with DCOM hardening changes are enabled.

Recommended DCOM settings

In general, attempt to use Default settings for all COM Server application like ApisHive instances, ApisHoneystore and ApisOPCHDA. That makes life easier in many ways. The disadvantage is that server computer restart is mandatory when Default settings are changed to make new settings take place.

Use default settings example

Start dcomcnfg snapin

Set Default settings



  • Navigate to My Computer -> Properties
  • Select Default Properties tab



  • Set Default Authentication Level to Packet Integrity
  • Select COM Security tab
  • Set Limits and Default settings on both Access and Launch Activation Permissions that meets the application requirements See the section OPC DCOM, Classic OPC in practice to help you understand the security mechanism od DCOM, this will vary from installation to installation, therefore it is essential to understand how access security is implemented in DCOM


Set application settings


  • Navigate to the application select Property and General tab
  • Set Authentication Level to Default. (Then the application will inherit the Authentication Level from Default settings of the computer set previously)



  • On Security tab select Use Default for both Launch and activation and Access Permissions



  • Restart server, this is essential when Default properties are changed

Lesson learned during DCOM hardening tests

It seems that clients where Authentication level is raced are allowed connection to servers where Authentication level is NOT raced. (Recent Windows update)

Restart of server when Default properties are changed is essential.


Fault finding

AMS logs

Inspect log in AMS or logfiles directly , you might find messages like this

2023-01-03 13:49:54,238.923| 6716|ERROR|ApisHive.m.OPC|ApisOPC.cpp:774|$RPT$ CreateOPCServer: Failed to create OPC server, Prediktor.ApisOPCServer.1, on 10.100.86.224. Error return: Access is denied.  (0x80070005). CLSID: {8E423571-A67B-11D2-9418-00608CF4C421}. Duration: 4.9951 ms.

This is classical security issue, typically unknown user/password, or user lacking access.

Windows logs

If experiencing classic OPC connection issue the Windows System and Security logs are essential to figure out the source of the issue. Check the system log on server side for messages related to DCOM hardening. To assure DCOM error logging is active, follow these steps:

  1. Start > Run > regedit
  2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
  3. Locate the OLE registry key for the product, right-click.
  4.  Select NEW > DWORD, type ActivationFailureLoggingLevel, press ENTER, double-click the new key, and change its value to 1.
  5. Repeat step 4 for CallFailureLoggingLevel.
  6. Restart the program or service.

System log

Inspecting the event logs might be like searching for the needle in the haystack if you don’t add a filter:

Filter the log Event sources == DistributedCOM



On server where Authentication level is raced to Packet Integrity and client is trying to connect with Authentication level less than Packet Integrity this message will appear in Windows System log on the server side:

The server-side authentication level policy does not allow the user W2019-201\testuser SID (S-1-5-21-3388131059-2642654006-1006207564-1000) from address 10.100.86.212 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.


Solution is to race Authentication to Packet Integrity both application and default on client side and restart computer.

NOTE! restart is required to activate the default setting.

Security log

The security log is helpful to identify access permission issues. Like unknown users or missing user access.

Filter the security log Keyword = Audit Failure

New DCOM error events in conjunction with hardening

To help you identify the applications that might have compatibility issues after we enable DCOM security hardening changes, we added new DCOM error events in the System log; see the tables below. The system will log these events if it detects that a DCOM client application is trying to activate a DCOM server using an authentication level that is less than RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. You can trace to the client device from the server-side event log and use client-side event logs to find the application.

Server events

Event ID

Message

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 events

Event ID

Message

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."

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)


Microsoft DCOM Hardening Patch Timeline

Update Release

Behavior Change

June 8, 2021

Hardening changes disabled by default but with the ability to enable them using a registry key.

June 14, 2022

Hardening changes enabled by default but with the ability to disable them using a registry key.

November 8, 2022

This update will automatically raise the requisite authentication level for all non-anonymous activation requests from DCOM clients to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY if it is below Packet Integrity. With this change, most Windows DCOM client applications will automatically work with DCOM hardening changes on the server side without any modification to the DCOM client applications.

March 14, 2023

Hardening changes enabled by default with no ability to disable them. By this point, you will need to have resolved any compatibility issues with the hardening changes and applications in your environment.



OPC DCOM, Classic OPC in practice


Sources to confusion, obstacles, and pitfalls

  • Firewalls
  • Computer wide and process specific security.
  • User account can achieve rights through group membership and Default and Customized permissions.
  • Local system account is treated as Anonymous logon on remote computer or domain.
  • Group Everyone is limited to all known users on local computer.
  • Callbacks with unknown identity, different than the caller.
  • Microsoft changes their security mechanism in service packs and new versions.
  • No universal recipe, “ALL” cases are different


Main tasks/challenges


  • Collect info
    • Client
      • Running account with password.
      • Path to executable.
    • Server
      • Host name or IP address
      • Running account with password
      • Path to executable.
  • Firewalls
  • Windows “security” UAC
  • DCOM security
    • OPC enumerator
    • Specific OPC server DCOM settings

Windows Firewall

Before starting any configuration, we must check Windows Firewall settings on all of the computers participating in the communication.

Following programs and ports must be open:


  • DCOM (rpc): TCP port 135, bidirectional
  • All OPC servers and clients (program)
  • OPC enum

Do this from the firewall control panel configuration tool, or the most efficient way, from script


Example:


DCOM (rpc):

netsh advfirewall firewall add rule name="OPC DCOM (RPC)" protocol=TCP dir=in localport=135 action=allow profile=any

netsh advfirewall firewall add rule name="OPC DCOM (RPC)" protocol=TCP dir=out localport=135 action=allow profile=any

 OPC Servers and client


In this case ApisHive:

netsh advfirewall firewall add rule name="AllowApis" dir=in program="C:\apis\bin64\apishivex64.exe" action=allow

netsh advfirewall firewall add rule name="AllowApis" dir=out program="C:\apis\bin64\apishivex64.exe" action=allow

OPC enum:

netsh advfirewall firewall add rule name= "Allow OpcEnum" dir=in

program="C:\Windows\SysWOW64\opcenum.exe" action=allow

netsh advfirewall firewall add rule name= "Allow OpcEnum" dir=out

program="C:\Windows\SysWOW64\opcenum.exe" action=allow


User Account Control UAC

If possible, turn off UAC on all computers participating in the communication.

This saves us for painful popups, and it is more likely that programs and configurations installs correctly.

The most efficient way to do this is to run following command on W7/Vista/2008 computer:

reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

NOTE! Reboot is required



DCOM security

This can be a bit confusing and over-complex from time to time and can cause a major trouble during commissioning.

There is no universal recipe, ALL cases are different, so basic knowledge to how the security model works is essential, along with thorough overview of user accounts, computers and client/servers participating in the communication, general assumptions of any of this parameter will lead to failure. Spend some time before starting any configuration to identify all OPC clients and servers with belonging User Accounts.  

When all parameters are known, the (D)COM principals we are dealing with are basically simple:

User Access is the key!

OPC DA clients can principally operate in two main read modes:


  • Polling; client polls for data at certain interval
  • Subscribe; Client initiates subscription on server and server sends data to client when value, timestamp or quality changes.

DCOM Security mechanism

Example


The basic mechanism is comparable to a postal worker, carrying goods from a storage room in one building, to a storage room in another building. Each building has two locked doors: the main entrance door; and an internal door to the storage room. The postal worker must be known and have access to the two doors.

Terms:

Example Term

Computer Term

Postal worker

A user account

The storage room

An OPC server

The buildings

Two computers

The mail

Data


Polling

The postal worker leaves the client building, enters the main door in the server building, then the storage room. He gets the goods he wants and returns home to the client building with his goods.

In this case, the postal worker from the client building must be well known and have access to the two doors in the server building.

Subscription

The postal worker leaves the client building, enters the main door in the server building, then enters the storage room, but now he asks the caretaker:

“When you have any new goods I’m interested in; can you bring it to me at the storage room in the client building?”

“No problem!” the caretaker says, then the postal worker leaves home without any data.

Now, when new goods are produced in the server building and placed in storage, the caretaker collects them immediately and leaves to deliver them to the storage room in the client building. The caretaker from the server building has to enter the two doors in the client building to deliver the goods.

As in the polling case, the postal worker from client building must be well known and have access to the two doors in the server building to deliver his wishes. Then the caretaker from server building must be well known and have access to the two doors in the client building to deliver the goods.


Mutual User Account recognition


To enable both computers to properly recognize User Accounts, it is necessary to ensure that User Accounts are recognized on both the OPC Client and Server computers. This includes all the User Accounts that will require OPC access. The account running the local client, might be different from the account running the remote OPC server.

In other words, we must have knowledge to all User Accounts for the various processes which are participating in the communication.

As mentioned OPC clients can operate in two read modes: Polling and Subscribe


  • Polling; client polls for data on certain interval
  • Subscribe; Server sends data to client when value, timestamp or quality changes.

Issue:

Polling:


  • Client must have read access on server.
  • The user asking for data must be known to the server
  • The user must have “read” access on the OPC server

Subscribing:


  • To be able set up subscription, the user asking for data must be known to the server
  • The user must have “read” access on the OPC server
  • In addition the OPC server must have “write” access on client, thus the user account running the server must be known to the client, as it writes back to the client (callback)


Conclusion:

  • The user running the client must be known to and given access to server.
  • If subscribing (the most common and efficient mode) the user running the server must be known to and given access to client

User(s) participating in communication must exists on both server and client.

Users must have appropriate rights to server and client.

Recommendations:


  • In production environment it is recommended when possible, the server should be installed as service and running on specific account, preferably System account

  • Avoid running server interactively, meaning starting it directly from logged on user. This will lead to confusion on the client side, the server running account changes depending on who is logged on server.

  • Server and Client running account password policy should be set to “never expire”, if not configuration must be updated on password change.

NOTE:


  • “Local system account” is treated as “Anonymous user” on remote computer.
  • “Some unknown user” is NOT treated as anonymous user on remote  computer.

Terms:

Assumptions used in this document (as mentioned all cases are different this is just an example):

Application

User

Password

OPC  server (ApisHive)

OPCServerUser

<some password>

OPC client (ApisHive)

Local System

<some password>


Commissioning:

Find out what User account(s) are running, the OPC server, the OPC client and finally the local configuration tool. This overview is essential and the key for further configuration and cannot be repeated too often.


  1. Find out which user is running the application(s) client and server.
  2. Is the application running as service or not?
  3. Use task manager or services console if server/client is running as service.
  4. If the application is not running as service, keep in mind that the running user might change depending on which user is currently logged on.

OPC enumerator

To be able to browse available OPC servers OpcEnum must be installed on the server computer.

Usually this is performed by the OPC server installer.

However, this should be part of the configuration checklist.

If Opcenum is not running as service, locate it and register it:

  • Opcenum.exe -service 
  • Run under local system account.
  • Give Anonymous and all users running clients access to it in DCOM follow procedure in troubleshooting section and assure all actual users have access.

Installing client, server and creating all necessary users is not part of this description, when that is performed, it is time to set up user security in Component Services console (dcomcnfg)


Check and set DCOM security on OPC server

System-Wide DCOM settings

Classic OPC depend on Microsoft’s DCOM for the data transportation. Consequently, you must configure DCOM settings properly. The system-wide changes affect all Windows applications that use DCOM, including OPC application. In addition, since some OPC Client applications do not have their own DCOM settings, they are affected by changes to the default DCOM configuration.

Task:

Allow OPC client to access OPC server host, check settings on remote computer.

Action:

Use Component Services to set the limits (the main entrance door) and default access configuration see troubleshooting section.

Specific OPC server DCOM settings

When system wide access is granted (access to the entrance main door) it’s time to assure access to the specific OPC server (the storage room).

On remote OPC server computer, start Component Services and browse to My Computer see example in troubleshooting section, assure user running the local client has access.


Troubleshooting

When experiencing disruption in communication, first of all, check the Windows event log for any messages related to your problem, if any messages containing:

Message contains

Symptom

Access is denied.  (0x80070005)

Can indicate DCOM security misconfiguration

The RPC server is unavailable.  (0x800706BA)

Can indicate Windows firewall security misconfiguration

The remote procedure call failed.  (0x800706BE)


OPC enumerator problem

When configuration of security setting of remote computer is incomplete, the OPC server list will be empty when browsing for OPC servers on remote computer and you might get error message(s) in the event log.

DCOM security

Message like this in the event log indicates that the problem likely is DCOM security related more than firewall. Remote server says “Access denied”

Failed to create OPC Server Lister object on 10.100.86.125.

As a result, OPC servers might not be available from the list of servers to choose from. Make sure OPCENUM.EXE is properly registered and configured on the server machine, consider both DCOM security and open the Firewall for OPCENUM.exe.

Or, you can enter the CLSID of your OPC server directly into the server property.

Error return: Access is denied.  (0x80070005)

Let’s assume in this case, the local client is running on “System account” meaning that Anonymous logon must have access right to remote computer and the OpcEnum process on the remote computer. 

Solution:

Check computer wide limits for Anonymous logon on remote computer as well as access rights on the OpcEnum process.

Computer wide limits


On OPC server computer, start Component Services and browse to My Computer right click and Properties, select COM Security tab in Access Permissions section press Edit Limits, assure that Anonymous logon has Remote Access. If ANONYMOUS LOGIN does not exist in the list, it must be added.

Repeat for Launch and activation permissions.


  




OPC enumerator access rights


Still in Component Services browse to OpcEnum right click and Properties, select Security tab, press Edit button in Access permissions section, an assure Anonymous login has Remote access. If ANONYMOUS LOGIN does not exist in the list, it must be added.

  


Repeat for Launch and activation permissions.


If you changed any of the settings, the OpcEnum service must be restarted for the changes to take effect


Firewall


Failed to create OPC Server Lister object on 10.100.86.125.

As a result, OPC servers might not be available from the list of servers to choose from. Make sure OPCENUM.EXE is properly registered and configured on the server machine, consider both DCOM security and open the Firewall for OPCENUM.exe.

Or, you can enter the CLSID of your OPC server directly into the server property.

Error return: The RPC server is unavailable.  (0x800706BA)

This message indicates that the problem likely is firewall or network related. There is no answer from remote server.

Solution:

The firewall must be opened for the OpcEnum process.

Two alternatives to configure; script or firewall control panel.

Script

From elevated command prompt run the following commands:

netsh advfirewall firewall add rule name="Allow OpcEnum" dir=in program="C:\Windows\SysWOW64\opcenum.exe" action=allow

netsh advfirewall firewall add rule name="Allow OpcEnum" dir=out program="C:\Windows\SysWOW64\opcenum.exe" action=allow

Beware of the OpcEnum installation path

Firewall control panel

On OPC server computer start Control panel-> Windows firewall->Advanced settings->New Rule select Program and press Next enter the program path to the OpcEnum executable like “C:\Windows\SysWOW64\OpcEnum.exe” press Next


Select Allow the connection Next

Apply to all networks Next

Give the rule a proper name like “Allow OpcEnum” and Finish

The Window firewall will now allow connections to the OpcEnum process.


OPC DA/HDA access problems

When configuration of security setting of remote computer is incomplete, you are not able to connect to the remote OPC server, thus item browsing is unavailable and you might get error message(s) in the event log.

DCOM security on remote server.

ALARM from OPC

»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»

Failed to create OPC server, Prediktor.ApisOPCServer.1, on 10.100.86.125.

Error return: Access is denied.  (0x80070005).

This message indicates that the problem is DCOM security related. Remote server says “Access denied”

Let’s assume in this case, the local client is running on “System account” meaning that Anonymous logon must have access right to remote computer and the Prediktor.ApisOPCServer.1 process on remote the computer 

Solution:

Check computer wide limits for Anonymous logon on remote computer as well as access rights on Prediktor.ApisOPCServer.1

Computer wide limits

See how to set Computer wide limits in previous section

OPC server access rights

Still in Component Services, in this case browse to ApisHive (OPC server) right click and Properties, select Security tab.

 

In this case the OPC server (ApisHive) is using default properties, we have two chooses:


  • Change it to Customized permissions, follow the same procedure as in OPCenum access rights section
  • Keep the default. The advantage of use default is if we are using several OPC server instances on same computer the access rights can be set in one place if desirable.

In this example we choose to keep default, now close the ApisHive Properties dialog, browse to My Computer right click and Properties, select COM Security tab in Access Permissions section and now press Edit default, assure that Anonymous logon has Remote Access.

 

Repeat for Launch and activation permissions, assure Anonymous user has Remote Launch and activation permissions.

If you changed any of the settings, the OPC server (ApisHive) service must be restarted for the changes to take effect.

Windows Firewall

ALARM from OPC
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
Failed to create OPC server, Prediktor.ApisOPCServer.1, on 10.100.86.125.
Error return: The RPC server is unavailable.  (0x800706BA).

Like in the OPC enum case, this message indicates that the problem likely is firewall related. There is no answer from remote server.

Solution:

The firewall must be opened for ApisHive process. Follow the procedure in Firewall configuration of OPC enum but in this case open for ApisHive ("<install dir>\Bin64\ApisHivex64.exe")

OPC server callback Firewall

ALARM from OPC/opcda://10.100.86.125/Prediktor.ApisOPCServer.1 [Primary]
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
Failed calling IOPCDataCallback::Advise - IOPCDataCallback! Error return: The RPC server is unavailable.  (0x800706BA).


This message indicates that the problem likely is firewall related. There is no answer from remote server, the server tries to write back to client but hits the firewall.

Solution:

The firewall on the local client computer must be opened for ApisHive process. Follow the procedure in Firewall configuration of OPC enum but in this case open for ApisHive ("<install dir>\Bin64\ApisHivex64.exe").

OPC server callback access rights

ALARM from OPC/opcda://10.100.86.125/Prediktor.ApisOPCServer.1 [Primary]
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
Failed calling IOPCDataCallback::Advise - IOPCDataCallback! Error return: Access is denied.  (0x80070005).

This message indicates that the problem is DCOM security callback related. Remote server tries to write back to client but gets “Access denied”

In this case server is running on “OPCServerUser” account meaning that when trying to write back to the client it must have access right to local computer and the process running the client as well (Prediktor.ApisOPCServer.1). 

On local computer:

Assure OPCServerUser exist with same password as the corresponding user on remote server.


Assure OPCServerUser has computer wide limits remote access rights

 

Assure OPCServerUser has remote access rights to client process, in this case ApisHive, trough default access permissions.



If you changed any of the computer wide settings, the OPC server (ApisHive) service must be restarted for the changes to take effect.



How to set DCOM security Computer wide limits for a specific user

Start Component Services system configuration and browse to My Computer, right click, select Properties and select COM Security tab in Access Permissions section: Press Edit Limits button and assure that that the specific user has Local and Remote Access.

 



Repeat for Launch and activation permissions.