Microsoft 在 Windows message center 里把 Kerberos RC4 加固说得很直，最终部署阶段会移除 Audit mode，只保留 Enforcement mode。域控打完安全更新后，仍依赖 RC4 的账号、服务或旧设备可能直接认证失败。
这类变更最怕被当成普通补丁处理。补丁装上去很快，找出哪个服务账号还在吃 RC4，可能要翻好几轮日志。
先从域控事件日志下手
Microsoft Learn 给出的排查入口是 KDC 上的安全事件日志，重点看 4768 和 4769。这里能看到票据使用的加密类型，也能看到账号支持的加密类型。运维团队要先把这些日志拉出来，按服务账号、计算机账号、来源主机做聚合。
不要只看失败事件。还没失败的 RC4 使用记录更有价值，它们告诉你哪些系统补丁后会出事。很多老系统平时没人碰，一出问题就是业务入口打不开。
服务账号要逐个核对
Active Directory 里最容易留下历史包袱的是服务账号。老应用、旧报表、文件共享、备份软件、打印系统、门禁系统，都可能绑着一个多年没人敢改的账号。账号属性里如果没有明确配置支持的加密类型，域控行为变化后就容易踩坑。
处理时别一口气改全域策略。先列清单，再按业务窗口切。能启用 AES 的账号就补齐属性，不能改的系统要写出原因和替代方案。只写临时例外，不写负责人，过一阵子又会没人认。
旧设备依赖要和业务方确认
Microsoft 文档反复提到 legacy devices，这个词在企业现场很具体。可能是一台老 NAS，可能是一套制造执行系统，也可能是一台供应商远程维护用的旧 Windows 主机。它们不一定归基础架构团队管，但认证失败时，电话会先打到域控管理员那里。
优易云做运维排查时，会把这些依赖拆成三类。能升级的排升级计划，能隔离的放到受控网段，必须保留的写明业务风险和补丁策略。没有业务方签字，基础架构团队别单独背锅。
云文件和混合身份也要一起测
Kerberos RC4 不只影响传统内网应用。使用 AD DS 做身份认证的文件服务、VDI、混合云存储，也可能被带到同一条链路里。Microsoft 针对 Azure Files、FSLogix 等场景都有提醒，说明这不是单一域控参数问题。
测试清单里应该包含登录、挂载文件、读取配置、执行计划任务、服务重启、备份恢复。只测用户登录是不够的。很多服务账号平时没有交互登录，失败会藏在后台任务里。
补丁窗口要留回看时间
域控补丁窗口不要排得太紧。更新前导出账号清单和策略，更新后立刻看 KDC 事件、认证失败、应用日志和帮助台工单。发现问题先定位账号和服务，不要急着回滚整台域控。
更好的做法是先拿一组代表性域控和业务系统做演练。演练里记录命令、事件 ID、负责人、回退条件。真正进入生产窗口时，大家照着 runbook 走，少靠群里临时喊。
把 RC4 清理做成资产治理
RC4 加固不是一次补丁任务，它暴露的是账号和旧系统台账不完整。服务账号没人维护，旧设备没人认领，加密类型没人检查，补丁迟早会把这些问题翻出来。
这次可以顺手建立一条规则。新服务账号必须配置加密类型，旧账号按季度复核，域控事件日志进集中检索，例外项带到期时间。等下一次认证协议收紧时，团队不用重新从黑盒里摸线。
