Most industrial sites that have been operating for more than ten years are running their SCADA servers and engineering workstations on the corporate IT domain, the same Active Directory domain that manages email, file servers, and business PCs. This made sense when OT and IT were separate worlds with no network connection between them. It makes considerably less sense now.
An IT/OT domain migration, creating a separate Active Directory domain specifically for OT systems and moving control system computers off the corporate domain, is one of the highest-impact structural security improvements a site can make. It is also one of the most operationally complex. This article explains what is involved and what to expect.
Why the corporate IT domain is a problem for OT
When an OT computer is a member of the corporate IT domain, several things follow:
- Group policies applied by the IT domain also apply to OT computers, including policies around software updates, security settings, and user access that may be inappropriate or disruptive to SCADA and PLC operations
- OT computers can be accessed by IT domain administrators, a legitimate IT access right that creates an unnecessary pathway into the OT network
- Password policies, account lockout settings, and other Active Directory controls applied to business users also apply to SCADA accounts, and may conflict with operational requirements (for example, SCADA display terminals that need to auto-login without a password prompt)
- Domain compromise, whether through ransomware, credential theft, or other attack, can propagate to OT computers without additional barriers
The goal of an OT domain migration is to place OT computers in an Active Directory domain that is entirely separate from the corporate IT domain, with its own domain controllers, its own group policies appropriate to OT operations, and its own account management.
Domain architecture options
There are three common architectural approaches:
- Separate OT domain, no trust: the OT domain is completely independent of the IT domain. No accounts are shared, no trusts exist. Users who need access to both IT and OT systems maintain separate credentials for each. This is the most secure option.
- Separate OT domain, one-way trust: the OT domain trusts the IT domain (or a specific subset of it), allowing IT domain accounts to authenticate to OT resources. This is convenient but introduces a pathway from IT into OT that requires careful management.
- OT OU within the IT domain: OT computers are moved to a dedicated Organisational Unit (OU) within the existing IT domain, with separate group policies applied. This is the least disruptive option but provides the weakest separation.
For most industrial sites where a genuine IT/OT separation is the goal, the separate OT domain with no trust (or a carefully scoped one-way trust) is the right architecture.
At Glencore’s Hail Creek and Rolleston mines, the OT domain is a fully separate Active Directory forest, OT.NET, with its own domain controllers, DNS, DHCP, and group policies, running on a VMware vSphere cluster managed entirely within the OT network. IT domain administrators have no access to OT systems.
What the migration process involves
Migrating computers from the corporate IT domain to a new OT domain is not a simple domain-join operation. For every SCADA server, engineering workstation, and OT PC being migrated, the process typically involves:
- Create a local administrator account on the machine before disjoining from the IT domain, which is essential to retain login access during the transition
- Update the machine’s IP address, DNS server settings, and network gateway to point to OT domain infrastructure
- Disjoin the machine from the IT domain
- Join the machine to the OT domain
- In OT domain Active Directory, create a machine account in the appropriate Organisational Unit and configure the relevant group policies to apply
- Create OT domain user accounts for all personnel who need access, with individual accounts per user, not shared accounts
- Reinstall or reconfigure any applications that relied on IT domain accounts or IT domain infrastructure (email clients, corporate software, remote access tools)
- Test all SCADA and PLC communications, as many drivers and communications configurations are tied to machine names or domain accounts
Group policies for OT systems
One of the most operationally significant benefits of a separate OT domain is the ability to apply group policies specifically designed for OT, rather than accepting IT-focused policies that were designed for business computers.
Key areas where OT-specific group policies make a difference:
- Password and lockout policy: SCADA display terminals often need to auto-login without prompting an operator for a password. OT group policies can be configured to permit this for specific machine types without compromising the broader domain policy.
- Windows Update: automatic updates should be disabled on OT systems and applied only during planned maintenance windows after testing. OT group policies can enforce this.
- USB and removable media: group policies can restrict removable media use on OT systems, enforcing site policies without relying on individual compliance.
- Software restriction: group policies can limit which software can execute on OT systems, reducing the attack surface.
Planning the cutover
The most operationally sensitive moment in an IT/OT domain migration is the cutover, the point at which each computer disjoins from the IT domain and joins the OT domain. For a SCADA server, this requires the SCADA system to be shut down, the domain migration completed, the system restarted on the new domain, and all SCADA communications verified before returning to operation.
For a site with multiple SCADA servers, engineering workstations, and operator terminals, this is typically planned across several maintenance windows rather than attempted as a single cutover event.
Thorough documentation before the migration starts is essential. Every machine’s current IP address, DNS settings, domain membership, and installed software should be recorded. Recovery from a failed domain migration is significantly easier when the pre-migration state is fully documented.
About the author
Dennis Murphy RPEQ is the principal engineer at Beetle Engineering & Automation, based in Mackay, Queensland. He has delivered IT/OT domain migration work across multiple Queensland industrial sites including Glencore’s Hail Creek and Rolleston coal mines. Contact: [email protected]