It is very rare that DCOM security for the CIMPLICITY OPC Server will remain off. Most environments require controlled access to systems interacting with a manufacturing process.

When communications between the OPC Server and your OPC client application are satisfactory, you will want to consider enabling DCOM security.

The degree of security enabled is dependent upon the policies at the site where the OPC Server is installed.

The topic of DCOM security (and Windows security for that matter) is extensive and can be confusing. There are several books dedicated to these topics alone. In addition, detailed information about DCOM security can be found at the OPC Foundation Web site, www.OPCFoundation.org, and the Microsoft Web site, www.Microsoft.com.

Brief definitions of DCOM security settings for CIMPLICITY OPC Server / OPC client interactions are as follows.

	Authentication security
	Domain authentication
	Authorization security
	Activation security

Authentication security

Authentication security ensures that the interaction between an OPC client and the CIMPLICITY OPC Server is legitimate. Authentication security for DCOM is an extension of the standard Windows operating system security (which itself is layered upon secured RPC (remote procedure call)). Authentication poses the question "Is the OPC client who it says it is?" and "Is the OPC server who it says it is?". The user configures the level of authentication required, which specifies how often this question is posed. Each more secure level places extra processing overhead on communications between the OPC client and the OPC server. A client and server negotiate to the highest level of authentication when the configured authentication levels differ.

For example, authentication can be required only at OPC client connection time to a server (level = Connect). Once a client is connected (and is authorized to use the OPC Server), all interactions are performed without further authentication. As another example, authentication can be required at the packet level (level = Packet Privacy), with each packet being fully encrypted. The choice of the authentication level is dependent on the security policies of the user.

In a multi-node computing environment, the security system on the computer node running the OPC server must be able to verify that the security ID of the OPC client is valid. In a domain environment, domain accounts must be validated. In peer-to-peer environments, matching local user accounts must be configured.

Authentication of an OPC client must be satisfied before authorization and activation permissions are checked. If a client cannot be authenticated, permission checking for the requested action is not performed.

Up

Domain authentication

A domain authentication architecture provides the lowest cost solution (from a maintenance perspective) for DCOM security. If you are using a domain, then follow (or ask your network administrator to follow) these general setup guidelines:

Create a new domain group. Users who are part of this group will be allowed to launch the CIMPLICITY OPC Server and access its objects.

Add the new group to the launch permissions and access permissions for the CIMPLICITY OPC Server using the DCOMCNFG utility.

Make sure all user accounts that run an OPC client application are part of this new group.

Up

Authorization security

Authorization security occurs once an OPC client transaction has been authenticated. At that time DCOM security must determine if that OPC client is authorized to perform call-level interactions with the OPC server. (COM/DCOM technology allows OPC client applications to make programmatic calls across process and computer node boundaries.) This determination is made by looking at the ACL (access control list) for the OPC server COM object. This ACL (or list of users and / or user groups) for the OPC server is configured using the DCOMCNFG utility supplied with the Windows operation system.

If the OPC client's user identity is listed on the OPC server's access permissions ACL (as a user or group member), then the OPC client can access CIMPLICITY OPC Server objects.

To restrict access of OPC clients to a CIMPLICITY OPC Server that is already running (authorization security), modify the access control list (ACL) of the OPC server by editing the custom access permissions with DCOMCNFG.

Up

Activation security

Activation security is unique to DCOM. The DCOM framework provides the ability for an OPC client to access the CIMPLICITY OPC Server object. If the OPC server object is installed on another computer node, then the framework launches (or activates) the OPC server (if it is not already running) on behalf of the client. Activation permission checking works the same as authorization permission checking. An authenticated client's user identity is checked against the OPC server's ACL for launch permissions. Activation permissions for the CIMPLICITY OPC Server are set up using DCOMCNFG.

Enable CIMPLICITY OPC Server activation security by editing the custom launch permissions for the OPC Server and specifying known users and / or groups.

Note: As a general rule, the activation security should always be more restricted than the authorization security. This prevents the situation where an OPC client can activate the CIMPLICITY OPC Server, but cannot use the OPC Server objects.

Up

More information

CIMPLICITY OPC Server technical notes.

---