The process of installing most applications, even in a hardened environment, is generally rather straight forward and there usually aren’t too many issues. Installing SQL Server in a cluster configuration, or any other use of a Windows Failover Cluster, is a bit harder in any environment needing to meet Defense Information Systems Agency (DISA) Security Technical Implementation Guideline (STIG) requirements. Or any other environment trying to be hardened to other standards.
If you harden your environment going straight by the Windows Server 2016 STIG, you’re going to run into problems getting failover clustering going. Below we’ll identify one of them and what you can do to work around it. Though in the end you’ll need to get the change documented through your cyber security team and approved by your Designated Approval Authority (DAA). I can hear you all groaning now.
A few years back, Microsoft introduced two security identifiers (SIDs) that were meant to protect against “pass the hash” techniques. They were introduced in Windows 7 and 8, and Windows Server 2008 R2 and 2012 as part of KB 2871997. The two identifiers are “NT AUTHORITY\Local Account” (S-1-5-113) and “NT AUTHORITY\Local Account and member of Administrators group” (S-1-5-114). These new SIDs are part of Server 2016 and do not require a KB to be created.
The Windows Server 2016 STIG calls for the “NT AUTHORITY\Local Account” to be used in a few denial policies within the “User Rights Assignment” section of Group Policy. One example being “Deny access to this computer from the network”. But why is this done? What’s the benefit and why do we care?
Well, the use of local system accounts to access a machine remotely, such as the built in administer account, is problematic for a variety of reasons. Chief among them is when multiple machines with the same local administrator account name also have the same password. Compromising any one of them gets an intruder, or malicious insider, instant access to all the machines and allows them to move horizontally through the environment; if not vertically as well. (Of course, using the same password on domain joined machines is an Active Directory STIG violation, so if you followed that requirement to a “T” you wouldn’t need to apply this in the first place. But that’s Defense in Depth, and it’s hard to argue with good security, or the STIGs)
So how does all this work? The “NT AUTHORITY\Local Account” SID is applied to a user’s access token at logon if the account is local to that machine. The “NT AUTHORITY\Local Account and member of Administrators group” SID is also added to the token if the account is also a member of the built in Administrators group. Prior to the existence of these SID’s, you would have needed to apply each local account by name to Group Policy settings such as “Deny log on through Remote Desktop Services” and “Deny access to this computer from the network” to get the same effect. So this is much simpler.
Now that the Windows Server 2016 STIG calls for those settings, the CLIUSR account is denied the ability to access systems remotely. Windows Server Failover Clustering, needed for SQL clustering, depends on the non-administrative local CLIUSR account for cluster node management. Blocking that accounts ability to logon over the network causes the cluster service to fail.
However, since CLIUSR isn’t a member of the built in Administrators group, we can substitute the “NT AUTHORITY\Local Account and member of Administrators group” within that DISA STIG setting. After that substitution, the CLIUSR will be able to access the nodes in the cluster remotely and the cluster service will run as expected.
The only problem your left with is to document it and explain it to your cyber security team so they can update your Risk Management Framework (RMF) documentation. All the rest of your servers that don’t run Failover Clustering, or have some other need to authenticate remotely, should be able to conform with this newer STIG requirement.
We hope if you’ve come across this issue, that this helps to resolve it.