Documentation
Documentation
Start typing to search…

DCOM Security Considerations

The OPC server connection parameters allow one to define the username, domain and password that will be used to establish the connection to the remote OPC server. OPC client will use the same definition for identifying the client user to the OPC server (by using CoSetProxyBlanket calls).

If the DCOM configuration allows the connection, it is not necessary to define the username for the server connection. However, it is required if/when the OPC server runs as a standalone server (or workstation) or belongs to a different domain than the RTDB computer where the OPC client runs. In this case, a local user name must be created on both the OPC server and the OPC client side, with the same password. Now the User and Password definitions can be defined to the OPC server connection parameters.

Notice that DCOM transports user information in each remote procedure call. If callbacks are used, the OPC server side will call remote procedures back to OPC client. This call also contains an associated username. Usually, the username is the one under which the OPC server runs. The same username (with the same password) must also exist on the OPC client side in order to be possible to perform the callback.

Note that the “administrator” user name can not generally be used in the OPC communication because it may not be possible to set the same password to it on both computers.

The manuals of the specific OPC server implementations may contain special information related to the DCOM security settings. However, in many cases, these instructions have turned out to be unnecessarily heavy. For example, it is usually not necessary to register the OPC server to the registry of the client computer. Instead, RTDB OPC client is able to use DCOM remote connection directly to the remote server computer, using the node and classid definitions of the OPC server connection. Note that when you change the DCOMCNFG settings, you generally need to restart the OPC server so that the change takes effect.

DCOM Limit settings in Windows XP SP2 or later

These instructions are valid only for operation system versions starting from Windows XP SP2 but not for those operating systems that have the “Distributed COM Users” group available (it has been available starting from Windows 2003 server SP1 and from the 64-bit version of Windows XP).

The following information is extracted from document “Using OPC via DCOM with XP SP2.pdf” by OPC foundation. It describes the required DCOMCNFG settings that are needed in XP with SP2 (both in the Client and in the Server side).

  • Start DCOMCNFG
  • Click Component Services, Computers
  • Right click My Computer, Properties
  • Go to COM Security tab
  • “Access Permissions” “Edit Limits”
  • ANONYMOUS LOGON / Remote Access” : Allow. OK
  • “Launch and Activation Permissions”, “Edit Limits”
  • Everyone, Remote Launch: Allow, Remote Activation: Allow. OK

DCOM Limit settings in Windows 2003 SP1 (or x64 XP) or later

These instructions are valid for operation system versions that have the “Distributed COM Users” group available (it has been available starting from Windows 2003 server SP1 and from the 64-bit version of Windows XP).

Add the users that are used in the OPC communication to the “Distributed COM Users” group. Remember to add also the user under which the OPC server is running (in case it is different than the OPC client user). This gives the DCOM Limit settings for the user (so that the DCOMCNFG steps described above are not needed).

DCOM settings in Windows 2008 Server (or Windows Vista) or Later

The following settings are needed in order to make the callback connection working in Windows Vista or Windows 2008 or later.

  • Start DCOMCNFG
  • Click Component Services, Computers
  • Right click My Computer, Properties
  • Go to COM Security tab
  • "Access Permissions", "Edit Default"
  • Add the user name under which the OPC server runs. Allow Local Access and Remote Access. A group name can also be used, except the Administrators group, because in Windows Vista or later the group is not enabled by default.

The above grants the OPC server user access to all COM servers in the OPC client machine. You can also restrict the access so that it can only use callbacks to RTDB_EcOpcClient.exe. In order to do this, you must first disable the ComInitializeSecurity call from OPC client by setting the SimpleConfig parameter DCOMAuthnLevel to -1

RTDB_Cmd dbc -datapath "%app_datapath%" -section "RTDB-EcOpcClient" -key "DCOMAuthnLevel" -strvalue "-1" SetSimpleConfig

However, the above SimpleConfig setting is available only in recent RTDB versions, and it is not possible to make these configurations without it.

After that, you need to register the OPC Client as a DCOM application so that it can be configured with DCOMCNFG. You can do this with the following commands (it is OK use the exactly same GUID as presented):

reg add HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\AppID\{ABB510E8-BF95-4762-ADFE-7793927FEEA0} /d "RTDB_EcOpcClient.exe" reg add HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\AppID\{ABB510E8-BF95-4762-ADFE-7793927FEEA0} /v AuthenticationLevel /t REG_DWORD /d 0x5 reg add HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\AppID\\RTDB_EcOpcClient.exe /v AppID /d "{BDAA1B72-7D1B-4CA9-9F2C-7FCED01086EE}"

After that:

  • Start DCOMCNFG
  • Click Component Services, Computers
  • Under My Computer, DCOM Config, navigate to the application "RTDB_EcOpcClient.exe", Right click, Properties
  • Go to the Security tab
  • "Access Permissions", "Customize", "Edit"
  • Add the user name under which the OPC server runs. Allow Local Access and Remote Access. A group name can also be used, except the Administrators group, because in Windows Vista or later the group is not enabled by default.
  • Restart the RTDB-EcOpcClient service (this is needed so that the DCOMAuthnLevel setting takes effect)

Using two Usernames for Security Reasons**

If the OPC client computer (i.e. the RTDB server) and the OPC server computer are not administrated by the same person, it is desirable that the administrators do not know the password of a powerful user account in each other’s systems. In this case, two different user accounts need to be created.

Let’s consider that the OPC server has been defined to be running under the username “U1”. To make callbacks possible, this account (with the same password) must also be created on the OPC client computer. The account does not need to be powerful on the OPC client side. The account can be created in cooperation with the two administrators so that the OPC client side administrator creates the account and the OPC server side administrator enters the password.

The outgoing connection from the OPC client to the OPC server requires a plain text password for the user name that is used in the connection. A separate user account U2 is created for this purpose on both the OPC client computer and on the OPC server computer. This user account does not need to be powerful on either system. The DCOM settings must be defined on the OPC server side so that this user is able to launch the OPC server or access the existing OPC server. The OPC server side administrator does not need the password of this account. The account can be created in cooperation so that the OPC client side administrator enters the password.

DCOM settings in the OPC server side

Use the instructions of the OPC server provider to define the DCOM settings at the OPC server side. However, if there are no such instructions, use these:

  • Add the OPC user name to the “Distributed COM users” group (or make appropriate DCOMCNFG “Edit Limits” definitions if this group does not exist, see instructions above for XP SP2)
  • Use DCOMCNFG / TheOpcServer to Give Access Permissions for the OPC user. Remote Access: Allow
  • Use DCOMCNFG / TheOpcServer to Give Launch and Activation Permissions for the OPC user. Remote Launch: Allow. Remote Activation: Allow
  • Use DCOMCNFG / TheOpcServer to define the Identity to the OPC server: If you are using a single OPC user name, select “The launching user”. If you are using a dedicated user name run the OPC server, use that user name (and remember to create the user also to the OPC client side, unless the user name of the same domain is used at both sides).
  • Make the above three definitions also for the “OPC Enum” application.
📘

Note: For Windows Vista, 2008 and above: as with the OPC client side, the Administrators group is generally not usable for security definitions. You need to create another group or use plain user names.

Firewall settings

OPC communication between computers uses DCOM protocol, which is implemented with RPC protocol. In RPC protocol the client connects to the server by first connecting to the RPC endpoint mapper, which listens to port 135. This means that port 135 must be open. It must be open also on the client computer to support callbacks. However, if the OPC communication has been configured to use only polling (for example synchronous reads), the OPC client side 135 port is not needed.

OPC server (and also OPC client in case of callbacks) dynamically generates itself a listen port (or multiple ports in some cases). For this reason it is not easy to define firewall settings according to port numbers. It is possible to restrict the used port numbers with registry setting (search “Using Distributed COM with Firewalls” from web), but perhaps it is more convenient to use IP addresses and executable file names in the firewall configuration.

Updated 5 months ago