Partager via

What’s new in SMB 3.1.1 in the Windows Server 2016 Technical Preview 2

  • Article

 

1. Introduction

Every new version of Windows brings updates to our main remote file protocol, known as SMB (Server Message Block).

If you’re not familiar with it, you can find some information in this previous blog post: Windows Server 2012 R2: Which version of the SMB protocol (SMB 1.0, SMB 2.0, SMB 2.1, SMB 3.0 or SMB 3.02) are you using?

In this blog post, you’ll see what changed with the new version of SMB that comes with the Windows 10 Insider Preview released in late April 2015 and the Windows Server 2016 Technical Preview 2 released in early May 2015.

2. Protocols Changes in SMB 3.1.1

This section covers changes in SMB 3.1.1 related to the protocol itself.

The Protocol Preview document fully describes these changes: [MS-SMB2-Diff]- Server Message Block (SMB) Protocol Versions 2 and 3, but you can see the highlights below.

2.1. Pre-Authentication Integrity

Pre-authentication integrity provides improved protection from a man-in-the-middle attacker tampering with SMB’s connection establishment and authentication messages.

Pre-Auth integrity verifies all the “negotiate” and “session setup” exchanges used by SMB with a strong cryptographic hash (SHA-512).

If your client and your server establish an SMB 3.1.1 session, you can be sure that no one has tampered with the connection and session properties.

Using SMB signing on top of an SMB 3.1.1 session protects you from an attacker tampering with any packets.

Using SMB encryption on top of an SMB 3.1.1 session protects you from an attacker tampering with or eavesdropping on any packets.

Although there is a cost to enable SMB signing or SMB encryption, we highly recommend enabling one of them.

Note: While these changes improve overall security, they might interfere with some solutions that rely on modifying SMB network traffic, like certain kinds of WAN accelerators.

2.2. SMB Encryption Improvements

SMB Encryption, introduced with SMB 3.0, used a fixed cryptographic algorithm: AES-128-CCM.

Since then, we have learned that AES-128-GCM performs better in most modern processors.

To take advantage of that, SMB 3.1.1 offers a mechanism to negotiate the crypto algorithm per connection, with options for AES-128-CCM and AES-128-GCM.

We made AES-128-GCM the default for new Windows versions, while older versions will continue to use AES-128-CCM.

With this flexible infrastructure for negotiation in place, we could add more algorithms in the future.

We observed that moving from AES-128-CCM to AES-128-GCM showed a 2x improvement in certain scenarios, like copying large files over an encrypted SMB connection.

2.3. Cluster Dialect Fencing

Provides support for cluster rolling upgrade for Scale-Out File Servers. For details, see https://technet.microsoft.com/en-us/library/dn765474.aspx#BKMK_RollingUpgrade

In this new scenario, a single SMB server appears to support different maximum dialects of SMB, depending on whether the SMB client is accessing clustered or non-clustered file shares.

For local, non-clustered file shares, the server offers up to 3.1.1 during dialect negotiation.

For clustered shares, if the cluster is in mixed mode (before upgrading the cluster functional level), it will offer up to 3.0.2 during dialect negotiation.

After you upgrade the cluster functional level, it then offers all clients the new 3.1.1 dialect.

3. Other SMB changes that are not protocol-related

There are other changes in Windows that change the SMB Client or SMB Server implementation, but not the protocol itself.

Here are a few important changes in that category:

3.1. Removing RequireSecureNegotiate setting

In previous versions of SMB, we introduced “Secure Negotiate”, where the SMB client and server verify integrity of the SMB negotiate request and response messages.

Because some third-party implementations of SMB did not correctly perform this negotiation, we introduced a switch to disable “Secure Negotiate”. We explain this in more detail in this blog post.

Since we have learned via our SMB PlugFests that third parties have fixed their implementations, we are removing the option to bypass “Secure Negotiate” and SMB always performs negotiate validation if the connection’s dialect is 2.x.x or 3.0.x.

Note 1: For SMB 3.1.1 clients and servers, the new Pre-Authentication Integrity feature (described in item 2.1 above) supersedes “Secure Negotiate” with many advantages.

Note 2: With the new release, any third party SMB 2.x.x or SMB 3.0.x implementations that do not implement “Secure Negotiate” will be unable to connect to Windows.

Note 3: While this change improves overall security, it might interfere with some solutions that rely on modifying SMB network traffic, like certain kinds of WAN accelerators.

3.2. Dialects with non-zero revision number now reported with the x.y.z notation

As you probably noticed throughout this blog post, we’re using 3 separate digits to notate the version of SMB.

In the past, you might have seen us talk about SMB 3.02. Now we call that SMB 3.0.2.

Note that there is no change when the revision number is 0, like SMB 2.1 or SMB 3.0 (we don’t call them SMB 2.1.0 or SMB 3.0.0).

This new format avoids confusion when comparing SMB dialects and better represents the actual version information used by SMB.

You can use the Get-SmbConnection cmdlet on the Windows SMB client to report the currently used SMB dialects.

4. Which protocol is negotiated?

Please note that SMB clients and SMB servers negotiate the SMB dialect that they will use based on each side’s offer.

Here’s a table to help you understand what version you will end up using, depending on what Windows version is running as the SMB client and what version of Windows is running as the SMB server:

 

OS

Windows 10WS* 2016 TP2

Windows 8.1 WS* 2012 R2

Windows 8 WS* 2012

Windows 7 WS* 2008 R2

Windows Vista WS* 2008

Previous versions

Windows 10WS* 2016 TP2

SMB 3.1.1

SMB 3.0.2

SMB 3.0

SMB 2.1

SMB 2.0.2

SMB 1.x

Windows 8.1 WS* 2012 R2

SMB 3.0.2

SMB 3.0.2

SMB 3.0

SMB 2.1

SMB 2.0.2

SMB 1.x

Windows 8 WS* 2012

SMB 3.0

SMB 3.0

SMB 3.0

SMB 2.1

SMB 2.0.2

SMB 1.x

Windows 7 WS* 2008 R2

SMB 2.1

SMB 2.1

SMB 2.1

SMB 2.1

SMB 2.0.2

SMB 1.x

Windows Vista WS* 2008

SMB 2.0.2

SMB 2.0.2

SMB 2.0.2

SMB 2.0.2

SMB 2.0.2

SMB 1.x

Previous versions

SMB 1.x

SMB 1.x

SMB 1.x

SMB 1.x

SMB 1.x

SMB 1.x

* WS = Windows Server

 

Note: Earlier Windows 10 and Windows Server 2016 previews used SMB dialect version 3.1.

5. Considering your options for removing the older SMB1 protocol

When Windows Server 2003 hits the end of its extended support later this year, the last supported version of Windows that only works with SMB1 will be gone.

SMB1 is already a separate component in Windows that you can completely remove. However, up to this point, Windows still enables it by default for compatibility reasons.

The next logical step (which we are planning for a future release of Windows) will be to ship SMB1 disabled by default, but still available if necessary.

To help with this transition, you can now enable auditing of SMB1 traffic in your SMB server using PowerShell. This will alert you via events if any clients are still using SMB1.

To enable auditing of SMB1 traffic, use the cmdlet: Set-SmbServerConfiguration –AuditSmb1Access $true

To view the SMB1 events, use the cmdlet: Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit

If you feel confident that there are no SMB1 clients in your network, you can uninstall SMB1 from your server using the cmdlet: Remove-WindowsFeature FS-SMB1

6. Conclusion

I hope this blog post helps you prepare for the upcoming changes in SMB.

We also recommend that you download the SNIA Tutorial on SMB 3, which we recently updated to include details of the 3.1.1 dialect. You can find a copy of that tutorial at https://www.snia.org/sites/default/files2/DSI2015/presentations/FileSystems/JoseBarreto_SMB3_remote%20file%20protocol.pdf

Comments

  • Anonymous
    May 08, 2015
    Die neue weltweit größte Konferenz für IT Professionals rund um die Technologien von
  • Anonymous
    May 22, 2015
    Comment on: 3.1 Note 3: While this change improves overall security, it might interfere with some solutions that rely on modifying SMB network traffic, like certain WAN accelerators.

    This will cause large enterprises pain when they run across WAN accelerators that have not been upgraded to handle the "Secure Negotiate" in SMB3. The solution now is to disable SN via the registry, but if you remove that option (as per above note), then traffic would not be able to pass.
  • Anonymous
    March 02, 2016
    Awesome blog Jose! :)Do you know if there is any updates to your blog in TP4?
  • Anonymous
    October 02, 2016
    ConfirmerÊtes-vous sûr de vouloir effectuer cette action ?Opération « Modify » en cours sur la cible « SMB Server Configuration ».[O] Oui [T] Oui pour tout [N] Non [U] Non pour tout [S] Suspendre [?] Aide (la valeur par défaut est « O ») : TSet-SmbServerConfiguration : Accès refusé.Au caractère Ligne:1 : 1+ Set-SmbServerConfiguration –AuditSmb1Access $true+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (MSFT_SmbServerConfiguration:ROOT/Microsoft/...erConfiguration) [Set-S mbServerConfiguration], CimException + FullyQualifiedErrorId : Windows System Error 5,Set-SmbServerConfiguration
  • Anonymous
    November 06, 2016
    Hello Jose,A customer was asking me about SMB 3.2, but I'm stumped, does it exist?Could it be the customer meant SMB 3.1.2?Is SMB 3.1.2 in a current release of Windows? (or slated for 2016R2 maybe?)Many thanks,VC
    • Anonymous
      December 12, 2016
      Not aware of any SMB 3.2. They probably mean what comes after 3.1, which is 3.1.1
      • Anonymous
        March 30, 2017
        See paragraph 3.2 above ...they were probably referencing SMB 3.0.2 (previously known as 3.02)
  • Anonymous
    December 20, 2017
    The comment has been removed