Sharing

In each version of Windows, Microsoft provides an updated version of the Server Message Block (SMB) protocol. Windows Server 2016 and Windows 10 communicate via the new SMB 3.1.1, offering some new features in terms of performance and security. Of course, Windows Server 2016 and Windows 10 can still use SMB to talk to older Windows versions and to Linux without problem (see the "Linux and SMB 3.1.1" box), although you must use an SMB version from the oldest system present. In this article, I introduce the use of SMB 3.1.1 and examine its compatibility issues.

The new version of the SMB protocol can prevent man-in-the-middle attacks by extending SMB encryption. SMB 3.0 in Windows 7 and Windows Server 2012 already did its best to restrict access to data transmitted by attackers. In SMB 3.1.1, the cipher is exchanged during the connection establishment process, the aim being to ensure that security is in place even before the client and server have mutually authenticated. Microsoft designates this new feature "pre-authentication integrity." The authentication data is encrypted with SHA-512.

Because the older Secure Negotiate function is rarely used and has caused some problems – especially with third-party software – you can now disable this feature, which can improve communication performance, especially if you are not using the function anyway.

More Secure

In SMB 3.1.1, Secure Negotiate is replaced by pre-authentication integrity. In connections with older versions of SMB, you cannot bypass Secure Negotiate, which stabilizes the connection to older systems. Third-party products that do not use Secure Negotiate are blocked by Windows Server 2016, unless they support pre-authentication integrity. That can be problematic, especially for systems that connect different data centers and the servers installed therein.

SMB 3.1.1 uses AES-128-GCM for encryption. According to Microsoft, this encoding can cope better with the latest Intel and AMD processors and can accelerate access via SMB, especially between servers (e.g., where Storage Spaces Direct or the new Storage Replica in Windows Server 2016 is used). Both of these new features are capable of communicating via SMB 3.1.1. Microsoft states a possible performance increase of 100 percent when copying large files over the network.

Windows 10 and Windows Server 2016 both also offer AES-128-CCM, however. Clients and servers negotiate which technology to use during the connection establishment process. If the client and server both support AES-128-GCM, this new technology is used; however, if you have clients running Windows 8.1 or Windows Server 2012 R2 or older, Windows Server 2016 and Windows 10 will use AES-128-CCM communications instead. In addition to SMB Encryption is SMB Signing. The two functions can be used in parallel, because it is the only way to make sure the client and server cannot be compromised and to avoid data sniffing.

SMB Encryption Hands On

SMB Encryption can be controlled using these PowerShell cmdlets:

> Set-SmbServerConfiguration -EncryptData <0 for False; 1 for True>
> Set-SmbShare -Name Share -EncryptData <0 for False; 1 for True>
> New-SmbShare -Name <Share> -Path <Path> -EncryptData 1

In exceptional cases, access can be unencrypted:

> Set-SmbServerConfiguration -RejectUnencryptedAccess <0 for False; 1 for True>

SMB Encryption can thus be defined per server for all shares or for individual shares. If SMB Encryption is configured for a server, you have no way to make adjustments at the share level. If you disabled SMB Encryption on a server, however, you can subsequently enable encryption for individual shares. If you enable encryption for a share or the entire server, clients are not given access if they send unencrypted requests. You can control this behavior in PowerShell as follows:

> Set-SmbServerConfiguration -RejectUnencryptedAccess <0 for False; 1 for True>

If you set a value of 0 for the -RejectUnencryptedAccess option, the server also accepts non-encrypted requests from clients that do not support encryption, including, for example, servers with Windows Server 2003 or Windows XP computers. In addition to controlling SMB, the Get-SmbServerConfiguration (Figure 1) and Get-SmbShare cmdlets supply detailed information about shares and the local SMB configuration.

Figure 1: PowerShell commands let you view detailed information about SMB.

Compatibility with Older SMB Versions

As mentioned before, Windows Server 2016 and Windows 10 can communicate with older versions of Windows; however, you must use SMB version 3.0.2 or earlier for compatibility reasons. The earlier versions do not have the security features, or the (potential) performance gains offered by SMB 3.1.1. Incidentally, this is also true for use with Windows Server 2012 R2 and Windows 8.1. As soon as a server with Windows Server 2016 communicates with a Windows 8.1 client, it uses SMB 3.0.2; likewise, it uses SMB 3.0 for Windows 7 and Server 2012. Significant features for fast and secure data exchange on the network are missing; for example, the opportunity to use multiple parallel access via SMB (SMB Multichannel).

SMB Multichannel in SMB 3.0.2 pools the bandwidths of various network adapters and allows parallel SMB access to shares. SMB Multichannel accelerates data traffic and protects it against the failure of a single SMB channel. The benefit is that server-based services can also store data on servers, rather than only on their own hard drives. To use this function, the network adapters must offer a suitable speed. Microsoft recommends the installation of a 10Gb adapter or at least the use of two 1Gb adapters and the use of the network card teaming function in Windows Server 2016.

For SMB Multichannel, you need to use at least Windows 8.1. If Windows 10 is installed on the clients, the server uses SMB Multichannel with SMB 3.1.1, unless a server with Windows Server 2012 R2 is involved. In this case, it reverts to SMB 3.0.2 again. As in SMB 3.0.2, all parallel channels in SMB 3.1.1 are encrypted with the same key, allowing the client and server to communicate over different channels with the same encryption.

On Windows 2016, SMB Direct is enabled between servers without the need for installation and configuration. To use this function, the installed adapter needs remote direct memory access (RDMA) support, which allows servers to transfer data from system RAM across the network to a different server with free capacity. For this to work, the network must be extremely fast (i.e., adapters of type iWARP, InfiniBand, or RDMA over Converged Ethernet [RoCE]). Hyper-V and SQL Server mainly benefit from this technology.

Hyper-V in Windows Server 2016 also can access the SMB protocol directly. The idea is that corporations should not store Hyper-V virtual hard drives (VHDX) directly on the Hyper-V host, but on a network share, which can quickly be accessed using Hyper-V with SMB Multichannel, SMB Direct, and Hyper-V over SMP. High-availability solutions such as live migration work in the same way. The cluster's shared disk then no longer needs to reside on a costly storage area network (SAN); instead, a server with Windows Server 2016 and enough free disk space is fine. The virtual servers' configuration files can be stored on this host, along with any existing snapshots. Cluster Shared Volumes (CSVs), the storage service for shared disk clusters required for Hyper-V, also support the SMB 3.1.1 protocol and its new features.

If you also use MS SQL Server version 2008 R2 alongside Windows Server 2016, the database server can benefit from the new SMB protocol. Transaction logs, database files, and backups can be outsourced to file servers running Windows Server 2016.