Kerberos加密类型配置核心是客户端、服务端与KDC支持的算法必须匹配，否则报“KDC不支持请求的加密类型”等错误；关键配置包括krb5.conf中的default_tkt_enctypes、default_tgs_enctypes和permitted_enctypes，需与KDC的supported_enctypes、账户msDS-SupportedEncryptionTypes属性及keytab中实际密钥类型一致，并确保底层系统和库支持对应算法。
kerberos 认证中加密类型配置，核心是让客户端、服务端与 kdc 在票据生成和解密时使用彼此都支持的算法。不匹配就会报错，比如 “kdc 不支持请求的加密类型” 或 err_etype_nosupp。关键不在“加多少种”，而在“对得上”。
krb5.conf 中三个关键配置项
Linux 客户端的 /etc/krb5.conf（Windows 是 krb5.ini）里，这三个参数决定客户端“想用什么”和“能用什么”：
-
default_tkt_enctypes：申请 TGT（票据授予票）时首选的加密类型，按从高到低排序。例如
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac - default_tgs_enctypes：向 TGS 请求服务票据（ST）时使用的加密类型，通常与上一项一致
- permitted_enctypes：客户端允许接受的所有加密类型列表（含前向加密），必须包含服务端实际提供的类型，否则票据无法解密
三者顺序要合理——优先级高的放前面，但 permitted_enctypes 必须覆盖所有可能用到的类型，哪怕只是备用。
服务端（KDC 或 AD）必须实际支持这些类型
客户端配得再全也没用，如果 KDC 或 Active Directory 没启用对应算法，请求直接被拒。
- 在 Windows 域环境中，检查账户的 msDS-SupportedEncryptionTypes 属性（可用 ADSI Edit 或 PowerShell 查看），它决定了该用户/计算机能用哪些加密方式
- 通过组策略 网络安全：配置 Kerberos 允许的加密类型 可批量控制域内所有机器支持的算法范围
- KDC（如 MIT KDC）需在 kdc.conf 中配置
supported_enctypes，并确保密钥数据库已为各主体生成对应密钥
keytab 文件必须包含匹配的密钥
服务端用 keytab 解密票据，而 keytab 不是“自动兼容”的——它只包含创建时明确指定的加密类型密钥。
- 用
kadmin addprinc -e添加主体时，必须显式列出所需加密类型，例如：addprinc -e "aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac" HTTP/host@REALM - 用
ktutil手动写入 keytab 时，每条add_entry都要指定-e参数和对应加密类型 - 可用
klist -k -t service.keytab查看 keytab 中实际包含哪些加密类型的密钥条目
操作系统与库支持是底层前提
即使配置和 keytab 都对，若系统缺少对应加密库，也会失败。
- Linux 上确认
krb5-workstation或libkrb5包支持 AES 和 RC4（较新发行版默认含 AES，旧系统可能需手动启用或升级） - Windows Server 2008 R2 及以后默认支持 AES128/AES256；更早版本需补丁或注册表启用
- Java 应用需注意 JCE 策略文件限制（旧 JDK 默认禁用 AES256），必要时替换 unlimited policy 或升级 JDK
