kerberos票据机制是带有时效、加密绑定、分层授权的动态信任凭证体系，tgt用于向tgs证明初始认证，service ticket用于访问具体服务，authenticator防重放；失败需分层排查：先klist确认票据存在性与有效性，再核对spn、密钥版本（kvno）及加密类型一致性，最后实测curl/hdfs/kafka等调用验证票据真可用性。
kerberos 票据机制不是简单的“登录凭证”，而是一套带有时效、加密绑定、分层授权的动态信任凭证体系。认证失败往往不是某一步出错，而是票据在生成、传递或验证任一环节被破坏或不匹配。排查关键在于分层定位：先确认票据是否存在，再验证它是否有效、是否被正确使用。
票据类型与作用必须分清
很多人混淆 TGT 和 Service Ticket，导致排查方向错误：
- TGT（Ticket Granting Ticket）：由 AS 发放，用 KDC 的 TGS 密钥加密，客户端无法解密内容，仅用于向 TGS 证明“我已通过初始认证”。有效期通常为 10 小时，可续期。
-
Service Ticket（ST）：由 TGS 发放，用目标服务主体（如
host/server.example.com@REALM）的密钥加密，客户端也无法解密，但会将它连同 Authenticator 一起发给服务端。有效期通常为 10 分钟，不可续期。 - Authenticator：客户端每次向服务发起请求时临时生成，含时间戳并用 Client/Server 会话密钥加密，用于防重放。它不被缓存，每次 AP-REQ 都不同。
常见票据类失败现象与直查动作
看到报错别急着改配置，先做三件事：
- 运行
klist -f：检查是否有 TGT；若无，问题在初始认证（kinit 或登录阶段）；若有但无对应 ST，说明 TGS 请求失败或服务名不匹配。 - 运行
klist -e：查看票据使用的加密类型（etype），确认是否与 KDC 支持的加密套件一致（如 AES256-SHA1 vs RC4-HMAC）。不匹配会直接拒绝，且日志中常出现KRB_AP_ERR_BAD_INTEGRITY或ETYPE_NOT_SUPP。 - 检查票据时间戳：
klist输出中的 Start Time、End Time、Renew until。若当前系统时间超出 End Time，票据已过期；若客户端与 KDC 时钟偏差 > 5 分钟，AS-REQ 会被静默拒绝（事件 ID 4，KERB_AP_ERR_SKEW）。
票据验证失败的典型链路断点
Service Ticket 验证失败，核心原因永远落在三个地方：
-
SPN（Service Principal Name）未注册或重复：KDC 查不到
HTTP/web.example.com@REALM，就会返回KDC_ERR_S_PRINCIPAL_UNKNOWN。用setspn -L servername（Windows）或ldapsearch（Linux/AD）确认 SPN 是否存在且唯一。 -
服务密钥不一致：服务端 keytab 中的密钥与 KDC 数据库中该主体的密钥不一致（例如 keytab 未更新、重建后未同步）。可用
ktutil -k /etc/security/keytabs/http.service.keytab list查看版本号（kvno），再对比 KDC 上该 principal 的 kvno（kadmin -p admin/admin@REALM getprinc HTTP/web.example.com@REALM）。 -
票据被篡改或解密失败：服务端尝试用自身密钥解密 ST 失败，可能因传输中损坏、中间设备修改 UDP 包、或客户端与服务端加密协商异常。Wireshark 中抓到
TGS-REP正常发出，但服务端日志报KRB_AP_ERR_MODIFIED，优先检查网络路径是否支持完整 UDP 包（MTU、防火墙分片策略）及两端加密策略一致性。
快速验证票据是否“真可用”
不要只信 klist 显示“有票”，要实测它能否完成一次完整服务访问：
- 对 HTTP 服务：用 curl 携带票据测试
curl --negotiate -u : http://web.example.com - 对 HDFS：执行
hdfs dfs -ls /并观察是否触发 GSSAPI 认证流程，而非回退到简单认证。 - 对 Kafka：启用
sun.security.krb5.debug=true启动客户端，观察日志中是否成功获取并提交了 ST。
