Introduction to DCOM for Remote OPC Connectivity

ahemcurrentΔίκτυα και Επικοινωνίες

21 Νοε 2013 (πριν από 3 χρόνια και 4 μήνες)

279 εμφανίσεις

Introduction to DCOM for Remote OPC Connectivity


Summary: Understanding DCOM Security is important for optimal OPC connectivity between OPC
Clients and OPC Servers.

Version: 7.0

Created at 2/3/2009 10:21 AM by Boor, Michael

Last modified at 2/3/2009 12:46 PM by Boor, Michael

________________________________________

This article is provided by Kepware Technologies.



Introduction

This article describes how DCOM settings affect local and remote OPC connections.



Specific d
etails about DCOM configuration are outside the scope of this article. For complete
configuration details see the Kepware DCOM Security Configuration document posted on the WDN.

What is it DCOM?

The acronym DCOM stands for Distributed COM where the "COM" i
s Component Object Model by
Microsoft. Since OPC is based on COM it should make sense that remote OPC connectivity is based
on DCOM.


DCOM is basically a way for software components to communicate across a network. DCOM Users
must configure DCOM to allow
Access and Launch capabilities of one application/user by another
application/user.



DCOM Step by Step

The way DCOM Security works is as follows.

1.

The OPC Client makes a request to connect to the server.

2.

The DCOM Security layer checks to see if the U
ser Account that is running the client
requesting the connection is in the DCOM Security Launch and Access Permissions list.

1.

If not then an error is returned to the client and the server is told not to accept it.

2.

If it is, the request is handed to
the server and the server is told to accept it.

3.

The server processes the request and responds back to the client.

4.

The DCOM Security layer checks the responding User Account that the server is running in to
see if it is in the DCOM Security Launch and

Access Permissions list.

1.

If not, the response is handed to the client application which is told not to accept it.

2.

If it is, the response is passed to the client application which is told that it is safe to accept it.




The same process is used
when adding items or performing any other OPC transactions.



DCOM with Common Network Types

Single Domain

A Windows Server Domain is a logical group of computers running versions of the Microsoft
Windows operating system that share a central directory dat
abase.



This central database or Active Directory contains the user accounts and security information for the
resources in that domain. Each person who uses computers within a domain receives his or her own
unique account, or user name. This account can
then be assigned access to resources within the
domain.



In a domain, the Active Directory resides on computers that are configured as "domain controllers."
A domain controller is a server that manages all security
-
related aspects of a user and domain
int
eractions, centralizing security and administration.



When the software components (PCs) reside on a single Domain connectivity can be achieved by
setting the Application Level permissions for the User Accounts that the applications are running
under. Fo
r example, if the Server and Client applications are running under the System Account, only
that account would need to be added to Launch and Access permissions.




Multiple Domains

If however, Server and Client applications are in separate Domains you
will need to use an alternative
to DCOM such as a bridging, mirroring, or tunneling product.



The common question from most customers is when the user will see this type of situation. The first
example that jumps to mind is trying to do an OPC connection
across the Internet.



Each application lies in its own Domain and because DCOM connections cannot span Domains, no
connection can be established.



Similar situations are encountered in Manufacturing environments where it is very common for the
Engineer
ing and Plant Floor Operations to be on separate Domains from the Administrative
Operations.



With the growing trend in our industry toward vertical integration, where real
-
time plant floor data is
provided to upper management, it is common to see connect
ions from multiple domains within the
same facility.



Workgroups

A Workgroup is the other model for grouping Windows computers in a networking environment.
Workgroup computers are considered to be 'standalone'
-

i.e. there is no formal membership or
authe
ntication process formed by the workgroup.



A workgroup does not have servers and clients, and thus represents a Peer
-
to
-
Peer (or Client
-
to
-
Client) networking relationship. Workgroups are considered difficult to manage beyond a dozen
clients (PCs), and lack single sign on, scalability, resilience/di
saster recovery functionality, and many
security features.



If you are in a workgroup, remote OPC connectivity via DCOM will work but there are a few
additional Permissions that will need to be established. For more details see the Kepware DCOM
Security
Configuration document posted on the WDN.



Virtual Private Networks (VPNs)

A virtual private network (VPN) is a communications network tunneled through another network,
and dedicated for a specific network. One common application is secure communications
through
the public Internet, but a VPN need not have explicit security features, such as authentication or
content encryption.



VPNs can be used to separate the traffic of different user communities over an underlying network
with strong security feature
s.



DCOM alternatives may incorporate VPN tunnel or encryption methodologies. However, typically
OPC connectivity is not attempted over a VPN connection. In other words, VPNs are used most often
for the remote configuration and maintenance of applications
, and not the transfer of process data.


DCOM Security Exists: Is it Ignored or Applied?

Many users of OPC
-
based products have little exposure to DCOM. They may assume that if an OPC
client and server are on the same PC then DCOM Security is not used. This

is not correct.



Many OPC client and server applications are designed to ignore DCOM when the server and client are
being Accessed or Launched by one User Account.



DCOM security is always applied if the client and server are running on separate PCs, o
r if one is
running in Desktop Application mode and the other is running as an NT Service.



DCOM Considerations

DCOM receives much more negative attention than it deserves. Although DCOM Security for remote
connectivity can be frustrating to configure, it

is widely
-
adopted around the world.



Remember the following points when using DCOM:



The large majority of DCOM "issues" are related to initial configuration not reliability or
performance at runtime.



DCOM is part of Microsoft operating systems so it
is there (for free) for use by OPC products
developed for Microsoft platforms.



DCOM provides excellent data throughput and performance for most applications.



Plant floor applications often use a Windows Server Domain for their network architecture.



DCOM Security can be adversely affected by Microsoft OS and Service Pack updates.



DCOM Security exists even with local OPC client to server connections but it is often not
Applied

but is Ignored by the OPC products. This is incorporated by OPC product vendors to make
local connections easier.



DCOM was not designed for certain network architectures.



DCOM User Checklist

Here are a few things to consider regarding the installation

and use of OPC
-
enabled products:

1.

Is the OPC client to server connection local (single computer) or remote (between 2 separate
computers)?

2.

What are the operating systems and service pack versions of all computers involved in the
connection?

3.

Is the

computer part of a Domain, Workgroup or some other network type?

4.

Will the OPC products be configured to Run as a Service on NT/XP/Server operating systems?

5.

Who will be responsible for implementing and maintaining any necessary DCOM
configuration and

security at setup as well as over the life of the application?

6.

Will the people responsible for the implementation have adequate User privileges
(Administrator privileges) for the PC or networked PCs involved?

7.

Will the people responsible for the impl
ementation have permissions to set the security and
policy settings that are sometimes required for DCOM configuration?

8.

Are the OPC
-
enabled products provided by active members of the OPC Foundation? Do those
members attend annual interoperability testin
g events and do their OPC products meet OPC
Compliancy?

9.

Are DCOM configuration instructions provided for all OPC enabled products in the solution?
Have these documents been reviewed prior to project commissioning.

10. Is technical support available from

all OPC vendors in the solution?

10.

Have questions 1
-
10 been properly investigated?


Summary

Understanding DCOM Security is important for optimal OPC connectivity between OPC Clients and
OPC Servers. However, with a little foundational knowledge and netw
ork planning by

OPC users as well as occasional guidance and support from OPC vendors, DCOM can be relied on for
the majority of industrial applications.

There are network architectures where alternatives to DCOM are required but with the checklist
above

and a bit of preparation the majority of applications incorporating OPC connectivity will
perform nicely.