微软计划于 4 月份对其身份认证体系的核心——Kerberos 协议的加密协商逻辑进行重大调整。这次变更并非简单的补丁更新，而是通过改变默认加密优先级，强制推动域环境从不安全的 RC4 迁移至 AES 体系。
{#section path-to-node="4"}
1. 技术本质：加密套件（Cipher Suites）的强制升级
在 Windows 域环境中，Kerberos 服务票据（Service Tickets）的加密类型由 KDC（域控制器）根据服务账号的属性决定。
-
当前逻辑（Legacy Logic）： 如果服务主体名称（SPN）对应的账号未显式启用 AES 支持，KDC 为了兼容性，会默认回退（Fallback）至 RC4-HMAC (Type 0x17)。
-
4 月更新后（New Logic）： KDC 将不再默认回退。即便账号未配置 AES，系统也会默认尝试使用 AES-128 (Type 0x11) 或 AES-256 (Type 0x12) 进行加密协商。
{#section-1 path-to-node="7"}
2. 潜在风险：为何会发生认证失败？
当 KDC 强制发出 AES 加密的票据，而应用服务端（如旧版 SQL Server、Java 应用或未经配置的 Linux Samba 服务）仅持有 RC4 的 Session Key 时，解密将宣告失败。
核心受损点：
-
Session Key 不匹配： 只有在
msds-SupportedEncryptionTypes属性中明确列出 RC4，系统才会支持 RC4 会话密钥。 -
Kerberoasting 防御： 此次变更本质上是微软在底层削弱 RC4 的生存空间，从而提升域环境抵御 Kerberoasting 离线爆破攻击的能力。
{#section-2 path-to-node="12"}
3. 三种应对策略的底层逻辑
-
盲目乐观（Hope）： 维持现状。补丁分发后，不支持 AES 的旧设备将直接抛出
KDC_ERR_ETYPE_NOSUPPORT错误，导致业务停摆。 -
紧急规避（Panic）： 通过组策略（GPO）或手动修改属性强制指定回退到 RC4。这虽然能暂时恢复业务，但会让域环境持续暴露在已知安全漏洞中。
-
精准治理（Know）： 提前审计。通过分析域控日志（Event ID 4769）筛选所有加密类型为
0x17的请求，并手动为这些账号开启 AES 128/256 支持。
{#section-3 path-to-node="15"}
4. 官方参考与文档链接
建议所有系统管理员和安全工程师阅读微软官方关于 Kerberos 加密变更的详细公告，以获取受影响的 CVE 编号及具体配置参数：
- 微软官方支持文档（KB5020276）：
https://support.microsoft.com/help/5020276
- 关于 Kerberos 加密类型的详细说明：
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769
LeisureLinux 深度建议： 在生产环境部署 4 月补丁前，请务必使用 PowerShell 检查
msds-SupportedEncryptionTypes属性值。如果该值为0或null，该账号将直接触发新的 AES 默认逻辑。
