To protect against SMB session hijacking, NT supports a cryptographic integrity mechanism, SMB Signing, to prevent active network taps from interjecting themselves into an already established session. See KB Q161372. Caution: packet signing will introduce a 10%-15% performance hit and to be effective, workstations and servers need to be configured for SMB signing.

Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
Name: EnableSecuritySignature
Type: REG_DWORD
Value: 1

Key: SYSTEM\CurrentControlSet\Services\Rdr\Parameters
Name: RequireSecuritySignature
Type: REG_DWORD
Value: 0

If you set RequireSecuritySignature=1 on servers, the registry setting ensures that the Server communicates with only those clients that are support message signing. BEWARE: older clients will fail to connect to servers that have this key configured. Similarly, the clients with RequireSecuritySignature set will not be able to connect to servers which do not have message signing support. A little looser but more reasonable approach is to set RequireSecuritySignature=0 and EnableSecuritySignature=1. Then if both ends of the converstation have been configured for SMB Signing, it will work and if one or the other is not configured, communication can still occur. Setting RequireSecuritySignature=1 on either the server or workstation is for environments with quite sensitive data as a rule.

The need for SMB signing has become less theoretical with the release of the hacker tool SmbRelay which automates a man-in-the-middle attack against the SMB protocol.

See also Q199714 - Cannot Join Domain Because of SMB Signing .