一次 Windows 11 24H2 强制 SMB 签名导致老旧 NAS 与共享设备无法访问的排查实录

Thu, 09 Jul 2026 07:00:00 +0000

一、问题背景

公司办公网长期以文件服务器（一台群晖 NAS）作为部门共享盘，同时多台网络扫描仪通过 SMB 把扫描件直接推送到共享目录。内网绝大多数终端还是 Windows 10，访问一直正常。近期采购的一批新笔记本出厂预装 Windows 11 24H2，IT 按标准镜像部署后下发到行政、财务等部门。上午刚交付，行政部就反馈：几台新笔记本在资源管理器输入 \\nas\share 直接报错打不开共享，而隔壁老电脑一切正常；与此同时，二楼的旧网络扫描仪把扫描件推到 NAS 时也开始失败。由于当天有合同扫描归档的硬性 deadline，这是一个需要尽快闭环的高优先级故障。

二、故障现象

新装 Windows 11 24H2 终端的具体表现：

资源管理器地址栏输入 \\192.168.10.20\行政共享 后弹出错误：“你不能访问此共享，因为它不安全……” 或 “Unspecified error (0x80004005)”，部分机器提示需要 SMB 签名。
用命令行 net use \\nas\share 连接，返回 “System error 1240 / 要求的 SMB 签名未协商”。
同网段的 Windows 10 电脑访问完全正常，说明 NAS 本身在服务、权限、网络层面没有宕。
二楼那台服役多年的网络扫描仪，SMB 推送任务日志持续报错 “connection refused / authentication failed”，扫描件堆积在本地缓存。
事件查看器 → Windows 日志 → 系统中出现 SmbClient 相关事件，提示客户端要求的安全特性（签名）未被对端满足。

现象指向一个结论：旧系统正常、新系统异常，且异常集中在“签名/安全协商”环节，基本可以锁定是客户端协议策略变化，而非 NAS 宕机或网络不通。

三、排查过程

第 1 步：界定范围，排除基础网络。 先 ping nas 通、Test-NetConnection 192.168.10.20 -Port 445 端口开放，证明 TCP 与网络层没问题；再在 Win10 上同一路径秒开，进一步排除 NAS 共享权限与账号问题。故障被收敛到“Win11 24H2 客户端 ↔ SMB 安全协商”这一段。

第 2 步：拿到精确错误码。 在问题机器上执行：

1
2
3

net use \\192.168.10.20\行政共享 /user:domain\admin ********
# 返回：System error 1240 has occurred.
#       要求的 SMB 签名未协商。

错误码 1240 在微软文档里对应的正是 “The account is not authorized to log in from this station” 的签名/安全变体——客户端要求签名，但服务端握手时没带签名，客户端于是拒绝。

第 3 步：核对客户端 SMB 安全配置。 用 PowerShell 查看本机 SMB 客户端要求：

`1`	`Get-SmbClientConfiguration \| Select-Object RequireSecuritySignature, EnableSecuritySignature, RequireEncryption`

输出显示 RequireSecuritySignature = True。回忆微软的发布说明：Windows 11 24H2 起，SMB 客户端签名（SMB signing）默认从“协商”升级为“强制（always）”，同时进一步收紧不安全的来宾/匿名访问，SMB1 也默认关闭。这正是与老系统（Win10 默认“协商/可选”）行为分叉的点。

第 4 步：确认对端能力。 登录群晖 DSM，查看控制面板 → 文件服务 → SMB → 高级设置，发现该机型固件较旧，“允许 SMB 签名”未勾选，且最高协商到 SMB3 但签名能力未启用；而那台旧扫描仪固件更老，仅实现到 SMB1/SMB2 且根本不支持签名。于是握手过程变成：Win11 客户端坚持“必须签名” ↔ NAS/扫描仪“不签名或不会签名” → 客户端主动中断，共享打不开。

第 5 步：抓包佐证。 在问题机器 Wireshark 抓 tcp.port==445，可以看到 Negotiate Protocol Response 里 SecurityMode 字段没有 SMB2_NEGOTIZE_SIGNING_REQUIRED 的对应能力，而客户端在 Session Setup 时设置了 SIGNING_REQUIRED，随后服务端返回 STATUS_ACCESS_DENIED，连接被拒。到这里根因已经坐实。

四、解决方案

分“治本”和“临时兼容”两条线处理，当天先止血、再排期根治。

方案 A（治本，优先）：在对端启用 SMB 签名。

群晖 NAS：控制面板 → 文件服务 → SMB → 高级设置 → 勾选 “允许 SMB 签名”（建议顺带升级到支持 SMB3 签名的较新 DSM 固件），保存后 Win11 24H2 立刻能正常挂载。
旧扫描仪：联系厂商升级固件到支持 SMB3 + 签名 的版本；若设备已 EOL 无法升级，则改用 FTP/SFTP 推送扫描件到一台支持签名的专用中转服务器，再同步进 NAS。

方案 B（临时兼容，仅限紧急）：在 Win11 客户端放宽签名要求。

# 不推荐长期使用，会削弱安全性
Set-SmbClientConfiguration -RequireSecuritySignature $false -Confirm:$false
# 或通过组策略：计算机配置→Windows 设置→安全设置→本地策略→安全选项
# “Microsoft 网络客户端：对通信进行数字签名(始终)” 设为 已禁用

注意：方案 B 只是给老设备“续命”，正确做法是推动对端支持签名，而不是让新系统退回不安全状态。

方案 C（长效机制）：用 GPO 统一全司 SMB 基线。 在域控上新建一条策略，明确 服务端 + 客户端均启用 SMB 签名，下发到所有终端，避免逐台手工配置、避免以后再有机器“不一致”。

当天先对 NAS 开启签名（5 分钟生效）恢复共享，扫描仪走 SFTP 中转应急，行政部合同归档 deadline 解除。

五、根因分析

根因是协议安全基线的单向演进：微软在 Windows 11 24H2 把 SMB 客户端签名由“协商可选”改为“强制开启”，目的是抵御 SMB 中继/MitM 类攻击；而内网里大量老旧 NAS 固件、嵌入式扫描仪仍停留在“不支持或未启用签名”的旧实现。当强制签名的客户端遇到不签名的对端，握手被客户端主动拒绝，表现为“共享打不开、扫描推不上去”。这不是网络故障，也不是账号故障，而是安全能力错配——新标准的客户端拒绝与不达标老设备对话。

六、预防措施

采购准入：新购 NAS、网络扫描仪、打印机等带 SMB 功能的设备，合同中明确必须支持 SMB3 与 SMB 签名，杜绝 EOL 老固件入网。
存量治理：盘点内网所有提供/消费 SMB 的设备，升级固件到支持签名的版本；无法升级的老旧嵌入式设备，迁移到 SFTP/FTP 或专用网关。
统一策略：通过域 GPO 固化“服务端+客户端均启用 SMB 签名”的基线，让安全配置一致、可审计，而不是靠每台机器“碰运气”。
变更预演：微软每次 Windows 功能版本（如 24H2）上线前，先在隔离测试环境跑一遍“共享访问、打印、扫描推送”等关键路径，提前暴露协议兼容性坑。
监控告警：对 NAS 的 SMB 协商失败日志做采集，配合 401/1240 类错误做早期预警，避免等到业务部门大面积报错才被动响应。

七、总结

Windows 11 24H2 强制 SMB 签名本身是正确的安全加固，但它把“对内网老旧设备兼容性”的账一次性结清了。这次故障的教训是：协议安全基线的演进速度，往往快于嵌入式设备的固件更新节奏。排查时抓住“旧系统正常、新系统异常 + 错误码 1240 + RequireSecuritySignature=True”这三条线索，就能快速定位到签名握手失败，而不是在权限、网络、账号上白绕圈。治本之道永远是在对端补齐签名能力，而不是让新客户端退回不安全状态。

Windows 11 on Zero Day Notes