OpenShift环境下Kerberos SSO认证流程异常问题求助

一、Ingress层面请求头校验 #

• 确认Ingress未篡改或丢弃Kerberos相关请求头：Authorization（带Negotiate前缀）、WWW-Authenticate，且客户端Host头必须与SPN中的主机名完全匹配（需为完整FQDN，不能用IP或别名）。OpenShift路由默认会添加X-Forwarded-*系列头，要确保应用能正确识别这些转发头，避免因源IP/主机名不匹配导致票据验证失败。
• 检查Ingress Controller的proxy-body-size配置，若Kerberos票据过大被截断，会引发间歇性验证失败。
• 核对路由TLS配置：HTTPS路由的证书SAN必须包含SPN的主机名，且Kerberos票据中的服务主体名需与路由暴露的FQDN完全一致，大小写也不能有差异。

二、SPN配置与票据传递问题 #

• 用setspn -L <服务账号>检查AD中注册的SPN，必须包含HTTP/<your-openshift-route-fqdn>，且该账号拥有该SPN的所有权，无重复注册（重复SPN是间歇性认证失败的常见诱因）。
• 确认应用已正确配置信任代理（比如Spring Boot需设置server.forward-headers-strategy=native），确保能通过X-Forwarded-*头获取真实客户端信息，而非Ingress Controller的IP。
• 检查Kerberos票据的有效期和续期设置：若票据过期后应用未处理续期逻辑，长时间会话场景下会出现间歇性认证失效。

三、会话与状态处理 #

• 检查应用是否依赖会话Cookie，同时确认Ingress路由的会话亲和性配置：需开启route.spec.sessionAffinity=ClientIP，避免同一用户请求被分发到不同Pod，导致后续授权流程因会话不共享中断。
• 核对Ingress是否修改了Cookie属性（如Secure、HttpOnly、SameSite），若应用期望的Cookie属性被篡改，会导致会话无法正常维持，引发登录流程卡住。

四、间歇性问题定位技巧 #

• 开启Ingress Controller调试日志：比如HAProxy设置logLevel=debug，查看每个请求的头信息是否完整传递，有无异常截断或修改。
• 在应用侧开启Kerberos/SPNEGO详细日志：Java应用可设置sun.security.krb5.debug=true，追踪票据验证全流程，排查是否存在偶发的票据解码失败或主体不匹配情况。
• 抓包分析：在Ingress Controller与应用Pod之间用tcpdump抓包，对比成功/失败请求的Kerberos头、Cookie、会话标识差异，定位间歇性问题的触发条件。

五、应用层授权对接排查 #

• 即便Kerberos认证返回200，也要确认应用是否正确将认证后的用户信息（如SID、UPN）映射到内部角色/权限系统，可在应用日志中输出认证后的用户对象，检查是否存在属性缺失或映射错误。
• 检查应用的授权拦截器逻辑：部分应用在认证通过后需加载用户权限等额外步骤，若这一环节出错，会导致看似认证成功但无法进入系统。

内容的提问来源于stack exchange，提问作者Mert