记一次 Windows 11 24H2 自动设备加密悄然开启导致更换主板后数据无法访问的排查

Tue, 28 Jul 2026 07:00:00 +0800

问题背景

公司今年上半年开始批量采购预装 Windows 11 24H2 的新款商用台式机，替换一批超期服役的老终端。新机器统一走 MDT 半自动部署加域，装机流程沿用了 23H2 时代的模板，没有针对 24H2 做专门评估。

这批机器陆续上线两个多月，一直风平浪静。直到设计部一台工作站主板故障，送修更换主板后开机——问题来了。

需要说明的背景是：我们的域环境只对笔记本强制启用 BitLocker（GPO 下发并托管密钥到 AD），台式机历来不做全盘加密，装机模板里也从未配置过 BitLocker 相关策略。所以我们默认这批台式机是"裸盘"状态。

故障现象

维修商换完主板送回后，机器开机直接进入蓝色的 BitLocker 恢复界面，提示"输入此驱动器的恢复密钥"，并给出一串恢复密钥 ID。

现场同事一脸茫然：这台台式机从没人给它开过 BitLocker。尝试跳过无效，重启若干次依旧卡在恢复界面，系统盘进不去。

更麻烦的是排查过程中的连锁发现：

用户的 Microsoft 账户里查不到密钥——这是台域账号登录的机器，从未绑定过个人 MSA；
AD 用户和计算机 里查看该计算机对象的 BitLocker Recovery 选项卡：空的，AD 里没有托管任何恢复密钥；
随机抽查同批次其他在用台式机，manage-bde -status c: 一看，保护状态全部是"已启用"——整批 24H2 台式机的系统盘不知何时都被加密了，而且没有任何一台的恢复密钥在我们手里。

也就是说：眼前这台是进不去系统，而潜在风险是整批机器只要动一次主板/TPM，就会集体撞上同样的死局。

排查过程

第一步：确认加密从哪来的。

我们从未下发过 BitLocker 策略，先怀疑维修商或用户自己开的。在一台正常的同批次机器上执行：

1
2

manage-bde -status C:
Get-BitLockerVolume C: | fl VolumeStatus,ProtectionStatus,KeyProtector

输出显示 Conversion Status: Fully Encrypted，KeyProtector 里有 Tpm 和 RecoveryPassword 两个保护器。再查事件日志 Microsoft-Windows-BitLocker-API/Management，加密事件的时间戳精确指向装机完成后用户首次登录当天，来源进程是系统自动行为，不是人为操作。

第二步：定位到 24H2 的行为变化。

检索微软文档后确认根源：Windows 11 24H2 大幅放宽了自动设备加密（Automatic Device Encryption）的硬件门槛。24H2 之前，OEM 台式机触发自动加密需要满足 Modern Standby 或 HSTI 等严苛条件，我们的台式机不满足，所以 23H2 批次从未被加密；而 24H2 开始，只要有 TPM 2.0 + UEFI + 安全启动，干净安装后自动加密就默认待命，用户首次以管理员身份登录即完成加密。

注册表可以验证这一点：

`1`	`reg query "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption`

装机模板里没有配置这个键，等于放行。

第三步：搞清楚为什么密钥哪儿都没有。

自动设备加密的设计逻辑是：加密先行，恢复密钥在用户用 MSA/Entra ID 登录时自动上传到对应云端账户。而我们的机器是传统 AD 域账号登录——既不是 MSA 也不是 Entra ID，且我们没有配置"将恢复信息备份到 AD DS"的 GPO（历来只对笔记本 OU 配了），于是密钥生成后只留在本机 TPM 保护的元数据里，任何地方都没有第二份。

主板一换，TPM 随主板走了，PCR 度量全变，密钥链断裂——恢复界面就是唯一出口，而我们拿不出恢复密钥。

第四步：抢救眼前这台机器。

运气不算太差：维修商换主板时旧主板还在。我们让维修商把旧主板装回，机器恢复 TPM 解锁正常进入系统，立刻执行：

1
2

manage-bde -protectors -get C:
manage-bde -protectors -adbackup C: -id {恢复密钥ID}

先把恢复密钥导出留存并托管到 AD，再随维修流程二次换板，凭密钥解锁后 manage-bde -protectors -add 重建 TPM 保护器，数据完好。如果旧主板已被回收销毁，这台机器的数据基本无解。

解决方案

分三步收口：

存量止血：写脚本通过域内推送，对整批 24H2 机器批量执行恢复密钥补托管：

1
2
3

$vol = Get-BitLockerVolume -MountPoint C:
$rp = $vol.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
manage-bde -protectors -adbackup C: -id $rp.KeyProtectorId

配合先行下发 GPO计算机配置→管理模板→Windows组件→BitLocker驱动器加密→操作系统驱动器中启用"选择如何恢复受 BitLocker 保护的操作系统驱动器"，勾选**“将 BitLocker 恢复信息保存到 AD DS"并强制"未成功备份到 AD DS 前不得启用 BitLocker”**。执行后逐台核对 AD 计算机对象的 BitLocker Recovery 选项卡，41 台全部托管成功。

装机模板修正：MDT 任务序列中注入注册表键，从源头禁止自动加密：

`1`	`reg add HKLM\SYSTEM\CurrentControlSet\Control\BitLocker /v PreventDeviceEncryption /t REG_DWORD /d 1 /f`

台式机保持不加密的既有策略；后续如决定台式机也上加密，则走 GPO 受控启用而非放任自动加密。

维修流程加卡点：送修单增加一项强制检查——送修前必须 manage-bde -status 确认加密状态并导出恢复密钥，未确认不得发出。

根因分析

直接原因是 24H2 放宽自动设备加密门槛：TPM 2.0 + UEFI + 安全启动即静默加密，我们的商用台式机第一次够到了门槛。

深层原因有两个叠加：一是装机模板未随系统大版本演进重新评估，23H2 的模板直接套 24H2，默认行为变化没人捕获；二是密钥托管链路与登录体系错配——自动加密假设用户用云账户登录来兜底密钥，而传统 AD 域环境两头落空：云端没有，AD 也没配托管，形成"加密了但密钥无人保管"的最危险状态。

预防措施

大版本上线前过一遍默认行为差异清单：每个 Windows 年度版本进企业前，专项评估安全基线类默认值变化（本次是 BitLocker，24H2 同期还有 SMB 签名强制等），输出适配结论再放行装机。
BitLocker 策略全覆盖：不再按"笔记本才加密"划 OU 配策略，改为全终端 OU 统一下发"恢复信息必须托管 AD DS 且托管成功才允许加密"的 GPO，无论加密由谁触发，密钥必有着落。
例行审计：资产巡检脚本加一项 Get-BitLockerVolume 采集，比对"加密状态=已启用但 AD 无托管密钥"的机器并告警，每月出清单。
维修/报废流程绑定加密检查，防止硬件变更撞上密钥缺失。

总结

这次事故的本质不是 BitLocker 的错，而是系统默认行为变了，管理动作没跟上。24H2 把自动设备加密推向几乎所有 TPM 2.0 机器，对纯云账户的个人用户是无感保护，对传统 AD 域企业却可能是"密钥悬空"的定时炸弹。侥幸在于旧主板还没被销毁，才换回了那台工作站的数据。给同行的提醒就一句：升级 24H2 的域环境，先查 manage-bde -status，再查 AD 里有没有密钥——两件事最好今天就做。

自动设备加密 on Zero Day Notes