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.

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.

SMB in Clusters

The Cluster Operating System Rolling Upgrade feature of Windows Server 2016 allows you to upgrade clustered servers directly to Server 2016 from Windows Server 2012 R2. However, the cluster stays in Cluster Compatibility Mode (CCM) after this action and continues to use SMB 3.0.2 to communicate, even with servers based on Windows Server 2016 or workstations with Windows 10. Microsoft refers to the technology as "Cluster Dialect Fencing." If local shares are available on a cluster node, Windows Server 2016 uses SMB 3.1.1, even if CCM is active for the cluster. However, in this case, shares on the cluster, for example, over a Scale-Out File Server (SOFS), are handled with SMB 3.0.2. However, once you start using Windows Server 2016 mode, the SOFS also uses the new SMB 3.1.1.

For the cluster to use the new SMB 3.1.1 protocol, all the cluster nodes must be operated on the basis of Windows Server 2016. Compatibility mode is then disabled. As long as the cluster is in compatibility mode with Windows Server 2012 R2, file shares are integrated with the cluster using SMB 3.0.2 (e.g., for a SOFS). Only after the migration does the cluster change to Windows Server 2016 mode. You can check the cluster version as follows:

> Get-Cluster | Select UpdateFunctionalLevel

Additionally, SMB 3.1.1 supports improved failover behavior between cluster nodes when deployed on clustered file servers. In doing so, Windows Server 2016 takes into account the user and server SMB sessions and keeps them when virtual file servers are moved between cluster nodes.

Managing SMB Access to Nano Server

SMB access is not active by default on Nano Server. Although Nano Server also uses SMB 3.1.1, all access is blocked until you allow it. You can use Nano Server to access shares via the network and access the C$ share to copy files to the server. This is particularly important if you subsequently want to join a domain with the server or use it for exchanging data.

For successful access, you must enable the firewall rule for SMB access by file and printer sharing in the Nano Server Recovery Console. To do so, press the F4 key. You can then configure the domain entry for Nano Server.

Locating and Disabling SMB 1.0

Because Windows Server 2003 and Windows XP are no longer officially supported, there is no reason to use SMB 1.0 on the network. However, Windows Server 2016 still has an option for doing so. If you no longer want SMB 1.0 to be used, you can remove its functions from Windows Server 2016; computers with Windows Server 2003 and Windows XP, then, would no longer be able to connect to the server via SMB. Because these connections can be hijacked quite easily, you thus have increased security. To use PowerShell to remove SMB 1.0 from Windows Server 2016, enter:

> Remove-WindowsFeature FS-SMB1

Windows Server 2016 lets you monitor whether clients still attempt to use SMB 1.0 to access the server. In this case, the server switches to the insecure SMB 1.0 mode for the connection. You can enable monitoring in Windows Server 2016 with PowerShell as follows:

> Set-SmbServerConfiguration -AuditSmb1Access $true

Finally, entering

> Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit

lets you discover whether any clients are still running Windows Server 2003 or Windows XP on the network.

Conclusions

Clients and servers communicate via the SMB protocol to exchange data. In each version of Windows, Microsoft has provided an updated version of SMB, with numerous innovations in the field of security, performance, and stability. Normally, you do not need to make adjustments, except when older operating systems are deployed.

In general, updating file servers, workstations, and other computers that communicate via SMB to Windows Server 2016 and Windows 10 is worthwhile. If it is not possible, you should consider which SMB version is used and what security issues you may be facing. Generally speaking, SMB 3.1.1 in Windows Server 2016 and Windows 10 is slightly more secure than the direct predecessor SMB 3.0.2. The main innovation in SMB 3.1.1 is pre-authentication integrity, which provides end-to end encryption for SMB connections.