Everything here also applies to Windows 8. These features were first available in the Windows Server “8” Beta & Windows 8 Consumer Preview releases. See this document for protocol level details of these features.

1       Encryption

SMB 3 in Windows Server 2012 adds the capability to make data transfers secure by encrypting data in-flight, to protect against tampering and eavesdropping attacks. The biggest benefit of using SMB Encryption over more general solutions (such as IPSec) is that there are no deployment requirements or costs beyond changing the SMB Server settings.

The encryption algorithm used is AES-CCM, which also provides data integrity validation (signing). See section 5 below for full details about SMB Encryption.

2       Signing

SMB 3 uses a newer algorithm for signing – AES-CMAC instead of the HMAC-SHA256 used by SMB 2.

Both AES-CCM and AES-CMAC can be dramatically accelerated on most modern CPUs with AES instruction support (see this link for general non-Microsoft information on CPU AES acceleration).

3       Secure Dialect Negotiation 

SMB 3 includes a new capability to detect “man in the middle” attempts to downgrade the SMB 2/3 protocol “dialect” or capabilities that the client and server negotiate. When such manipulation is detected by either client or server, the connection will be disconnected and Event ID 1005 will be logged in the Microsoft-Windows-SmbServer/Operational event log. Secure Negotiate cannot detect/prevent downgrades from SMB 2 / 3 to SMB 1, and for this reason we strongly encourage users to disable the SMB 1 server if possible (see section 4 below). This is especially important for certain SMB Encryption deployment scenarios, as discussed in section 5 below.

4       If you don’t need SMB 1, turn it off!

Although the Windows CIFS/SMB 1 Server is a very mature codebase, we would still encourage users who have no need for it to turn it off on their servers, thereby reducing attack surface (SMB 1 supports over 100 protocol commands). The newer and separate SMB 2 server component supports SMB protocol versions 2 and higher, including SMB 3.

If all of your clients are Windows Vista and later, you probably don’t need SMB 1 enabled on your servers.

SMB 2 was first supported in Windows Vista & Windows Server 2008.  Older clients such as Windows 98/ME, Windows 2000, Windows XP and Windows 2003 do not support SMB 2, and will not be able to access file or print shares if the SMB 1 server is disabled.  Some non-Microsoft SMB clients may also be incapable of speaking SMB 2 (e.g. printers with “scan to share” functionality). Computer Browser functionality also requires SMB 1, but the Browser service is disabled by default on Windows Server 2008 R2 and later anyway.

You can discover whether any SMB clients are currently connected to your server using SMB 1 with the following PowerShell command:

Get-SmbSession | Select Dialect,ClientComputerName,ClientUserName | Where-Object {$_.Dialect –lt 2.00}

The SMB 1 server can be disabled with this command:

Set-SmbServerConfiguration –EnableSMB1Protocol $false

If a client connection is rejected because the SMB  1 server is disabled, Event ID 1001 will be logged in the Microsoft-Windows-SmbServer/Operational event log. The rejected client name/IP can be found in the event details.

5       Encryption Details

5.1 Configuration

Using Windows Server 2012, an administrator can enable SMB Encryption for the entire server, or just specific shares. Since there are no other deployment requirements for SMB Encryption, it is an extremely cost-effective way to protect data from snooping and tampering attacks. Administrators can very simply turn it on using either the File Server Manager, or using powershell, as shown below.

Using Powershell

To enable encryption for an individual share, run the following on the server:

          Set-SmbShare –Name <sharename> -EncryptData $true

To create a new share with Encryption turned on:

          New-SmbShare –Name <sharename> -Path <pathname> –EncryptData $true

To enable encryption for the entire server, run the following on the server:

          Set-SmbServerConfiguration –EncryptData $true

Using File Server Manager

1.       Open Server Manager and navigate to File and Storage Services

2.       Click on Shares

3.       Select the share you want to turn encryption on for, and right-click

4.       Select “Properties” from the context menu.

5.       In the Share Properties window, select “Settings”, and enable “Encrypt data access” (see graphic below)

6.       Click OK to close

5.2 Deployment Considerations

By default, once SMB Encryption is turned on for a share or server, only SMB 3 clients will be allowed to access the affected shares. The reason for this restriction is to ensure that the administrator’s intent of safeguarding the data is maintained for all accesses. However there might be situations (for example, a transition period where mixed client OS versions will be in use) where an admin may want to allow unencrypted access for clients not supporting SMB 3. To enable that scenario, run the following powershell command:

Set-SmbServerConfiguration –RejectUnencryptedAccess $false

The Secure Negotiate capability described in section 3 does prevent a “man in the middle” from downgrading a connection from SMB 3 to SMB 2 (which would use unencrypted access); however it does not prevent downgrades to SMB 1 which would also result in unencrypted access.

For this reason, in order to guarantee that SMB 3 capable clients will always use encryption to access encrypted shares, the SMB 1 server must be disabled.

If the –RejectUnencryptedAccess setting is left at its default setting of $true then there is no concern, because only encryption capable SMB 3 clients will be allowed to access the shares (SMB1 clients will also be rejected).

5.3 Implementation Details

A few details important to note from implementation perspective:

1.       SMB Encryption uses the AES-CCM algorithm to encrypt/decrypt the data. Details about key generation can be found in sections 3.1.4.2 and 3.2.5.3 of the protocol document linked at the top of this post. AES-CCM also provides data integrity validation (signing) for encrypted shares regardless of the SMB Signing settings. Of course, if you want to enable just signing without encryption, you can continue doing so as before. See a great blog about SMB Signing here for more details.

2.       In a default configuration (no unencrypted access allowed to encrypted shares), if clients not supporting SMB 3 attempt to access an encrypted share, Event ID 1003 will be logged to the Microsoft-Windows-SmbServer/Operational event log and the client will receive an “access denied” error.

3.       SMB Encryption and NTFS EFS are completely unrelated, and SMB Encryption does not require or depend on using EFS.

5.4 Deployment Scenarios

SMB Encryption should be considered for any scenario in which sensitive data needs to be protected from man-in-the-middle attacks. Here are a couple examples which are relevant:

1.       In a traditional information worker scenario, a lot of sensitive data is being moved over the SMB protocol. SMB Encryption offers an end to end privacy and integrity guarantee between the file server and the client, irrespective of the networks traversed (e.g. WAN links maintained by 3^rd party providers).

2.       The new capabilities offered by SMB 3 in Windows Server 2012 enable file servers to provide continuously available storage for server applications (such as SQL or Hyper-V). This also offers an opportunity to protect that information from snooping attacks by simply enabling SMB Encryption. Compare this with the dedicated hardware solutions required for most SAN networks.