OPC and DCOM Security
Configuring OPC to work between multiple computers - connecting clients to remote servers - is the most taxing problem faced by many OPC users.
More Information on configuring DCOM
DCOMCNFG
During development, many OPC programmers work around this problem by using the same account details to log in to both client and server computers. While this may be acceptable for development and demonstration, it is usually not practical in a production environment. Sooner or later, any OPC expert will need to acquire some understanding of Windows security, and in particular the Distributed COM Configuration tool (DCOMCNFG) which defines the security model for COM applications used remotely.
Which User?
When a COM server is run remotely, the default behavior is for the server to run as the 'interactive user', i.e. the user who is currently logged in. This explains why using the same login on each PC can be such an effective technique. However, it has some obvious drawbacks, not least the need to have a particular user logged in on the server computer.
In practice, the best approach is usually to create an account on the server computer specifically for the purpose of running the OPC server - the username for the account might be 'opc'. DCOMCNFG is then used to configure the COM server to run under the identity of this new user, rather than as the 'interactive user' or the 'launching user'.
Other Issues
The OPC server is not the only COM server which comes into play when using OPC. Consideration must also be given to security settings for the OPC server enumerator component (OPCENUM.EXE). This additional COM server is used by the majority of OPC clients to identify available OPC servers.
Furthermore, because of callback mechanisms, OPC clients act as servers for particular COM interfaces, with the OPC server as the consumer of these interfaces. In this case, the DCOM security position is reversed, and security on the client computer must be considered to ensure that callbacks are able to get through.
More Information on configuring DCOM
Because DCOM security is such a common problem for implementers of OPC systems, there are many sites with available information. These are some of the better ones:
OPC Support provides information on common OPC Connectivity problems including DCOM settings, DEP configuration and many more. To properly to configure COM/DCOM to connect an OPC client to an OPC Server, specific DCOM troubleshooting guides can be found here:
FAQs and Common DCOM problems - MatrikonOPC
DCOM Help from ascolab GmbH - a guide to DCOM security for industrial environments, in the form of a downloadable HTML Help file.
Configuring DCOM by Software Toolbox.
DCOM Videos - Software Toolbox. A series of screencasts showing DCOM configuration options for different Windows versions.
OPC DCOM Settings - IT-CO recommended DCOM settings for OPC (PDF) - CERN. Parts of this document are specific to CERN, but its level of detail make it useful nonetheless.
OPC Foundation White Papers. This list includes a number of papers relating to DCOM, including one specific to DCOM security.
You may also like to run this Google query for other references: opc dcomcnfg OR "dcom security".
Windows XP Service Pack 2
DCOMCNFG Failures - Registry Corruption Issues
A number of users have reported an apparently serious bug in Windows XP SP2 affecting use of DCOMCNFG. The problem was first reported by Matrikon, and has since been confirmed by OPC Foundation.
See this topic on the OPC Foundation Message Board for more information.
New Guidelines
It now appears the problem lies with applications which attempt to programatically control their DCOM security settings by direct Registry manipulation. Windows XP SP2 mandates a different way of achieving the same results. See this post, from OPC Foundation Technical Director Jim Luth, for more information. The new technique is used, conditionally, by recent updates to OPC Foundation's server enumerator and DA sample code.
Changes to DCOM Security
The headline feature of Windows XP SP2 is enhanced security and protection, including significant changes to the behavior of DCOM Security. The following links give more information:
- Using OPC via DCOM with Microsoft Windows XP Service Pack 2 - OPC Foundation white paper covering changes to DCOM configuration and the Windows Firewall
- Changes to Functionality in Microsoft Windows XP Service Pack 2 - Microsoft TechNet article
Windows XP SP2 is available from August 2004.
Alternatives to DCOM
It is not necessary to use DCOM when setting up OPC connections between computers. The following alternatives may be worthy of consideration.
OPC XML-DA
The OPC XML-DA specification defines an alternative mechanism for remote OPC communications. XML-DA is based on SOAP, and generally uses HTTP as its transport. As a result XML-DA is likely to work through firewalls, and also offers the possibility of cross-platform OPC.
Various products exist which allow OPC (COM) clients and servers to communicate remotely via an XML-DA bridge/gateway. See our XML-DA page for more information.
OPC Tunnelling
Products such as Matrikon OPC Tunneller offer another route to bypassing DCOM. In this case, Tunneller is installed on both client and server PCs, interfacing with the true OPC client and server via local COM. The two copies of Tunneller then communicate with one another using one of a number of supported protocols, including TCP/IP.
OPC Security
External and internal threats are concerns in critical control systems. OPC Security provides security in a standard manner. OPC Foundation developed OPC Security Specs. Learn here
