 |
 |
 |
 |
 |
 |
|
User Permissions Considerations when
setting up a DCOM Connection between An OPC Client and OPC Server 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 OPC server. There are some common types of permissions we discuss in our DCOM tutorial
So, the most common permissions you will see us discuss are Access and Launch permissions. 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 NT/2000. 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. 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 server side. 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 setup. 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. |
|
Copyright Software Toolbox, Inc., 1996-2002, All Rights Reserved Worldwide.
|