OPC and DCOM: 5 Things You Need To Know (Part 2)

See Part 1

3.1 Default Properties

In the Default Properties tab, ensure that three specific options are set as follows (refer to Image 6):
a. Check the “Enable Distributed COM on this computer” menu option. Note that you will have to reboot the computer if you make changes to this checkbox.
b. Set the “Default Authentication Level” to Connect. It is possible to use other settings in the list, but the “Connect” option is the minimum level of security that you should consider.
c. Set the “Default Impersonation Level” to Identify.Default Protocols

In the Default Protocols tab (refer to Image 7), set the DCOM protocols to “Connection- Oriented TCP/IP”. OPC communication only requires “Connection-Oriented TCP/IP”, so it is possible to delete the rest of DCOM protocols. However, if these protocols are indeed required for non-OPC applications, you can leave them there. The only consequence is that timeouts may take a little longer to reach.

3.2 COM Security

Windows uses the COM Security tab (refer to Image 8) to set the system-wide Access Control List (ACL) for all objects. The ACLs are included for Launch/Activation (ability to start an application), and Access (ability to exchange data with an application). Note that on some systems, the “Edit Limits” buttons are not available.

To add the right permissions, follow the steps below:
a. In the Access Permissions group, click the “Edit Default…” button (refer to Image 9). Add “Everyone” to the list of “Group or user names”. Click the OK button.
b. In the Access Permissions group, click the “Edit Limits…” button (refer to Image 9). Add “Anonymous Logon” (required for OPCEnum) and “Everyone” to the list of “Group or user names”. Click the OK button.
c. In the Launch and Activation Permissions group, click the “Edit Default…” button (refer to Image 9). Add “Everyone” to the list of “Group or user names”. Click the OK button.
d. In the Launch and Activation Permissions group, click the “Edit Limits…” button (refer to Image 9). Add “Everyone” to the list of “Group or user names”. Click the OK button.

4. Configure Server Specific DCOM settings

Once the system-wide DCOM settings are properly configured, turn attention to the serverspecific DCOM settings. These settings will eventually be different for every OPC Server. To change these settings, begin by:
a. Click on the Windows Start button, and select the Run menu option (refer to Image 4).
b. In the Run dialog box, type "DCOMCNFG" to initiate the DCOM configuration process, and click the OK button. The Component Services window will appear (refer to Image 10).

c. Once in the Component Services window (which is initiated by DCOMCNFG as above), navigate inside the Console Root folder to the Component Services folder, then to the Computers folder, expand My Computer, finally click on the DCOM Config folder.
d. In the list of objects in the right window pane, find the OPC Server to configure and right-click on it. Select the Properties option.

In the OPC-Server specific settings, only the Identity tab needs to change from the default settings. The rest of the tabs (refer to Image 11) can refer to the default configuration that was set in section 3 (Configure System-Wide DCOM settings).

You must pay special attention to the Identity tab. The Identity tab will look like one of the two screen captions in Image 12 below. The 4 (four) Identity options are:

The interactive user: The OPC Server will assume the identity of the Interactive User. This is the person who is currently logged on and using the computer on which the OPC Server resides. Note that someone must be logged on. If no one is logged on to the computer, the OPC Server will fail to launch. In addition, if someone is currently logged on, the OPC Server will shutdown as soon as the person logs off. Last, in the case of a reboot, the OPC Server will not launch until someone logs on. Consequently, this is typically a poor setting for OPC Servers. OPCTI does not recommend that you use this setting unless the OPC Server vendor specifies this setting explicitly.
The launching user: The OPC Server will take the identity of the User Account that launched it. With this setting, the Operating System will attempt to initiate a new instance for every Launching User. There are three general problems with this setting. The first problem is that some OPC Servers will only allow a single instance to execute. Consequently, the second Launching User will be unable to make the connection because an instance of the OPC Server is already running on the computer. The second problem occurs when the OPC Server vendor allows more than one instance of the OPC Server to execute concurrently. In this case, the computer on which the OPC Server resides will have multiple copies of the OPC Server executing concurrently, which will consume a significant portion of the computer resources and might have an adverse affect on the computer’s performance. In addition, some system resources might be unavailable to any instances of the OPC Server that follow the first. For example, the first Launching User will be able to connect to a serial port, while every other Launching User will simply receive Bad Quality data. OPCTI does not recommend that you use this setting unless the OPC Server vendor specifies this setting explicitly. Last, the Launching User must have Administrative rights on the OPC Server computer. They can not be configured as a “Limited” user.
This user: The OPC Server will take the identity of a specific User Account. This setting might be required when the OPC Server is tightly coupled with the underlying data source. In this case, the OPC Server must assume a specific Identity to exchange data with the data source. However, since the OPC Server uses a specific User Account, it is possible that the computer running the OPC Client does not recognize the OPC Server’s User Account. In this case, all callbacks will fail and all OPC data Subscriptions (asynchronous data updates) will fail. If this is indeed the case, you will have to add the OPC Server account on the computer running the OPC Client application. Various DCS vendors require this setting for their OPC Server. OPCTI does not recommend that you use this setting unless the OPC Server vendor specifies this setting explicitly.
The system account (services only): The OPC Server will take the identity of the Operating System (or System for short). This is typically the desired setting for the OPC Server as the System Account is recognized by all computers on the Workgroup or Domain. In addition, no one needs to be logged on the computer, so the OPC Server can execute in an unattended environment. OPCTI recommends configuring the Identity of the OPC Server with this setting, unless the OPC Server vendor specifies a different setting explicitly. Note that Windows disables this option if the OPC Server is not setup to execute as a Windows Service. If this is the case, simply configure the OPC Server to execute as a service before configuring this setting.

5. Restore Windows Security

Once you establish the OPC Client/Server communication, it is important to secure the computers again. This includes (but is not limited to):

a. Turn on the Windows Firewall again. This will block all unauthorized network traffic. You will also need to provide exceptions on two main levels:

Application level: specify which applications are able to respond to unsolicited requests.
Port-and-protocol level: specify that the firewall should allow or deny traffic on a specific port for either TCP or UDP traffic.

b. Modify the Access Control Lists (ACLs) to allow and deny the required User Accounts. This can be accomplished either through the system-wide settings of DCOMCNFG, or in the server-specific settings. Remember that OPCEnum requires the “Anonymous Logon” access. You may wish to remove this access. The consequence of this action will simply be that OPC Users will be unable to browse for OPC Servers on the specific computer where Anonymous Logon access is not available. However, users will indeed be able to properly connect to and exchange data with the OPC Server.

We encourage you to complete your DCOM setup with this step. Integrators frequently establish OPC communication and don’t spend the necessary time to secure the computers again. This can lead to catastrophic results if network security is compromised due to a virus, worm, malicious intent, or simply unauthorized “experimentation” by well-meaning coworkers. Specific settings are discussed in a separate whitepaper.

6. Conclusion

OPC is powerful industrial communication standard. However, OPC relies on having DCOM work properly. Luckily, DCOM problems can usually be overcome with relatively simple configuration changes as documented in this whitepaper. To get a deeper understanding of OPC, DCOM, and the diagnosis of all common problems OPCTI highly recommends that you take time to get formal OPC training. This will enable you to structure your OPC knowledge to help you reduce your short and long-term project costs. OPCTI also encourages you to provide us with feedback. Let us know about new problems and solutions that you found. We will pass these on to the rest of the OPC community, to help everyone get connected.

Part 1 : Part 2

Randy Kondor, President, OPC Training Institute, has more than 15 years of leadership experience building global OPC and security awareness and acceptance. An accomplished engineer, his vision and capable expertise have been a driving force in making the OPC Training Institute the world's largest OPC training company. Randy's success is due to the priority he has placed on educating industry about OPC standards. Education continues to be his focus today. His significant impact in the industry continues to be felt as ....... See Details....