Any OPC Classic user in the industrial automation industry has almost certainly had their interactions with Windows DCOM security. And most, if not all, are stories that we all shake our heads at and nod in understanding of the difficulties of traversing the pitfalls of DCOM security configuration.
In this first part of a "DCOM Horror Stories" sidebar to our continuing Tech Support Corner blog series, this blog post covers a DCOM user scenario involving the Microsoft Windows Cortana search capabilities being sidelined by DCOM security misconfiguration. Additionally, it covers what options are out there for avoiding DCOM entirely for situations like this.
Problems and headaches involving Windows DCOM security are one of the most encountered topics our tech support team encounters when providing assistance to users of the OPC Classic solutions at Software Toolbox. Over the years, we've developed a set of DCOM tutorials to help our users mitigate the issues they have configuring DCOM.
As we all know, though, not every situation can be accounted for when there are many different variables in play. Given how much our support engineers deal with DCOM on a day-to-day basis, we're going to share several DCOM horror stories over the coming weeks and months that our users have experienced and that we've helped them overcome just to underline the complexities of DCOM when compared to alternatives such as OPC UA or secure tunneling.
Our first DCOM horror story involves a Windows function that many of us use. Cortana is the voice-activated "personal assistant" that Microsoft Windows provides as an answer to Apple's Siri. Assisting with many tasks including local and internet search functions, if you're used to having access to Cortana for your day-to-day routine, then suddenly not having her could be quite a nuisance.
Some of our users experienced just that after configuring Windows DCOM security rendered Cortana quite voiceless.
How can DCOM Configuration Break Windows Cortana?
If you've ever configured Windows DCOM (which I'm guessing is true for a lot of you), you don't need me to tell you that there are several sections requiring configuration in Windows Component Services, with one of them being the computer/server level DCOM settings.
As you may be aware, one of our key recommendations when working on DCOM security is to initially "open it up" by setting the minimum DCOM security levels, when first starting, to get everything to work. Then, incrementally, you would increase the security levels such that they are at the highest levels possible while still allowing OPC systems on the machines to work correctly.
So, if you ever been through our DCOM tutorial, you may recall that, at the server level, our suggestion for the "Default Authentication Level" under the "Default Properties" tab of the server level settings is a value of "None". The recommendations in our DCOM tutorial were certainly valid for this user story with respect to getting the OPC connections working correctly remotely.
However, this was in the earlier days of Windows 10, which happened to be this user's operating system of choice. What this user wasn't aware of was that there was an issue with underlying Cortana components in Windows that are using DCOM permissions to communicate with each other. Those underlying Windows components handled the system indexing and search, Windows Update Services, and other Windows functions and required the Default Authentication Level of DCOM when making their connections to other windows services.
The default setting is "Connect". So setting "Default Authentication Level" to "None" as part of the process of configuring DCOM for OPC Classic caused those components to stop working. Initially, this user was between a rock and a hard place as it became a situation where they either had to set the authentication level to "None" to get OPC Classic to work, or set it to "Connect" to get Cortana and the associated Windows components to work correctly. And, for awhile, they did just that; toggling the authentication level setting as needed.
Ultimately, this was a Windows issue that was resolved in the next round of Windows updates such that setting the "Default Authentication Level" to "None" allowed Cortana and the other underlying components to work correctly along with their OPC systems.
Wouldn't it be nice, though, not to have to worry about DCOM ever again in such situations?
How can DCOM Configuration Issues Be Avoided Entirely?
You've likely heard some of the options I'm going to propose - you may have even considered some of them in the past. In the end, eliminating DCOM from 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.
How much is it worth to your sanity, peace of mind and the bottomline of your process to have reliable, secure connectivity?
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 was an early adopter of OPC UA for our 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).
With OPC UA, there is no DCOM because OPC UA was designed specifically not to rely on DCOM. Instead, OPC UA relies on secure certificates, secure encryption algorithms and user authentication, providing a far greater level of data security than DCOM ever could.
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.
We completely understand that - it'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.
Migrating from OPC Classic to OPC UA can be an incremental process when approach in that manner allowing you to upgrade your systems at your own pace.
OPC Tunneling and Why It's Easier and More Secure than DCOM
You've likely at least heard of OPC tunneling and why it's a great alternative to DCOM in the past. There are multiple solutions out there and they're not all created equal (See our guide on the key considerations when picking a tunneling solution).
Much like OPC UA, OPC tunneling doesn't rely on DCOM for remote connections between clients and servers. A tunneling components resides on both the OPC client and OPC server machines, requiring only local OPC communications (which eliminates DCOM from the equation).
Where differences lie between OPC tunneling solutions is the method of data transfer between the two tunneling components. Some solutions just tunnel the actual OPC calls back and forth between machines. This can be problematic for several reasons.
First, it's less efficient than just transferring raw data (it's simply more handshaking and data volume). And, secondly, if there is a disconnect on the network between the two machines, the OPC Client side will be sitting there waiting on a response to the OPC call just waiting until it times out.
Our solution for OPC tunneling, the Cogent DataHub, simply mirrors the process data from your OPC server on both sides of the connection, transferring just the raw data for a much more 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, security-wise, it's far better than DCOM as 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.
In summary, I can say that I've never met a single person in my 13 years in the automation industry that actually likes dealing with DCOM security. DCOM issues can ruin the day of almost anyone unfortunate enough to encounter them.
So I encourage you, if you don't have an existing migration plan in place to move away from DCOM, evaluate the pros and cons of using an alternative like OPC UA or OPC tunneling in your control system and make a plan. And, as always, don't forget Software Toolbox as a resource for any OPC questions you may have - just contact us. (And, if you haven't gotten your copy, our Free 18 Frequently Asked OPC Questions Guide is still available.)
