Server

SMB Versions and Signing, Demystified

By Prabath Thalangama· October 24, 2026· 4 min read
#smb#windows#security

Introduction

SMB (Server Message Block) is the protocol behind Windows file shares, \\server\share, and much of Active Directory's plumbing. It's had three major generations, and the differences matter for both security and performance.

The versions

Dialect Introduced Notes
SMB 1.0 (CIFS) 1980s–90s Chatty, no real integrity protection, WannaCry / EternalBlue vector. Disable it.
SMB 2.0 / 2.1 Vista / Win7 Far fewer round trips, larger reads/writes, durable handles, signing available
SMB 3.0 / 3.0.2 Win8 / 2012 AES-CCM encryption, secure dialect negotiation, SMB Direct (RDMA), multichannel
SMB 3.1.1 Win10 / 2016 AES-GCM, mandatory pre-auth integrity (SHA-512), stronger nego tamper-proofing

SMB1 has no legitimate use on a modern network. It can't be signed meaningfully, its authentication is weak, and it's how several worms spread laterally. The only thing keeping it alive is ancient NAS boxes and MFPs (scan-to-folder) — replace or isolate them.

# Windows: check and remove SMB1
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol
# Samba: force minimum protocol in smb.conf
[global]
    server min protocol = SMB2_10
    client min protocol = SMB2_10

Dialect negotiation

The client sends a NEGOTIATE request listing the dialects it supports; the server picks the highest it also supports. SMB 3.1.1 adds pre-authentication integrity: both sides hash the full negotiate exchange, so an attacker can't silently downgrade the connection to a weaker dialect (the "secure negotiate" problem SMB 3.0 partially addressed and 3.1.1 nailed).

If a Windows client and Windows server both support 3.1.1, that's what they use — you don't configure it, you just make sure SMB1 is off so it can't be the fallback.

Signing vs encryption

They solve different problems:

  • Signing — every message carries an HMAC keyed from the session. Protects integrity and authenticity: an on-path attacker can't tamper with requests or inject them (defeats NTLM relay to SMB). Does not hide the data. Cheap-ish but adds CPU and latency.
  • Encryption (SMB3) — AES-GCM/CCM over the whole session. Protects confidentiality too. Slightly more expensive; worth it for anything crossing an untrusted segment or WAN.

Domain controllers require SMB signing for SYSVOL/NETLOGON by default (that's why Group Policy is tamper-resistant). For file servers:

# Require signing on the server (clients that won't sign are refused)
Set-SmbServerConfiguration -RequireSecuritySignature $true

# Require encryption for a specific share
Set-SmbShare -Name Finance -EncryptData $true
# ...or the whole server
Set-SmbServerConfiguration -EncryptData $true
# Samba
[global]
    server signing = mandatory
[finance]
    smb encrypt = required

Windows 11 24H2 / Server 2025 made SMB signing on by default for all connections — some old NAS devices broke as a result. The fix is to update the NAS, not disable signing.

Hands-on: what did this connection actually use?

# Per-connection: dialect, signing, encryption
Get-SmbConnection | Format-Table ServerName, ShareName, Dialect, Signed, Encrypted

# Server side: who's connected and how
Get-SmbSession | Format-Table ClientComputerName, Dialect, SecureSession
# Linux client (cifs-utils)
mount.cifs //server/share /mnt -o vers=3.1.1,sec=krb5,seal   # seal = encryption
mount | grep cifs                                            # shows vers= actually used
smbclient -L //server -m SMB3

Verification and troubleshooting

  • "You can't connect because SMB1 is disabled" / error 0x80070035 — the target only speaks SMB1 (old NAS, printer). Don't re-enable SMB1 globally; replace the device, or as a last resort isolate it on a segment with no other reason to trust it.
  • Slow large-file copies over WAN — SMB is latency-sensitive. SMB2+ helps with larger I/O and credits, but a chatty antivirus filter or SMB signing on a high-RTT link still hurts. SMB Multichannel (two NICs) and BranchCache are the real fixes; a copy tool that pipelines (robocopy /MT) helps.
  • Intermittent "access denied" that a retry fixes — often Kerberos: clock skew > 5 min, or the client used the IP (forces NTLM) instead of the hostname (allows Kerberos). Connect by FQDN.
  • NTLM relay concerns — require signing everywhere and encryption on sensitive shares; disable NTLM where you can. Signing is the single most effective mitigation.
  • Samba client can't negotiate 3.1.1 — old cifs-utils/kernel. Check cat /proc/fs/cifs/DebugData for the negotiated dialect.
  • Get-SmbConnection shows Dialect 2.0.2 to a modern server — something capped it: a GPO, server max protocol, or a middlebox. 2.0.2 means no encryption is possible.
PrabathStuck on something this site can't fix?Reach out to Prabath directly on LinkedIn.