User Permissions Considerations when setting up a DCOM Connection
between An OPC Client and OPC Server
DCOM Tutorial Home
A key foundation for setting up a DCOM connection between two computers is to have the machines setup
so that they have permission to access each other. This is a two way street. The client must have permissions to access the machine with the OPC server and
vice versa. If you don't have permissions set both ways, then you will not have success. This article is not intended to be a substitute for good knowledge
of the Microsoft Windows NT and Windows 2000 user accounts and security model. There are plenty of good books on the subject available at any local bookstore.
This article is intended to point out some key things you need to have setup before you even try to configure a DCOM connection between an OPC client and an
Types of Permissions:
There are some common types of permissions we discuss in our DCOM tutorial
- Access -- these permissions allow a client machine to
connect to a server computer, retrieve a list of OPC servers and connect to a server. They also allow the OPC server to make what is known as a
"callback" to your client. A callback occurs when you ask the OPC server to notify your client only when data changes. If you use these types of
reads, sometimes called "subscription" or "exception" reads, then it is important that Access permissions be set right on the client machine.
- Launch - these permissions are what allows an OPC client application to start or "launch" an EXE running on the machine where the OPC server is located. There are 2 common EXEs that get launched: (1) OPCEnum.exe, a standard OPC common component that lists the available OPC servers on a machine and returns that list to a client and (2) the actual EXE that corresponds to the OPC server. For example, our TOP Server OPC server EXE is "servermain.exe", the INGEAR AB Server is "IGOPCAB.exe"
- these permissions allow a remote client to change the configuration of the OPC servers setup
in the registry - you should rarely have to touch these permissions and in fact should not unless you know what you are doing.
So, the most common permissions you will see us discuss are Access and Launch
Users and Groups:
This document is not meant to replace common books on NT/2000 security, but there are some key concepts
we want to emphasize.
Users: A user is a particular login name+password combination used to gain access to a machine running Windows
Groups: A group contains one to many users. Groups
are a useful way to combine a set of user accounts and grant them certain rights for access and launch. If the actual user names that you wish to have
access to your OPC servers will change with any frequency, we recommend you use Groups when granting all rights. Then all you have to do is add/remove
users from the Groups in the NT/2000 user manager and their rights to access OPC servers will carry along. Proper use of Groups, whether they be ones
you create on your own or any of the NT/2000 default groups, is a great way to reduce your long term maintenance cost of the system
Local Users/Groups: A Local user is an account that is known ONLY to the machine on which the account was setup. Likewise for a Local Group. If you need an account to have access to another machine, and the account is a Local User, you will need to create a Local user with the identical username+password on the remote machine. For this reason, we recommend running OPC Client - Server setups in a Domain if you can - the maintenance and setup is easier.
Domain Users/Groups: A Domain User account is one that can be used anywhere within an NT/2000 domain so long as the computer
is a member of the domain. Authentication of the user is handled by a primary domain controller machine, thus allowing you to centralize your security
management on the user/group level. A Domain Group is a group that is available to any computer that is a member of the domain. We recommend
using Domain user accounts and Groups to setup your DCOM Config permissions when setting up OPC client/server connections-- the risk of problems is lower
and the long term maintenance is much easier.
What's a Domain ?
In Windows NT there is the concept of a Domain (in in Win 2000 domains still applies,
though the concept has been evolved to talk about Forests/Trees, something beyond the scope of this article). A domain is a group of machines that have reasons
to need to be able to work together. For example, you might have the paint shop domain, the body shop domain, the accounting domain, the marketing domain, and
sales domain in a large company. For the majority of their day to day work, the users in each domain need only to access the machines in their group but not
others. The Windows NT concept of a Domain allows you to setup a Domain Server in the group and setup security in the Domain so that the users within the
domain have common access to the Domain server and to some degree, to each other's machines. So for example, in the Paint Shop, you might have a Domain
Server (also called a Primary Domain Controller or PDC in Microsoft-speak) and 10 Windows NT machines. When users login to their boxes, they log in to the
Paint_Shop domain, which then gives them access to any shared resources (drives, printers, etc) in the Paint_Shop domain. Their user name and passwords are
authenticated (validated, checked - pick your term) against a database of users stored on the Domain Server. Unless a special relationship called a
"Domain Trust Relationship" has been setup, users in the Marketing domain would not have access to shared resources in the Paint_Shop domain. In a
Domain Trust Relationship, the PDC (Primary Domain Controller) for the Paint_Shop domain agrees to trust the Marketing domain's users as if they were their
own. Domain Trust relationships and their setup and maintenance is an advanced topic beyond this discussion - just be aware that if you have multiple domains, you have to be more careful with your access rights setup.
In Windows 2000, machines can still be a member of a Domain, but you can optionally also setup Windows
2000 machines to support the new Active Directory security model, a subject which is beyond the scope of this particular document.
Get in the Domain - if you can
Now that you have the idea of a domain, why does it matter to OPC? The primary benefit of both the OPC
client computer and the OPC server computer being a member of a domain is that security is centralized. Both machines will trust accounts that are members of
the domain, meaning their username/password combinations are found in the security database of the PDC machine. The downside is that if the PDC goes down, you
might not be able to validate security after reboot of a machine in the domain until the PDC comes back. Fortunately you can have BDCs or "Backup Domain
Controllers" in a Domain to decrease this risk.
When you run an OPC client application on an NT/2000 machine, that application, even if it is running
as a service, has to run under some user name -- you'll hear this sometimes called "running in the context of user name JoeSmith" -- it means you
are running the application as if it were launched after a user JoeSmith logged into that machine. The same applies to an OPC server -- it too runs under some
user name or "context".
So if we have OPC client on machine A, running under username JoeSmith, and it wants to talk to an OPC
server on machine B, that is running under the name BillJones, then DCOM security defaults require that JoeSmith have access to Machine B, and BillJones have
access to MachineA. Without BOTH of those requirements met, you'll never get your DCOM connection to work, at least not without some major trickery that
just isn't worth the hassle.
OK - so what -- how does a Domain help this situation ? Simple -- if Machine A and B are members of the
Paint_Shop domain, and users JoeSmith and BillJones are both accounts in the domain Paint_Shop, then unless you have done something to abnormally restrict
those user's rights (i.e. taken them out of the Domain Users group or other manual editing of rights), the permissions are already setup, you're done.
This is because Machine A trusts the PDC of the Paint_Shop domain to advise it that BillJones has access, and Machine B trusts the PDC of the Paint_Shop domain
to advise it that JoeSmith has access.
Because of these relationships, getting an OPC client and OPC server on machines in the same domain is
probably the easiest scenario.
No Domain - What do you do ?
If you don't have a domain, it's OK. The risk of the PDC or having to have a BDC to decrease
that risk may be something your network design said doesn't work for you. If your NT/2000 machines are not members of a domain, then they are running as
standalone machines. Every NT/2000 machine (even those in a domain) has it's own "local" database of trusted users. When a machine is not a
member of the domain, the ONLY user accounts it will trust are those it finds in it's own "local" security database.
Here is how this can get you into trouble on setting up and OPC client to server connection. If machine
A has an account JoeSmith and Machine B has an account BillJones, and that is all, then how can an OPC client running as JoeSmith on Machine A, gain access to
an OPC server running as BIllJones on Machine B ? It can't -- when Machine B receives a request from the OPC client, embedded inside that request is the
notation "this is from user JoeSmith on Machine A". Machine B says "I don't know any JoeSmith" and refuses the connection. The typical
error message thrown is "Access Denied". A sure sign you have this issue is when you try to connect to a remote machine with an OPC client to browse
available servers and you can't even connect to the machine through the browse dialog without getting and "Access Denied" error. That's a
sure sign you have a permissions issue between your two boxes.
So what is the solution ? Well fortunately you can trick the boxes. All you need to do is create the
EXACT SAME user account names AND passwords on BOTH BOXES. So on Machine A, you need to have an account JoeSmith AND BIllJones. On Machine B, you also need an
account JoeSmith and BIllJones. The passwords for BOTH JoeSmith accounts MUST match. The passwords for the BillJones accounts must match on both boxes.
JoeSmith and BillJones CAN have different passwords between the two account names, and should for good security measure. You should also make sure those
accounts have identical access rights if you can.
Once you have that setup, when Machine A comes calling on Machine B with an OPC request and identifies
himself as JoeSmith with some password (it's encrypted), Machine B will look in it's database, see the same accountname, the same password, and same
"come on in request from Machine A". When Machine B goes to return it's data from the OPC server to the OPC client on machine B, the OPC server
will go call Machine A as BillJones with a password -- Machine A will look in it's database, see that it has that account, and accept the call.
A good way to see if you have these permissions set right is to go to Network Neighborhood, browse from
Machine A to Machine B and try to connect to Machine B. You may not have any shared folders or printers, but so what - if you can connect to the machine
without error, even if no shared resources are available, you likely have solved the first phase of the Access permissions challenge, gaining access to the
machine. Your next step would be to make sure that the users you've setup are granted the proper rights in the DCOM Config utility on the client side and
We know this may sound like a lot but if you read over this a few times, think about the simple concept
of Machine's A and B allowing people access to the machines, you can see why this permissions issue is so crucial to proper DCOM configurations and
If you have your basic access permissions working (i.e. you can at least see the machine
and see shared folders/shared printers), you can go on to DCOM Client setups or DCOM Server setups.
Warning: contents of this tutorial are Copyright Software Toolbox, Inc. 2001-2002, and
may not be reproduced in electronic or written form without written permission of Software Toolbox Inc. Anyone found copying copyrighted material from
this site for use on another site will be prosecuted. You are welcome to link to this site from your site. The information in this article is
accurate to the best of our professional judgement at the time of writing but is subject to change.