1. 从一次票据请求失败说起：Kerberos 报错为什么总让人一头雾水
如果你在运维或后端开发岗位上待过一段时间，大概率遇到过这样的场景：服务突然大面积不可用，日志里刷出一片KRB_AP_ERR_SKEW、KRB_AP_ERR_MODIFIED或者Server not found in Kerberos database，而你盯着这些十六进制错误码，完全不知道从哪下手。Kerberos 这套认证协议的设计哲学是"从不轻易告诉你哪里错了"——出于安全考虑，它把大量失败原因统一收敛成几个模糊的错误码，这就导致排查难度陡增。
我自己第一次接触 Kerberos 是在一个跨平台文件共享项目里，当时客户端挂载共享目录时一直报KRB_AP_ERR_MODIFIED，我花了整整两天才定位到根因是 SPN 注册重复。从那以后我养成了一个习惯：把每次遇到的 Kerberos 错误、排查路径、最终根因都记录下来，慢慢积累成了一套自己的排查手册。这篇内容就是把这些年踩过的坑、总结的方法论系统性地梳理出来，覆盖最常见的十几类 Kerberos 错误，从错误码含义、根因分析到具体修复步骤，尽量做到拿来就能用。
这篇文章适合谁看？如果你正在搭建或维护依赖 Kerberos 认证的服务（比如 Hadoop 生态、NFS、数据库集成认证、Web 应用的 SSO 等），或者你只是被某个 Kerberos 报错卡住了想快速找到方向，那这篇内容应该能帮到你。我不会堆砌 RFC 原文，而是用实际排查的思路来讲——先看现象，再猜原因，然后验证，最后修复。
2. 先搞懂 Kerberos 认证的完整链路，报错才有方向感
2.1 三阶段交互：AS、TGS、AP 各自负责什么
很多人排查 Kerberos 错误效率低，根本原因是对认证流程没有清晰的画面感。Kerberos 的认证过程可以拆成三个阶段，每个阶段都有明确的参与方和产出物：
第一阶段：AS Exchange（认证服务交换）。客户端向 KDC 的 AS 组件发送自己的身份信息，KDC 验证通过后返回一个 TGT（Ticket Granting Ticket）和一个用客户端密钥加密的 Session Key。这个阶段的核心是"证明你是你说的那个人"。如果这一步失败，通常意味着客户端密钥不对、账户被禁用或者时间偏差过大。
第二阶段：TGS Exchange（票据授予服务交换）。客户端拿着 TGT 去向 KDC 的 TGS 组件申请访问某个具体服务的票据。TGS 验证 TGT 有效后，返回一个 Service Ticket 和一个新的 Session Key。这一步的核心是"证明你有权访问那个服务"。失败通常意味着 SPN 没注册、TGT 过期或者权限不足。
第三阶段：AP Exchange（应用访问交换）。客户端拿着 Service Ticket 去访问目标服务，服务端解密票据验证身份。这一步的核心是"服务端确认你的票据是真的"。失败往往意味着密钥版本不匹配、加密类型不兼容或者票据被篡改。
理解这三个阶段之后，你看到任何 Kerberos 错误码，第一件事就是判断它发生在哪个阶段。KRB_AP_ERR_*系列基本都在第三阶段，KRB_ERR_*系列可能在第一或第二阶段，KDC_ERR_*系列则明确是 KDC 侧的问题。这个分类能帮你快速缩小排查范围。
2.2 票据缓存：看不见但极其关键的中间态
Kerberos 客户端在拿到 TGT 之后，会把它缓存在本地，后续申请 Service Ticket 时直接复用，不需要重新输入密码。这个缓存就是Credential Cache（凭证缓存），在 Linux 上通常是一个文件（比如/tmp/krb5cc_1000），在 Windows 上则是内存中的 LSA 缓存。
票据缓存出问题是很多"诡异现象"的根源。比如你明明用kinit成功获取了票据，但服务还是报认证失败——很可能是因为服务进程读取的缓存路径和你kinit时写入的路径不一致。再比如你切换了用户但没有清理旧缓存，导致新用户复用了旧用户的 TGT，出现身份错乱。
排查缓存问题的常用命令是klist，它会列出当前缓存中的所有票据，包括 TGT 和 Service Ticket，以及它们的过期时间、加密类型和标志位。养成"遇到认证问题先klist一下"的习惯，能省掉大量瞎猜的时间。
2.3 加密类型协商：最容易被忽视的兼容性陷阱
Kerberos 支持多种加密类型（Encryption Type），常见的有aes256-cts-hmac-sha1-96、aes128-cts-hmac-sha1-96、rc4-hmac等。客户端和服务端（以及 KDC）需要在加密类型上达成一致，否则票据无法解密。
现实环境中最常见的问题是：老系统只支持rc4-hmac，新系统默认禁用了rc4-hmac，两边一碰就报KRB_AP_ERR_MODIFIED或者KDC_ERR_ETYPE_NOSUPP。这种问题的隐蔽性在于，它不会在认证一开始就暴露，而是在票据解密阶段才失败，错误信息往往指向"票据被篡改"，让人误以为是安全问题。
解决思路是统一加密类型策略。你可以在krb5.conf中通过default_tgs_enctypes、default_tkt_enctypes、permitted_enctypes等参数控制客户端支持的加密类型，在 KDC 侧通过kdc.conf的supported_enctypes控制服务端支持的加密类型。关键是两边要有交集，且优先级要合理。
3. 高频错误码逐个拆解：从现象到根因的完整排查路径
3.1 KRB_AP_ERR_SKEW：时间同步这个老生常谈的坑
KRB_AP_ERR_SKEW是出现频率最高的 Kerberos 错误之一，直译过来就是"时钟偏差"。Kerberos 协议默认允许客户端和服务端之间的时间偏差不超过 5 分钟（300 秒），超过这个阈值就会拒绝认证。这个设计的目的是防止重放攻击——如果票据没有时间窗口限制，攻击者截获票据后可以无限期使用。
排查这个错误的第一步是确认偏差到底有多大。在客户端和服务端分别执行date命令，对比两者的时间差。如果确实超过 5 分钟，那就需要同步时间。Linux 上通常用chronyd或ntpd来同步，Windows 上则依赖域控制器的 W32Time 服务。
但这里有个容易踩的坑：时间同步了，Kerberos 还是报 SKEW。这种情况通常有两个原因。一是同步没有真正生效，chronyd可能因为网络问题没有连上时间源，你以为同步了其实没有。二是虚拟化环境下的时钟漂移，虚拟机在负载高的时候时钟会跑偏，即使刚同步过，过一会儿又偏了。对于虚拟化环境，建议开启宿主机的时钟同步透传，或者在虚拟机内配置更频繁的同步间隔。
还有一个隐蔽的情况：KDC 和客户端时间都准，但中间有防火墙做了时间相关的拦截。这种情况比较少见，但如果前面几种可能都排除了，可以检查一下网络设备是否有异常的时间策略。
实操建议：在
krb5.conf中可以把clockskew参数适当调大（比如 600 秒），作为临时缓解手段。但这只是权宜之计，根本解决还是要保证时间同步可靠。
3.2 KRB_AP_ERR_MODIFIED：最容易被误判的错误
KRB_AP_ERR_MODIFIED的字面意思是"票据被修改"，听起来像是安全问题，但实际上绝大多数情况下它跟攻击没有关系。这个错误的本质是：服务端用自己认为正确的密钥去解密票据，但解密失败或者解密后的内容校验不通过。
导致这个错误的常见原因有以下几种：
第一种：SPN 注册重复。同一个 SPN 被注册到了多个账户上，KDC 在签发票据时用了账户 A 的密钥，但服务端实际运行在账户 B 的身份下，用 B 的密钥去解密 A 的票据，自然失败。这种情况在多台机器共用同一个服务名时特别常见。排查方法是检查 KDC 上该 SPN 的注册情况，确保一个 SPN 只对应一个账户。
第二种：密钥版本不匹配。Kerberos 的密钥是有版本号的（kvno），当账户密码变更时，kvno 会递增。如果服务端的 keytab 文件没有及时更新，里面还是旧版本的密钥，而 KDC 已经用新密钥签发票据了，就会解密失败。排查方法是对比 KDC 上账户的当前 kvno 和 keytab 中的 kvno 是否一致。
第三种：加密类型不匹配。前面提到过，如果客户端和服务端支持的加密类型没有交集，也会报这个错误。排查方法是检查klist -e输出的票据加密类型，以及服务端 keytab 中包含的加密类型。
第四种：DNS 解析问题。Kerberos 对主机名非常敏感，如果客户端解析到的主机名和服务端注册的 SPN 不一致，票据里的服务名就对不上。这种情况在有多张网卡或者 DNS 配置混乱的环境里很常见。
排查KRB_AP_ERR_MODIFIED的推荐顺序是：先确认 SPN 唯一性，再检查 kvno 一致性，然后核对加密类型，最后排查 DNS。这个顺序是从最常见到最罕见排列的，能帮你最快定位问题。
3.3 Server not found in Kerberos database：SPN 缺失或写错
这个错误信息很直白：KDC 在数据库里找不到你请求的服务主体（Service Principal Name）。原因通常有两个：要么 SPN 根本没注册，要么你请求的 SPN 名称写错了。
SPN 的格式是service/hostname@REALM，比如HTTP/web.example.com@EXAMPLE.COM。任何一个部分写错都会导致找不到。常见的错误包括：大小写不一致（Kerberos 对大小写敏感）、主机名用了 IP 而不是 FQDN、Realm 名称拼错等。
排查方法是先用kinit获取管理员票据，然后用kadmin的list_principals命令列出所有主体，搜索你需要的 SPN 是否存在。如果不存在，用addprinc添加；如果存在但名称不对，用delprinc删除后重新添加正确的。
这里有个经验：在添加 SPN 之前，先用ktutil或kadmin的ktadd命令生成 keytab，确保密钥正确导出。很多人在添加 SPN 后忘记导出 keytab，或者导出的 keytab 没有包含所有需要的加密类型，导致后续认证仍然失败。
3.4 KDC_ERR_PREAUTH_FAILED：密码错误还是配置问题
KDC_ERR_PREAUTH_FAILED通常被理解为"密码错误"，但它出现的原因不止于此。预认证（Pre-authentication）是 Kerberos 的一个安全增强机制，客户端在请求 TGT 之前，需要先用自己密钥加密一个时间戳发给 KDC 验证。如果这个验证失败，就会报这个错误。
除了密码真的错了之外，还有几种情况会导致预认证失败：
- 账户被锁定或禁用：多次密码错误后账户可能被锁定，或者管理员手动禁用了账户。
- 加密类型不匹配：客户端用来加密时间戳的加密类型，KDC 不支持。
- 时钟偏差：虽然通常报 SKEW，但在某些实现中预认证阶段的时间戳校验失败也会报 PREAUTH_FAILED。
- keytab 中的密钥过期：如果用 keytab 做认证，keytab 里的密钥和 KDC 上的不一致。
排查时先用kinit -V开启详细输出，看看具体卡在哪一步。如果确认密码没问题，就检查账户状态和加密类型配置。
3.5 KRB_AP_ERR_TKT_EXPIRED 与 KRB_AP_ERR_TKT_NYV：票据生命周期问题
这两个错误分别对应票据过期和票据尚未生效。KRB_AP_ERR_TKT_EXPIRED说明票据的结束时间已经过了，KRB_AP_ERR_TKT_NYV说明票据的开始时间还没到。
票据过期是正常现象，重新kinit获取新票据即可。但如果票据频繁过期，就需要检查票据的生命周期配置。Kerberos 票据的生命周期由 KDC 的max_life参数和客户端的ticket_lifetime参数共同决定，取两者中较小的值。默认通常是 10 小时或 24 小时。
KRB_AP_ERR_TKT_NYV比较少见，通常发生在客户端和服务端时间不同步的情况下——客户端的"现在"还没到票据的生效时间。这本质上还是时间同步问题，解决思路和 SKEW 一样。
对于需要长时间运行的服务，建议配置票据自动续期（renewable ticket）。在krb5.conf中设置renew_lifetime，然后定期执行kinit -R来续期。注意续期也有上限，不能无限续下去，超过max_renewable_life后必须重新认证。
4. 配置层面的隐形杀手：那些不报错但让认证失败的因素
4.1 krb5.conf 的常见配置陷阱
krb5.conf是 Kerberos 客户端的核心配置文件，很多认证问题根源都在这里。以下是我在实际项目中遇到最多的几个配置陷阱：
Realm 名称大小写不一致。Kerberos 的 Realm 名称约定是全部大写，但配置文件里如果写成小写，某些实现会不认。更隐蔽的是，[realms]段的键名和[domain_realm]段的值必须完全一致，否则域名到 Realm 的映射会失败。
KDC 地址配置错误。[realms]段里的kdc参数指定 KDC 的地址，可以写主机名也可以写 IP。如果写主机名，需要确保 DNS 能正确解析；如果写 IP，要确保 KDC 确实监听在那个地址上。多 KDC 环境下，可以配置多个kdc条目实现冗余。
dns_lookup_kdc和dns_lookup_realm的取舍。这两个参数控制是否通过 DNS 的 SRV 记录来发现 KDC 和 Realm。开启的好处是配置简单，坏处是依赖 DNS 的可靠性，而且排查问题时多了一层不确定性。在生产环境里，我通常建议显式配置 KDC 地址，把dns_lookup_kdc设为false，减少变量。
default_ccache_name的路径问题。这个参数决定票据缓存的存储位置。默认值通常是FILE:/tmp/krb5cc_%{uid}，但在某些系统上可能不同。如果服务进程运行在不同的用户下，或者有自定义的缓存路径，就容易出现"票据明明有但读不到"的情况。
4.2 keytab 文件的权限与内容校验
keytab 文件是服务端用来解密票据的密钥存储文件，它的正确性直接决定认证能否成功。以下是我总结的 keytab 检查清单：
| 检查项 | 检查方法 | 常见问题 |
|---|---|---|
| 文件权限 | ls -l查看 | 权限过宽（如 644）导致安全告警，或过窄导致服务无法读取 |
| 主体名称 | klist -k查看 | 主体名称与 SPN 不一致，或 Realm 拼写错误 |
| 密钥版本 | klist -k查看 kvno | kvno 与 KDC 上不一致，通常是密码变更后未重新导出 |
| 加密类型 | klist -k -e查看 | 缺少服务端需要的加密类型，如只有 rc4 没有 aes |
| 文件完整性 | file命令查看类型 | 文件损坏或格式不对，可能是传输过程中被破坏 |
导出 keytab 的推荐做法是用kadmin的ktadd命令，并显式指定需要的加密类型。比如：
kadmin -q "ktadd -k /etc/krb5.keytab -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 HTTP/web.example.com"这样能确保 keytab 中包含正确的加密类型，避免后续因为加密类型不匹配导致的认证失败。
4.3 DNS 与 SPN 的对应关系：一个字母都不能错
Kerberos 对名称的精确性要求极高，DNS 解析结果和 SPN 注册名称必须完全对应。我遇到过好几次这样的情况：客户端用web.example.com访问服务，但 SPN 注册的是web01.example.com，虽然这两个名字指向同一台机器，但 Kerberos 不认，直接报Server not found in Kerberos database。
解决这个问题的关键是统一命名规范。在服务部署时，明确服务对外暴露的主机名，然后严格按照这个主机名注册 SPN。如果服务有多个别名，要么为每个别名都注册 SPN，要么在客户端配置[domain_realm]做映射。
另一个常见问题是反向 DNS 解析不一致。Kerberos 在某些场景下会做反向解析来验证服务身份，如果正向解析和反向解析的结果不一致，可能导致认证失败。排查方法是用dig -x检查反向解析结果，确保和正向解析一致。
5. 跨平台场景下的 Kerberos 兼容性问题
5.1 Linux 与 Windows 互操作时的典型故障
在混合环境中，Linux 客户端访问 Windows 域服务（或者反过来）是最容易出问题的场景。以下是我遇到最多的几类故障：
加密类型协商失败。Windows 域控制器默认支持的加密类型和 Linux 客户端默认支持的往往不一致。Windows 较新版本默认启用 AES，但可能仍保留 RC4 兼容；Linux 发行版则可能默认禁用 RC4。两边如果没有交集，认证直接失败。解决方案是在krb5.conf中显式配置permitted_enctypes，包含双方都支持的类型。
SPN 注册方式差异。Windows 环境下，SPN 通常通过setspn命令注册，而且和计算机账户或用户账户绑定。Linux 环境下，SPN 通过kadmin注册。如果同一个服务在两边都有注册，容易出现重复 SPN 的问题。排查时需要在 Windows 侧用setspn -L列出所有 SPN，在 Linux 侧用kadmin的list_principals列出，对比是否有冲突。
票据缓存格式不兼容。Windows 使用 LSA 缓存，Linux 使用文件缓存，两者格式不同。在跨平台场景下，不能直接共享票据缓存，需要各自独立获取票据。
5.2 容器化环境中的 Kerberos 认证挑战
容器化给 Kerberos 认证带来了新的挑战。容器通常是短生命周期的，而 Kerberos 票据有有效期，这就产生了矛盾。常见的解决方案有几种：
方案一：在容器启动时获取票据。通过 init 容器或者启动脚本执行kinit，把票据写入容器内的缓存文件。缺点是票据过期后容器内的服务会认证失败，需要配合续期机制。
方案二：挂载宿主机的票据缓存。把宿主机的/tmp/krb5cc_*文件挂载到容器内，容器直接复用宿主机的票据。缺点是容器和宿主机的 UID 必须一致，否则缓存文件名对不上。
方案三：使用 keytab 做无密码认证。把 keytab 文件挂载到容器内，服务启动时用kinit -kt获取票据。这是生产环境最推荐的方式，因为 keytab 可以长期有效，不依赖人工输入密码。
不管用哪种方案，都要注意容器内的时间同步问题。容器默认使用宿主机时间，但如果宿主机时间不准，容器内的 Kerberos 认证同样会失败。
5.3 多 Realm 信任关系下的排查要点
在大型组织里，往往存在多个 Kerberos Realm，它们之间通过信任关系（Trust）实现跨域认证。跨域认证出问题时，排查链路会更长，因为涉及两个 KDC 的交互。
排查跨域问题的第一步是确认信任关系是否正常。在 KDC 上用kadmin的list_principals查看是否有krbtgt/OTHER.REALM@REALM形式的主体，这是跨域信任的关键。如果没有，说明信任关系没建立。
第二步是确认跨域票据能否正常获取。用kinit -f获取可转发的 TGT，然后尝试访问对方 Realm 的服务。如果失败，用KRB5_TRACE环境变量开启详细日志，看看卡在哪一步。
第三步是检查两个 Realm 的加密类型和票据生命周期配置是否兼容。跨域票据的生命周期取两个 Realm 配置的较小值，如果一边配置得很短，可能导致票据频繁过期。
6. 一套可复用的 Kerberos 排错方法论
6.1 从日志入手：KRB5_TRACE 的正确用法
很多人排查 Kerberos 问题时只看应用层的错误信息，这是远远不够的。Kerberos 库本身提供了详细的调试日志，通过设置KRB5_TRACE环境变量就能开启。比如：
export KRB5_TRACE=/dev/stderr kinit user@EXAMPLE.COM这样会把 Kerberos 库内部的每一步操作都打印出来，包括向哪个 KDC 发了什么请求、收到了什么响应、用了什么加密类型等。这些信息对于定位问题至关重要。
我通常会把KRB5_TRACE的输出重定向到文件，然后逐行分析。重点关注几个关键节点：AS 请求是否成功、TGS 请求是否成功、票据的加密类型是什么、KDC 返回的错误码是什么。有了这些信息，再结合前面讲的错误码含义，基本能定位到根因。
6.2 分层排查法：客户端、KDC、服务端逐层验证
我总结了一套分层排查法，把 Kerberos 认证涉及的三个角色分开验证，避免混在一起排查导致思路混乱。
第一层：客户端验证。在客户端执行kinit获取 TGT，如果这一步就失败，问题在客户端或 KDC。检查客户端的krb5.conf、时间同步、DNS 解析、账户密码。
第二层：KDC 验证。如果kinit成功但申请 Service Ticket 失败，问题在 KDC 或 SPN 配置。用kadmin检查 SPN 是否存在、kvno 是否正确、账户是否被禁用。
第三层：服务端验证。如果 Service Ticket 能拿到但服务端认证失败，问题在服务端的 keytab 或配置。检查 keytab 的权限、内容、加密类型，以及服务端的krb5.conf配置。
每一层验证通过后再进入下一层，这样能快速定位问题所在的环节，避免在无关的地方浪费时间。
6.3 常见问题速查表与修复命令
为了方便快速查阅，我把最常见的 Kerberos 错误、根因和修复命令整理成一张表：
| 错误码 | 最可能根因 | 快速修复命令 |
|---|---|---|
| KRB_AP_ERR_SKEW | 时间偏差超过 5 分钟 | chronyc makestep或ntpdate强制同步 |
| KRB_AP_ERR_MODIFIED | SPN 重复或 kvno 不匹配 | kadmin -q "ktadd -k ..."重新导出 keytab |
| Server not found | SPN 未注册或名称错误 | kadmin -q "addprinc -randkey service/host@REALM" |
| KDC_ERR_PREAUTH_FAILED | 密码错误或账户锁定 | 检查账户状态，重置密码 |
| KRB_AP_ERR_TKT_EXPIRED | 票据过期 | kinit重新获取或kinit -R续期 |
| KDC_ERR_ETYPE_NOSUPP | 加密类型不兼容 | 在krb5.conf中配置permitted_enctypes |
| Client not found | 客户端主体未注册 | kadmin -q "addprinc user@REALM" |
这张表覆盖了日常运维中 80% 以上的场景。遇到问题时先查表，能快速找到方向，然后再深入排查细节。
6.4 预防胜于治疗：日常巡检清单
与其等出问题再排查，不如平时做好巡检。以下是我建议纳入日常运维的 Kerberos 巡检项：
- 时间同步状态：每天检查客户端和 KDC 的时间偏差，确保在 1 分钟以内。
- 票据有效期：监控关键服务的票据剩余有效期，提前续期避免过期。
- keytab 版本：定期对比 keytab 中的 kvno 和 KDC 上的 kvno，确保一致。
- SPN 唯一性：定期扫描 SPN 注册情况，发现重复及时清理。
- 加密类型兼容性：在升级系统或变更配置后，验证加密类型协商是否正常。
- 日志监控：对 Kerberos 相关日志设置告警，出现认证失败时及时通知。
这些巡检项看起来琐碎，但能帮你把大部分问题消灭在萌芽阶段。我在实际项目中坚持做这些巡检后，Kerberos 相关的紧急故障至少减少了七成。
7. 几个真实排查案例的复盘
7.1 案例一：Hadoop 集群大规模认证失败
某次一个 Hadoop 集群突然出现大面积任务失败，日志里全是KRB_AP_ERR_MODIFIED。排查过程如下：
首先确认时间同步正常，排除 SKEW。然后检查 SPN 注册，发现yarn/host1@REALM这个 SPN 被注册到了两个不同的账户上——一个是集群部署时创建的，另一个是后来运维人员手动添加的。KDC 签发票据时用了其中一个账户的密钥，但 NodeManager 服务用的是另一个账户的 keytab，导致解密失败。
修复方法是删除重复的 SPN，只保留正确的那个，然后重新导出 keytab 并分发到所有节点。重启服务后恢复正常。
这个案例的教训是：SPN 注册必须集中管理，禁止手动随意添加。后来我们建立了一个 SPN 注册审批流程，所有 SPN 的增删改都要经过审核，类似问题再没出现过。
7.2 案例二：跨域访问时的加密类型协商失败
另一个案例是跨 Realm 访问时，客户端能拿到跨域 TGT，但申请对方 Realm 的 Service Ticket 时报KDC_ERR_ETYPE_NOSUPP。排查发现，本地 Realm 的 KDC 配置的supported_enctypes包含aes256-cts，但对方 Realm 的 KDC 只支持rc4-hmac，两边没有交集。
解决方案是在本地 Realm 的 KDC 配置中临时加入rc4-hmac支持，同时推动对方 Realm 升级加密类型。在过渡期间，通过配置permitted_enctypes确保客户端能协商出双方都支持的类型。
这个案例说明，跨域场景下的加密类型兼容性需要提前规划，不能等到出问题才处理。在建立信任关系之前，就应该确认双方的加密类型策略是否兼容。
7.3 案例三：容器环境下的票据缓存路径问题
还有一个比较典型的容器场景问题：服务在容器内运行，kinit也成功了，但服务访问后端时仍然报认证失败。排查发现，kinit是在容器的 shell 里执行的，票据写到了/tmp/krb5cc_0，但服务进程是以另一个用户身份运行的，它读取的缓存路径是/tmp/krb5cc_1000，两者不一致。
解决方案是在容器启动脚本中显式设置KRB5CCNAME环境变量，指定统一的缓存路径，并确保服务进程有权限读取该文件。或者在启动服务前用kinit -c指定缓存路径重新获取票据。
这个案例的教训是：容器环境下的环境变量和文件权限需要特别关注，不能假设和传统环境一样。
8. 写在最后：一些个人体会
Kerberos 这套协议设计得很精妙，但它的错误处理机制对运维人员确实不够友好。我的经验是，排查 Kerberos 问题最重要的不是记住所有错误码，而是建立起一套系统的排查思路——先判断问题发生在哪个阶段，再逐层验证，最后定位根因。
另外，日志是你的朋友。KRB5_TRACE加上 KDC 侧的服务端日志，基本能还原整个认证过程的每一步。很多人排查时只看应用报错，忽略了底层库的详细日志，这是很可惜的。
最后分享一个小技巧：如果你经常需要排查 Kerberos 问题，建议在测试环境搭建一套完整的 KDC + 客户端 + 服务端环境，把各种错误场景都复现一遍。亲手制造过错误，再遇到时就能一眼认出来。我在自己的测试环境里模拟过十几种常见错误，这个投入在后来的实际运维中回报巨大。
