Security is at the forefront of many administrator's minds and with Failover Clustering, we did some improvements with Windows Server 2019 and Azure Stack HCI with regards to security.
Since the beginning of time, Failover Clustering has always had a dependency on NTLM authentication. As the versions came and went, a little more of this dependency was removed. Now, with Windows Server 2019 Failover Clustering, we have finally removed all of these dependencies. Instead Kerberos and certificate-based authentication is used exclusively. There are no changes required by the user, or deployment tools, to take advantage of this security enhancement. It also allows failover clusters to be deployed in environments where NTLM has been disabled.
This goes for the bootstrapping of the cluster to the starting of the resources and drives. With the bootstrapping process, the need of an Active Directory domain controller is also no longer needed. As explained in this blog, we have a local user account (CLIUSR) that is used for various things now. In conjunction of this account as well as the use of certificates:
- Cluster Service starts and forms the cluster
- Other nodes will join the cluster
- Drives (including Cluster Shared Volumes) will come online
- Groups and resources start coming online.
This is especially beneficial if you have a domain controller is virtualized running on the cluster, preventing the "chicken or the egg" scenario.
Another security concern that administrators have is what is out on the wire. There are a couple of security settings to consider with regards to communications between the nodes and and storage. From a storage perspective, there is Cluster Shared Volume (CSV) traffic for any redirected data and Storage Bus Layer (SBL) traffic, if using Storage Spaces Direct.
Let's first talk about cluster communications. Cluster communications could contain any number of things and what an admin would like is to prevent anything from picking it up on the network. As a default, all communication between the nodes are sent signed, making the use of certificates. This may be fine when all the cluster nodes reside in the same rack. However, when nodes are separated in different racks or locations, an admin may wish to have a little more security and make use of encryption.
This setting is controlled by the Cluster property SecurityLevel and has three different levels.
1 = Clear Text
2 = Signed (default)
3 = Encrypted
If the desire is to change this to encrypted communications, the command to run would be:
(Get-Cluster).SecurityLevel = 3
The other bit of communication between the nodes would be with the storage. Both Cluster Shared Volumes (CSV) has traffic on the wire and if using Storage Spaces Direct, you have the Storage Bus Layer (SBL) traffic. For these bits of traffic, the default is to send everything in clear text. Admins may decide they wish to secure this type of data traffic to lock it down and prevent sniffer traces from picking anything up.
This setting is controlled by the Cluster property SecurityLevelToStorage and has three different levels.
1 = Clear Text (default)
2 = Both CSV and SBL traffic are signed
3 = Both CSV and SBL traffic are encrypted
If the desire is to change this to encrypted communications, the command to run would be:
(Get-Cluster).SecurityLevelToStorage = 3
One caveat to the SecurityLevel and SecurityLevelToStorage that must be taken into consideration. These forms of communication are using SMB. When using a form of encryption on the network with SMB, RDMA is not used. Therefore, if you are using this on RDMA network cards, RDMA is not used and can cause a performance impact. Microsoft is aware of this impact and working on correcting this for a later version.
Thanks
John Marlin
Senior Program Manager
Posted at https://sl.advdat.com/3eevtLZ