必须客户端和服务器两端同时启用“对通信进行数字签名（始终）”策略，即客户端侧配置“Microsoft网络客户端：对通信进行数字签名（始终）”，服务器侧配置“Microsoft网络服务器：对通信进行数字签名（始终）”，二者缺一不可，否则连接失败或退回到无签名状态，无法防止中间人劫持。
要真正增强内网 smb 共享传输安全性，关键不是“开启签名”，而是让客户端和服务器两端都强制要求签名。只开一边等于没开——连接会失败，或退回到无签名状态，起不到防护作用。
必须同步配置的两个策略
这两项设置缺一不可，且需在所有参与共享通信的设备（包括工作站、文件服务器、域控制器）上统一启用：
- 客户端侧（出站强制）：计算机配置 → 管理模板 → 网络 → Lanman 工作站 → “Microsoft 网络客户端：对通信进行数字签名（始终）” → 启用
- 服务器侧（入站强制）：计算机配置 → 管理模板 → 网络 → Lanman 服务器 → “Microsoft 网络服务器：对通信进行数字签名（始终）” → 启用
验证是否生效的快捷方式
策略应用后无需重启，运行 gpupdate /force 刷新即可。快速确认实际连接状态：
- 在访问共享的客户端上执行：
Get-SmbConnection | fl *, Signing—— 查看 Signing 字段是否为 True - 在共享所在的服务器上执行：
Get-SmbSession | fl *, Signing—— 同样确认 Signing 为 True
兼容性与常见避坑点
不是所有设备都支持强制签名，部署前需注意：
- Windows XP、部分老旧 NAS（如早期群晖/威联通）、某些网络打印机默认不支持 SMB 签名，连接将直接拒绝
- 域环境中，普通成员服务器和工作站默认不启用服务器端签名，仅域控制器默认启用，这点常被忽略
- 若环境含非 Windows 设备（如 Linux Samba 服务），需确认其 SMB2/SMB3 配置支持 HMAC-SHA-256 或 AES-CMAC 签名算法
- 性能影响真实存在但可控：现代 CPU 上通常仅增加 3–5% CPU 开销，千兆局域网下文件吞吐下降不明显
进阶加固建议
签名是基础防线，配合以下措施可形成纵深防护：
- 禁用 SMBv1（
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force），杜绝古老漏洞面 - 启用 SMB 加密（
Set-SmbServerConfiguration -EncryptData $true -RejectUnencryptedAccess $true），防流量嗅探 - 优先使用 Kerberos 认证而非 NTLM，确保会话密钥强度足够支撑签名运算
- 避免通过 IP 地址或 CNAME 访问共享，使用真实主机名，保障 Kerberos SPN 正确解析
