OPC DCOM setup

Introduction

This document provides additional help when configuring DCOM security settings in windows

Acronyms and Abbreviations

OPC : Ole for Process Control

DCOM : Distributed Component Object Model

OPCENUM : A computer service (program) provided by the OPC foundation. It is used to find and list the installed OPC servers on a computer.

Prerequisites for OPC communication

OPC communication always involves at least one OPC client and one OPC server. In order for OPC communication to work, both computers must be connected via a TCP/IP based network. Also, the computers must be active, that is, turned on, and not hibernating. The OPC server software must be installed on the server, and the proper DCOM settings must be set. Setting the proper DCOM settings involves:

1. To allow a client to browse the server computer for installed OPC servers, the ”Opcenum” service should be installed and properly configured. The presence and use of OPCENUM is not required in order to run OPC communication, but configuration work is easier when OPCENUM is available.

2. User and access rights must be configured in order to establish an OPC client – server communication.

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

OPC setup, step-by-step

This is a step by step configuration of security settings for OPC communication between a server and a client.

Requirements:

• Firewall open for OPC traffic
• Opc server is installed
• OpcEnum.exe is installed

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:\Program Files\APIS\Bin\apishive.exe" action=allow

netsh advfirewall firewall add rule name="AllowApis" dir=out program="C:\Program Files\APIS\Bin\apishive.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:

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)

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.

“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):

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.

Computer settings

1. Select ”Local Security Policy” under ”Administrative tools”

2. Select ”Network access: Sharing and security model for local accounts” under Security Options

3. Right click and select Properties and choose ”Classic – local users authenticate as themselves”.

Start dcomcnfg by clicking Start – Run, type in: dcomcnfg, and hit enter

a. Component Services window opens

5. Right click on Component Services - Computers – My Computer and select properties

6. Select Default Properties tab

7. Check Enable Distributed COM on this computer

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 Computer wide limits section in the troubleshooting guide, assure user running the local client has access.

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 OPC server access rights example in the troubleshooting guide, assure user running the local client has access.

Check and set DCOM security on OPC client

OPC server callback access rights

As mentioned earlier 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).

Figure out what user account is running the remote server, take a look at the OPC server callback access rights section in the troubleshooting guide and assure the user running the server has access to your local computer as well as the local OPC client process.

OpcEnum DCOM Settings

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 at OPC enumerator access rights in troubleshooting section and assure all actual users have access.

Troubleshooting

In case of OPC communication problems:

1. At first, check the list of common pitfalls;

2. Ping the client from the server and vice-versa to verify that network communication exists;

3. Check the documentation of both server and client, to see whether error messages can be logged for view in log viewer. If so, enable the logs and check them in log viewer in Apis Management Studio;

a. Use ”Control panel-> Local security policy -> Audit policy” to enable security auditing. Success or failure of user authentication then can be logged to the Security log, and this may reveal the cause of communication failure (Remember to restart the server to activate the new settings);

4. If communication is established, but tags are ”bad:not connected”, and read mode is “Subscribe”, change the read mode to ”Poll”. If this solves the problem, the server has insufficient access rights (lacks the ”write” right) to the client;

5. If communication is established, but tags are ”bad:configuration error”, the source item id (OPC address) in the server is usually incorrectly configured on the client.

6. Further readings see Troubleshooting OPC Communication DCOM and Firewall issues.