SMB signing required by default in Windows Insider

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25381 (Canary, zn_release) Enterprise editions, signing is now required by default for all connections. This changes legacy behavior, where Windows 10 and 11 required signing by default only when connecting to shares named SYSVOL and NETLOGON and where  domain controllers required signing when any client connected to them.

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

You'll recall the Windows 10 and 2019 campaigns against SMB1 and guest auth fallback. Before that, we introduced functionality like and pre- integrity.

Security is a never-ending quest.

Tabletop boardgame figures attack a huge red monsterTabletop boardgame figures attack a huge red monster

SMB signing 

SMB signing ensures every message contains a signature generated using session key and cipher suite. The client puts a hash of the entire message into the signature field of the SMB header. If anyone changes the message itself later on the wire, the hash won't match and SMB knows that someone tampered with the data. It also confirms to sender and receiver that they are who they say they are, breaking relay attacks. Ideally, you are using Kerberos instead of NTLMv2 so that your session key starts strong; don't connect to shares with IP addresses and don't use CNAME records. Signing is a key defensive tactic.

Signing algorithms have evolved over time; SMB 2.02 signing was improved with HMAC SHA-256, replacing the old MD5 method from the late 1990s and SMB1. SMB 3.0 added AES-CMAC. In Windows and Windows 11, we added AES-128-GMAC signing acceleration.

Controlling the new signing behavior

All versions of Windows and Windows Server support SMB signing (back to Windows NT!). But a third-party might disable or not support it. If you attempt to connect to a remote share on a third-party SMB server that does not allow SMB signing, you should receive one of the following error messages:

0xc000a000

-1073700864

STATUS_INVALID_SIGNATURE

The cryptographic signature is invalid.

To resolve this issue, configure your third-party SMB server to support SMB signing. This is Microsoft's official recommended guidance. Do not disable SMB signing in Windows or use SMB1 to work around this behavior (SMB1 supports signing but does not enforce it). An SMB device that does not support signing allows interception and relay attacks from malicious parties. I can't speculate what errors a third-party SMB client will throw if it doesn't support signing and then connects to your Windows 11 client, but I'll update this post if someone reports one.

SMB signing will at least slightly reduce the performance of SMB copy operations. No, I cannot tell you how much; it depends entirely on the speed and number of your cores, as well as their utilization from all the other processes vying for their time. You'll need to evaluate against your workloads and decide if those with extremely high performance and latency requirements override the lack of security brought by unsigned traffic. This is no different than the past 30 years of SMB signing, it's just a change in defaults.

To see the current SMB signing settings, run the following PowerShell commands:

Get-SmbServerConfiguration | FL requiresecuritysignature
Get-SmbClientConfiguration | FL requiresecuritysignature

To disable the SMB signing requirement in client (outbound to other devices) connections, run the following PowerShell command as an elevated administrator:

Set-SmbClientConfiguration -RequireSecuritySignature $false

To disable the SMB signing requirement in server (inbound to your Windows 11 Canary Insider Enterprise edition device), run the following PowerShell command as an elevated administrator:

Set-SmbServerConfiguration -RequireSecuritySignature $false

With this new behavior, you can no longer examine the registry RequireSecuritySignature settings to know if Windows is requiring signing, because if they don't exist, Windows will still require signing. Any auditing tools that look at the registry could give false information. Use Get-SmbServerConfiguration and Get-SmbClientConfiguration or the CIM classes MSFT_SmbClientConfiguration and MSFT_SmbServerConfiguration and ensure any or auditing tools use them (this has been the right approach for all SMB settings for a decade).

You don't need to reboot but existing SMB connections will still use signing until you close them or restart the device. If you disable the new default requirement for SMB signing with PowerShell or using Group Policy, it won't come back on automatically, it will just return to the legacy behaviors of Windows 11.

Final thoughts

Expect this default change for signing to come to Pro, Education, and other Windows editions over the next few months, as well as to Windows Server. Depending on how things go in Insiders, it will then start to appear in major releases.

SMB encryption is far more secure than signing but environments still run legacy systems that don't support SMB 3.0 and later. If I could time travel to the 1990s, SMB signing would've always been on and we'd have introduced SMB encryption much sooner; sadly, I was both in high school and not in charge. We'll continue to push out more secure SMB defaults and many new SMB security options in the coming years; I know they can be painful for application compatibility and Windows has a legacy of ensuring ease of use, but security cannot be left to chance.

To get the latest Canary Windows insider ISO, visit Download Windows Insider Preview ISO (microsoft.com)

For more information on SMB security, check out:

Until next time,

Ned “I had Nevermind on cassette” Pyle

 

This article was originally published by Microsoft's Windows Security Blog. You can find the original article here.