Complications of Domains, Workgroups, & Mixed Windows Versions & Solutions
In the Operations Technology or OT world that most of our users live in, it’s normal to have multiple versions of Windows and systems that may not always be setup consistently but we have to make it all work anyway. Connecting OPC clients and servers when the Windows computers are not on the same version, not in an Active Directory or, using older terminology, a domain, and having everything work well takes skill, and keeping it secure involves a lot of details.
In this blog post, our team asked me to explore with you the details involved to assist you with better understanding Windows Security and to converse more productively with your IT Team. I’ll also share how you can learn more about how to make things easier on yourself through the use of OPC UA or with Tunneling.
To transfer OPC data from an OPC DA server to an OPC DA client, a Windows technology called COM is used. Your HMI software used in your operations is an example of an OPC client. The OPC server is the driver that is talking to your PLCs, DCS, or other control systems. In applications where multiple clients need data from the controllers, the OPC server software is typically put on a separate computer to gain efficiencies in communication by not having multiple clients asking the control hardware for the same data repeatedly.
When the OPC DA server and OPC DA client are not on the same computer, Distributed COM or DCOM is used. When connecting between computers using DCOM, Windows Security gets involved. Windows Security uses a username and password to authenticate each of these different connections.
In the drawing below, for example, each of these things has to be allowed for a typical connection:
- Server PC has to allow the OPC client PC to connect to it over the network
- Server PC has to allow the OPC client software on the OPC client PC to communicate over the connection, using the username/password that the OPC client software is running under
- In order to return data from the OPC server to the OPC client for OPC subscriptions, which is the way most reads are done, the OPC client computer has to allow the user that the OPC server is running under to connect and access the OPC client software
So what this means is that the 2 PCs have to know about the usernames and passwords that the OPC client and OPC server software are running under. You may not realize this but every time a software application runs on Windows, it is running under the authority of some username and password. You may hear us sometimes ask “what username or user context is the OPC client running under”. If the OPC client was launched from a logged-in user, it’s whatever user is logged in on that PC. Things get more complicated if the OPC client software or the OPC server software are running as a service, as you then have to know what user account the OPC server software service is configured to run under.
To make a connection work, you have to configure both PCs to trust the username/password 
combination from the other PC. Imagine if you had to do that in a scenario like the one shown at the right with multiple clients and servers. Our support has received calls from people with just these types of architectures who are trying to make DCOM work.
We have a whole set of tutorials and videos on how you set this up, but over the years we’ve found there are better ways to spend your time and ours.
Feeling complicated already? Want a better way?
Workgroups, Domains and Trust
Over the years, we’ve seen a lot of users’ systems where the computers on their OT network are not in a domain. As IT/OT convergence brings more structure and best practices to the OT world, when applied properly and not over-zealously as they sometimes are, we see fewer networks without a domain.
If your computers are in an Active Directory, or domain, then you have a single repository of all the usernames, passwords, and groups of users on your network. The reason this helps is because when you configure the OPC client and server software, you can just point to one place to get the users. You don’t have to set them up on both, you are choosing to trust the Active Directory as the central authority.
If your computers are in a Windows workgroup, you have to setup and maintain the usernames on BOTH PCs as shown below.
And if you ever change one of the passwords, or you forget to check the “Password never expires” box when setting them up, which is a bad security practice to do anyway, you will wake up one day and expired passwords will have caused your systems to stop working!
Security and the Changing Windows Versions
Now that you understand the mechanics of those OPC connections, and how Windows workgroups and Active Directory are involved, it’s time to address the hottest topic in IT/OT today - security.
Over the years, Microsoft has evolved the security used and they continue to evolve it. When I first was networking Windows PCs in 1993, the network security model used by Microsoft Windows NT and 3.11 was called NTLM. And to this date, if you want to, you can get a Windows PC to use NTLM as its method of passing usernames and passwords between computers. In fact, if you use Windows workgroups instead of Active Directory, NTLM is used.
NTLM has been hacked! Yes, that’s right; it’s old news but it has been. Tools exist (L0phtcrack for example, Google it!), that can scan the network for NTLM password hashes, capture them and do a brute force crack on them to derive the user’s password.
Moral of the story: Don’t use NTLM! Avoid workgroups if security is a concern!
Kerberos Good! Starting with Windows 2000, Microsoft began using a technology called Kerberos for its authentication of users. Named after the Greek character Cerberus, the three-headed guard dog of Hades, it uses several cryptology methods in a multi-phase authentication. Prior to 2000, Kerberos was so secure it was banned from export from the US. Since then the global IT community has collaborated to build on the technology and it’s available to the world and is on its 5th major version.
So please, if you’re going to use DCOM, please use an Active Directory network setup, so that you can benefit from the power of Kerberos.
Here’s the problem as Windows has evolved:
As Windows has evolved, so have the levels and versions of Kerberos in use. And every week, for perfectly valid if not still risky reasons, we hear from clients who have older Windows operating systems that have long since reached Microsoft final end-of-life, in use in their operations. For example, Kerberos 5 wasn’t introduced in Windows until Server 2003.
Because Kerberos uses public key cryptology, it can evolve and use newer better encryption algorithms. Good thing because with increasing computing power, the length of encryption keys has to continuously increase. I recently renewed an SSL certificate and had to sign it with a 2048 bit key! When I bought my first SSL certificate ever in 1997, it was a 56-bit key and that was the best there was!
Well with Windows 7 and 2008R2, Microsoft started using the Advanced Encryption Standard (AES) 128/256 and they block DES, an older Kerberos encryption standard by default!
This means that if you are trying to interoperate between Windows 7, 2008R2 or newer, and operating systems older than those, such as 2008, 2003, XP, or even older, good luck. Windows will struggle to authenticate and if you’re lucky, will fall back to NTLM, which you’ve learned is very risky!
There is a better way!
So why do all of that if there are better ways? One of the better ways could be to use OPC UA, which does not rely on COM and DCOM, and thus Windows security. OPC UA however does require that you still understand SSL encryption, certificate management, and open firewall ports. A good way to learn more about OPC UA is to watch our OPC UA Introduction Seminar.
Since 2006, we’ve recommended and helped users address the connectivity challenges of remote data using OPC Tunneling. Using off-the-shelf software, we’ve seen users setup connections in minutes that didn’t require any dealing with Windows security, that used the highest legally available levels of encryption on their Windows PCs and, in some applications, even setup bi-directional links without opening any inbound firewall ports, with near real-time data transfer speeds, that could recover from network faults seamlessly.
To learn more about the tool these users have implemented, download the free whitepaper below.
