DCOM Security and the headaches it tends to create are undoubtedly familiar to any OPC Classic user in the industrial automation industry. Stories about experienced DCOM woes are just part of the territory.
In this second part of a "DCOM Horror Stories" sidebar to our continuing Tech Support Corner blog series, this blog post covers a DCOM user scenario where the user was a little too thorough in locking down their DCOM configuration, resulting in a locked out system. And it includes a reminder of options that help you avoid DCOM configuration altogether.
Security is one of the hottest topics across industrial automation. Everyone wants to ensure their systems and data are as secure as possible. For OPC Classic users (primarily being OPC DA), it's been a reality for decades that DCOM is the platform for security, and it tends to be a less than ideal necessity.
Our tech support team at Software Toolbox encounters users with DCOM issues weekly when providing assistance to users of OPC Classic solutions. And, while we have a comprehensive set of DCOM tutorials to help our users avoid and resolve DCOM issues, sometimes users try to blaze their own path without our assistance, to varying levels of success.
As you are likely aware if you've ever configured DCOM permissions, there are system-level DCOM permissions (configured in "My Computer" root under Component Services) but there are also application or COM component level permissions to be configured. For instance, you'll find an entry for most OPC Server and OPC Clients in DCOM Config.
Our user in today's horror story was a little overzealous when configuring their security policies for their OPC Server and locked the DCOM configuration for their server completely preventing any further configuration of the DCOM permissions for that server.
How can DCOM Configuration Lock Up a System?
So how did this user manage to completely lock themselves out of DCOM configuration for their OPC server? There are three sets of security permissions for an OPC application: Launch and Activation Permissions, Access Permissions and, finally, Configuration Permissions.
The Configuration Permissions section for an OPC application regulates which user accounts and groups are even permitted to access the COM/DCOM security entries in the Windows registry for making changes to DCOM. The Launch and Activations Permissions and the Access Permissions for DCOM are encoded and stored in Windows registry keys. Configuration Permissions restrict access to those registry entries completely.
Our unsuspecting user in this DCOM horror story unfortunately chose to enter the Configuration Permissions for their OPC Server and proceeded to change each group and user account's security permissions to "Deny" for everything. Since their own user account and even the Administrator account for the system had been denied configuration permissions, there was no way to reverse the change manually. The change he had made literally prevented him from changing it back.
This resulted in the user having to fully reload the operating system on their system to restore the registry to it's original state. As I'm sure you can imagine, that was not a trivial effort on a production system. This is also one of the main reasons it is never recommended to make registry changes manually, either, without first having a backup of the registry, as it can have unintended and undesirable effects.
One of the best courses of action, if you must use DCOM and OPC Classic, is to follow a trusted how-to resource like our DCOM tutorials to ensure misconfigurations like this don't occur.
Even better, though, is not having to worry about DCOM ever again in such situations - read on to find out how.
How can DCOM Configuration Issues Be Avoided Entirely?
Now I've mentioned the following options in our previous DCOM Horror Story but want to reiterate them briefly here in case you missed that post.
As I stated previously, moving away from DCOM for your process control systems is a consideration of how much pain you have and will experience as a result of configuring and troubleshooting OPC Classic systems based on DCOM security.
OPC UA and Why It's Easier and More Secure than DCOM
OPC UA is the latest OPC technology intended to supersede the original OPC Classic interface in both ease-of-use, efficiency and, most of all, greater security of your process data. Software Toolbox has a wide variety of OPC UA capable solutions including TOP Server for Wonderware, OmniServer, OPC Data Logger, SLIK-DA with UA, OPC Data Client and more (Click for a list of all Software Toolbox solutions supporting OPC UA).
One of the most common responses we hear when asking OPC Classic users why they aren't using OPC UA is that they have too much invested in OPC Classic systems to just rip-and-replace with OPC UA Clients and Servers.
That's one reason we have a solution called the Cogent DataHub which supports both OPC Classic and OPC UA. It can act as a "gateway" to help you switch your OPC clients and/or servers that already support OPC UA while allowing your other OPC Classic only solutions to work with OPC UA.
OPC Tunneling and Why It's Easier and More Secure than DCOM
Alternately OPC tunneling is a great alternative to DCOM. As with most industrial process technologies, there are multiple tunneling solutions out there (see our guide on the key considerations when picking a tunneling solution).
Our solution for OPC tunneling, the Cogent DataHub, mirrors process data from your OPC server on both sides of the connection, transferring just the raw data for an extremely efficient connection. There are also configurable settings for handling connection breaks with more friendly behavior than making your OPC client wait for a callback that may never come.
And it's far more secure than DCOM - DataHub tunneling supports secure SSL encryption using a self-generated certificate or a certificate you have sourced from a reliable certificate authority such as Symantec, GlobalSign, Thawte and more.
I think it's safe to say that no one enjoys DCOM security. DCOM headaches have a tendency of popping, sometimes in unexpected and usually inconvenient ways.
If you haven't considered migrating away from DCOM on your process systems, think about evaluating the pros and cons of implementing an alternative like OPC UA or OPC tunneling in your control systems as you go forward. And, don't forget Software Toolbox is always here as a resource for your OPC questions - just contact us. (And, if you still haven't gotten your copy, our Free 18 Frequently Asked OPC Questions Guide is still available.)
