Microsoft introduced Server Message Block (SMB) version 3.0 with Microsoft Server 2012. This version is more secure and provides many features including SMB failover and scaling out servers. Sometimes, though, you cannot connect from one site to another. This blog will explore why this happens and how to resolve the issue.
What are the signs that there is an issue?
- You observe that two 2012 R2 Servers are not able to access the shares of each other.
- The same servers are able to access the shares of 2008 R2 servers.
In our experience, this pointed us in the direction that the only difference between 2008 R2 and 2012 R2 is the version of SMB that is SMB2 and SMB3 respectively.
You will need to utilize a temporary work-around until time can be coordinated with the firewall vendor to fix it appropriately. You need to create a registry that will disable one of the advanced features of SMB3 (Require Secure Negotiate):
Dword : RequireSecureNegotiate
Value : 0 (Zero)
That key tells SMB to not require secure negotiation so the connection can be established without a signed response. A reboot is recommended.
Once you’re able to determine the underlying issue with the infrastructure that may be preventing SMB3 communication, you should clear up the registry adjustment to take advantage of SMB3.
Why does this occur?
In a nutshell, upon reception of a Tree Connect response, an SMB3-capable client validates the original SMB2 Negotiate request by sending a signed IOCTL, called FSCTL_VALIDATE_NEGOTIATE_INFO. The server needs to reply with a signed response and this enables end-to-end validation of the Negotiate exchange.
The client sends the IOCTL only if it is implemented to request validation of an SMB2 Negotiate via the RequireSecureNegotiate abstract data element.
Down-level servers (pre-Windows 2012) will return STATUS_NOT_SUPPORTED or STATUS_INVALID_DEVICE_REQUEST since they do not allow or implement FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response provided it’s properly signed. For a SMB3-capable server, it is recommended that the server implements FSCTL_VALIDATE_NEGOTIATE_INFO. On the other-hand, when a client establishes an SMB 3.x connection, it MUST go through the FSCTL_VALIDATE_NEGOTIATE_INFO phase, provided RequireSecureNegotiate allows it.
Windows 8 clients and 2012 R2 servers are by default configured for this and to change the behavior we need the registry key RequireSecureNegotiate
To correct the issue properly, use Wireshark or some other packet capture software to see where the blocking of the packets is occurring – on the switch or any firewall or router that may be involved in the network.
You should be looking for the following:
TCP 445 —SMB default port
Dialect: 0x0202 (SMB 2.0.2)
Dialect: 0x0210 (SMB 2.1)
Dialect: 0x0300 (SMB3.0)
Dialect: 0x0302 (SMB3.0.2)
Dialect: 0x0311 (SMB3.1.1)
SMB versioning: https://msdn.microsoft.com/en-us/library/cc246492.aspx
You should see the SMB2 or greater under protocol and then a negotiate and a successful response. The signed response is usually what is not received.
In WireShark you can also create a filter to see any response that is not STATUS_SUCCESS using filter for smb2.net_status > 0xc0000000
Need more information or help in finding the problem? Email email@example.com, we are happy to help!