SMB client encryption mandate now supported in Windows Insider

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25982 (Canary Channel), SMB now supports requiring encryption of all outbound SMB client connections. With this new option, administrators can mandate that all destination servers support SMB 3.x and encryption, and if missing those capabilities, the client won’t connect. This enforces the highest level of network security as well as bringing management parity to SMB signing, which allows both client and server requirements.

SMB encryption

SMB Encryption supplies SMB data end-to-end protection from interception attacks and snooping. It first shipped in SMB 3.0 on Windows 8 and Windows Server 2012. Windows 10 and Windows Server 2019 added AES-GCM support for better hardware-accelerated encryption, then Windows 11 and Windows Server 2022 introduced AES-256-GCM cryptographic suites. Today you can configure SMB encryption on a per share basis, for the entire file server, when mapping drives, or when using UNC Hardening.

SMB client encryption mandate

You can now also configure the SMB client to always require encryption, no matter what the server, share, UNC hardening, or a mapped drive requires. This means an administrator can globally force a Windows machine to use SMB encryption – and therefore SMB 3.x – on all connections and refuse to connect if the SMB server does not support either.

Configuring SMB encryption mandate

You can configure this new option with both Group Policy and PowerShell.

Group Policy

To configure SMB client for required encryption to all SMB servers (i.e., for outbound connections), enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Require encryption

[ATTACH=full]54528[/ATTACH]Group Policy editor UI

Setting the policy to disabled or not configured removes the encryption requirement.

Important: use care when deploying SMB encryption through group policy to a heterogenous fleet. Any legacy SMB servers such as Windows Server 2008 R2 won’t support SMB 3.0. Older third-party SMB servers might support SMB 3.0 but not encryption.

PowerShell

To configure the SMB client for required encryption to all SMB servers (i.e., for outbound connections), set the following PowerShell parameter:

Set-SmbClientConfiguration -RequireEncryption $true

To see the effective setting on a machine:

Get-SmbClientConfiguration | FL RequireEncryption

Final notes

SMB encryption has performance overhead and compatibility overhead, and you should balance that against SMB signing - which has better performance and tamper protection but no snooping protection – or against no use of encryption or signing at all, which has best performance but no security. SMB encryption supersedes SMB signing and supplies the same level of tamper protection, meaning that if your SMC client requires signing, SMB encryption turns it off; there is no point requiring both because encryption wins.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

• SMB client encryption mandate now supported in Windows Insider (October 2023)
  
• SMB over QUIC client access control now supported in Windows Insider (October 2023)
  
• SMB NTLM blocking (September 2023)
  
• SMB dialect management (September 2023)
  
• SMB signing required by default in Windows Insider (June 2023)
  
• The beginning of the end of Remote Mailslots (March 2023)
  
• SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
  
• SMB authentication rate limiter now on by default in Windows Insider (September 2022)
  
• SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)
  

For more information on securing SMB on Windows in-market, check out:

• SMB security enhancements | Microsoft Learn
  
• Secure SMB Traffic in Windows Server | Microsoft Learn
  
• Protect SMB traffic from interception | Microsoft Learn
  

Until next time,

- Ned Pyle

Continue reading...