全域强制启用AES-256需五环节闭环：域功能级别≥2008、GPO禁用RC4等弱算法并仅启AES128/AES256、AD用户属性勾选AES256且重置密码生成密钥、客户端klist purge清除旧票据、通过klist tickets和事件ID 4769验证加密类型为aes256-cts-hmac-sha1-96及值24。
在全域范围内强制启用aes-256，不是单纯改一个设置就能生效，而是需要域功能基础、策略配置、账户属性、密钥刷新和验证闭环五个环节全部到位。缺一不可，否则会出现“看似启用却仍走rc4”的假象。
确认全域环境满足最低门槛
这是前提，跳过会导致后续全部失效：
- 域功能级别必须 ≥ Windows Server 2008（建议升级至2012 R2或更高）；
- 所有域控制器运行Windows Server 2008及以上版本；
- 客户端操作系统为Windows Vista / Server 2008或更新系统（XP、Win7 SP0等不支持AES-256）；
- 非Windows客户端（如Linux SSSD、macOS旧版本）需单独评估兼容性，部分需服务端保留RC4支持——但这会削弱全域强度，应避免。
通过组策略统一约束Kerberos加密类型
仅靠用户属性不够，必须用GPO从策略层切断弱算法路径：
- 编辑Default Domain Policy（或新建专用GPO并链接到域根）；
- 路径：计算机配置 → 策略 → 安全设置 → 账户策略 → Kerberos策略；
- 将“支持的Kerberos加密类型”设为仅包含：AES128_HMAC_SHA1, AES256_HMAC_SHA1；
- 务必取消勾选RC4_HMAC_MD5、DES_CBC_CRC等所有弱类型；
- 策略下发后，客户端需执行klist purge清除旧票据，或重启生效——缓存中的RC4票据不会自动作废。
批量激活每个账户的AES-256密钥能力
Kerberos票据是否能用AES-256，最终取决于用户账户是否生成并存储了对应密钥：
- 在ADUC中逐个打开用户属性 → “账户”选项卡 → “加密类型” → 勾选AES256_HMAC_SHA1（建议同时勾选AES128以兼顾新老客户端）；
- 批量操作推荐PowerShell：
Set-ADUser -Identity "username" -SupportedEncryptionTypes AES128,AES256； - 关键细节：用户密码未重置前，AD可能仍沿用旧密码派生的RC4密钥；强制用户修改一次密码，才能确保AES密钥被完整生成并写入目录。
验证是否真正落地生效
不能只看策略是否配置，要查票据和日志双证据：
- 客户端执行klist tickets，检查每张TGT和服务票据的Encryption Type字段是否显示aes256-cts-hmac-sha1-96；
- 在域控制器上查看安全日志，筛选Event ID 4769（服务票据发放），确认Service Ticket Encryption Type值为24（AES256专属代码）；
- 若发现某应用登录失败，先检查其客户端是否为老旧Java环境（未装JCE无限制策略）或嵌入式设备（硬编码RC4），这类情况需单独适配，而非降级全域策略。
