OPCClient object communications driver security settings

In order for the OPCClient object to connect to a third-party OPC communications driver, certain security settings are required on the third-party OPC communications driver node.

Note: These same settings must be applied to OPCEnum if the OPCClient is to use the server name instead of the progID.

If the OPC Server is an AVEVA communications driver, no additional configuration is required.

The recommended settings are explained as follows. All of these setting can be set with Windows utility DCOMCnfg.Exe.

1. Run DCOMCnfg.Exe.

2. In the list of applications, select the OPC Communications Driver and then click Properties.

   Note: Under some conditions, the third-party OPC communications driver may not appear in the list of applications. In this case, you will need to create server specific AppID and run DCOMCnfg.Exe again. For information on creating AppID for COM objects, see the Microsoft documentation.

3. Click the General tab.

4. In the Authentication Level list, click None. (The default setting is "Default.")

   The authentication level informs the component object model (COM) how much authentication protection is required, and it can range from authenticating the client at the first method call to encrypting parameter states fully.

5. Click the Security tab to configure who is allowed to launch permissions and access permissions to the server.

   The launch permissions control the list of users who are granted or denied permission to launch a particular server.

   You can control the list of users who are granted or denied access to the methods of a particular server by setting access permissions. You can add users or groups to the list, specifying whether access permission is being granted or denied. You can also remove users from the list.

   When setting access permissions, you must ensure that both SYSTEM and Everyone are included in the list of users that are granted access.

6. Select Use custom access permissions and Use custom launch permissions.

7. For each of them, click Edit and then add "Everyone" and "System" to the list of users allowed to access and launch the server.

8. Click the Identity tab to configure the identity of the server.

   An application's identity is the account that is used to run the application. The identity can be that of the user that is currently logged on (the interactive user), the user account of the client process that launched the server, a specified user, or a service. Thus, you can select from one of the following three options:

   • The interactive user

     The interactive user is the user that is currently logged on to the computer where the application is running. If the identity is set to be the interactive user, all clients use the same instance of the server if the server registers its class factory as multi-use. If no user is logged on, the application will not run. If the server has a graphical user interface (GUI) that the client needs to see, you should use interactive user for the application's identity. However, choosing this identity carries some security risks because the server runs under the identity of the logged on user without the logged on user's knowledge or consent.

   • The launching user

     This is the default setting for the application identity. When the launching user is chosen for the application's identity, each client account gets a new instance of the server, and each server gets its own WinStation. Because of the separate server instances, launching user is the most secure identity setting. However, there are limits on resource consumption. Also, any GUI the server displays will not be seen by the client. Although this is the option selected by default, we recommend to avoid selecting this option.

   • This user

     Specifying a particular user (and the user's password) is the preferred identity for COM servers. The reason this identity is preferred is that no one has to be logged on the machine where the server is running for the server to run, and every client talks to the same instance of the server if the server registers its class factory as multi-use. If the server has GUI, then you should not choose this identity; if you do, the user will not be able to see the user interface. Running as a fixed user account is more secure than the interactive user identity because this identity can only be assigned to the application by someone who has the specific user's password.