必须同步配置域策略与域控制器策略并刷新用户密钥：Default Domain Policy中启用AES加密类型并禁用RC4；Default Domain Controllers Policy中在“安全选项”下设相同加密类型；每个用户需重置密码或通过PowerShell设置msDS-SupportedEncryptionTypes为24以生成AES256密钥；客户端须执行klist purge或重启清除旧票据缓存；验证需抓包确认AS-REQ中etype=18。
域控制器上必须同步修改两处GPO策略
只改客户端策略而忽略域控制器策略，会导致登录失败或tgt无法签发。错误现象是用户反复提示“密码错误”或事件日志中出现event id 4768（as-req）失败，且service ticket encryption type字段为空或为0。
需要同时配置：
- Default Domain Policy → 计算机配置 → 安全设置 → 账户策略 → Kerberos策略 →
支持的Kerberos加密类型：勾选AES128_HMAC_SHA1和AES256_HMAC_SHA1，**务必取消勾选RC4_HMAC_MD5等弱算法** - Default Domain Controllers Policy → 计算机配置 → 安全设置 → 本地策略 → 安全选项 →
网络安全性：配置 Kerberos 所允许的加密类型：设为相同值（RC4_HMAC_MD5,AES128_HMAC_SHA1,AES256_HMAC_SHA1）
注意：第二处策略在“安全选项”下，不是“Kerberos策略”，路径极易找错；若仅配置第一处，域控制器自身仍会接受RC4票据，导致客户端启用AES后被拒绝。
每个AD用户账户必须显式启用AES256密钥
Kerberos票据是否能用AES256，最终取决于用户账户是否生成了对应密钥。即使GPO已下发、域功能级别达标，Set-ADAccountControl -SupportedEncryptionTypes AES128,AES256也只设置“能力声明”，不自动生成密钥。
必须执行以下任一操作才能真正生成AES256密钥：
- 用户主动重置一次密码（推荐）：新密码哈希会触发KDC生成AES128和AES256密钥对
- PowerShell批量刷新（适用于服务账户）：
Set-ADUser -Identity "svc_sql" -Replace @{"msDS-SupportedEncryptionTypes"=24}（24 = AES128+AES256） - 使用
ldp.exe手动修改msDS-SupportedEncryptionTypes属性为24，然后强制KDC重建密钥（需重启Netlogon服务）
验证方式：在客户端运行klist tickets，看Encryption Type是否出现aes256-cts-hmac-sha1-96；若仍是rc4-hmac，说明该用户密钥未更新。
客户端生效前必须清除旧票据缓存
GPO策略下发后，已获取的TGT不会自动失效——它仍按旧加密类型续期。常见误判是“配置完就去查klist，发现还是RC4”，其实只是缓存没清。
强制刷新方法：
- 执行
klist purge（管理员权限CMD/PowerShell） - 或运行
net stop kdc && net start kdc（仅限Windows专业版及以上） - 最彻底：重启客户端，确保全新TGT以AES256请求
注意：klist tickets只显示当前缓存票据，不反映策略是否生效；真正生效标志是下次AS-REQ请求中etype字段为18（AES256）——可用Wireshark抓包过滤kerberos && kerberos.etype == 18确认。
非Windows客户端和老旧服务要单独评估兼容性
AES256启用后，以下场景大概率中断，且无法通过GPO降级解决：
- Linux上使用SSSD + krb5.conf未配置
default_tgs_enctypes和default_tkt_enctypes为aes256-cts-hmac-sha1-96 - SQL Server 2012及更早版本连接字符串含
Integrated Security=true时，底层Schannel可能拒绝AES256票据 - 某些Java应用（JDK krb5.conf中显式启用AES256
临时缓解方案只能是：为特定服务账户保留RC4支持（在ADUC中该用户属性→“加密类型”里**只勾选RC4_HMAC_MD5**），但这是安全妥协，应同步推动应用升级。真正的加固完成点，是所有关键服务票据都稳定显示Encryption Type: aes256-cts-hmac-sha1-96且无登录失败事件。
