Windows Server 2025 / 检查 SMB 签名并测试共享加密

服务器消息块（Server Message Block，SMB）协议的签名用于保护消息完整性，SMB 加密则保护传输内容。共享文件夹连接失败时，应先检查服务器名称、用户身份、协议支持和实际协商结果，再考虑是否需要调整保护设置。

区分签名、加密与权限

已签名的连接不一定已加密；加密网络流量也不会修正过宽的文件权限，更不会自动加密磁盘中保存的文件。SMB 签名专项说明区分了 Windows Server 2025 的出站要求：FS1 访问其他服务器时，本身就是 SMB 客户端。不能据此断定所有服务器角色的入站默认要求相同。组策略对象（GPO）和计算机角色会影响实际配置。NTFS 是 New Technology File System（新技术文件系统），其文件权限与共享权限共同决定可执行的操作。

修改前查询当前要求

在 FS1 上以管理员权限打开 PowerShell，分别查询访问其他服务器的 SMB 客户端，以及提供本机文件的 SMB 服务器。使用SMB 与 NTFS 权限练习中已经可用的 LabRead。先核对实际文件夹路径，并用测试用户读取一个已知文件，建立正常访问的基线。如果共享不存在或初始读取失败，应先解决该问题：

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData

RequireSecuritySignature 表示是否要求签名，并非某个会话的完整保护状态。EncryptData 根据查询对象分别属于服务器或共享；RejectUnencryptedAccess 涉及相应上下文中不支持加密的访问是否被拒绝。本练习不修改这些全局设置。SMB 安全强化概览介绍新增功能；签名的方向要求应结合前面的专项文档与本机实际设置判断。客户端的额外加密要求没有包含在本次选择的列中。

仅为测试共享启用加密

仅在隔离实验环境的 LabRead 上操作，使用有效的域身份并先关闭打开的文件。先执行 $previousEncryption 的赋值，核对得到的布尔值，并在会话之外另行记录，以便窗口关闭后仍可恢复。开启加密后不要重新执行赋值，否则会覆盖原始值。随后逐行执行；若提示确认，应确认目标确为 LabRead，遇到错误则停止，不要继续假定设置成功：

$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData

最后的查询应显示 LabRead 的 EncryptData=True。SMB 加密需要两端都支持；设备声称支持 SMB 3.x，并不代表具备所需的加密能力。保留现有全局策略，包括对未加密访问的拒绝；若实验环境已有例外，导致无法可靠验证，应先检查该例外。保存工作后，仅关闭涉及的客户端连接，再通过正常服务器名称重连。其他应用可能仍维持 FS1 会话，应协调关闭；仅关闭文件资源管理器窗口不能证明连接已重建，也不应无差别断开所有网络驱动器。

在 CLIENT1 上以相同的域身份打开 \\fs1.ad.example.test\LabRead，并读取之前的已知文件。随后在该客户端、打开连接的身份上下文中运行查询；使用其他凭据启动的控制台可能看到不同会话：

Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted

除 ShareName 外，还要检查 ServerName：筛选条件只匹配 LabRead，可能返回多个服务器上的同名共享。fs1.ad.example.test 对应行的 Dialect 应为支持的 SMB 3.x 版本，Encrypted 应为 True。Get-SmbConnection 参考文档说明了连接与用户、凭据的关系。若没有该行，确认确实通过指定路径读取了文件，且查询身份正确。若 Encrypted=False，不能认为加密验证成功，应检查仍保留的旧会话、目标与策略。此查询不显示 Signed 状态。加密成功也不会将只读权限变成写入权限。

区分兼容性与身份验证故障

在域中使用正确的服务器名称，并在适用时使用 Kerberos 身份验证；不要用 IP 地址或任意别名绕过身份问题。对于较旧的网络附加存储（Network Attached Storage，NAS）设备，先检查更新、经过身份验证的账户以及签名和加密支持。无法兼容时，应评估替换或网络隔离。不要为求快速连通而全局关闭签名、启用不安全来宾访问或开启 SMB1。

打开“事件查看器”→“应用程序和服务日志”→“Microsoft”→“Windows”，检查 CLIENT1 上相关的 SMBClient 通道，以及 FS1 上相关的 SMBServer 通道。对照同一失败时间，记录错误代码、完整消息、计算机、共享和账户，但不要公开凭据。结合表格判断：“拒绝访问”可能涉及权限，也可能涉及安全协商，不能只凭这一句确定原因。先将事件与配置对应，再修正一个已确认的条件并重复相同读取。

仅恢复本次测试的变更

比较结束后，在同一个 FS1 PowerShell 会话中恢复已保存的原始值。先确认变量仍保留最初的布尔值；如果变量已丢失，应找回变更前的记录，不要猜测。原本已经加密的共享不能被一律恢复为未加密：

Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption

使用前面的查询再次核对 EncryptData，重新建立 CLIENT1 连接，读取同一文件并检查 Encrypted。原始值为 True 时，恢复后应仍为 True。原始值为 False 时，客户端加密要求或其他策略仍可能让连接保持加密。不要为了强行得到比较结果而放宽全局策略。实际部署还应结合数据敏感程度、兼容性、在该环境中测得的性能和恢复访问途径；本练习不进行性能测试，也不能替代权限检查。