AD中UPN变更后Spring Boot应用Kerberos SSO认证失败排查

1. 客户端Kerberos缓存残留旧UPN #

Kerberos认证依赖客户端缓存的票据，AD修改UPN后，客户端本地可能仍保留旧的服务票据或TGT，导致认证时发送旧UPN。

• 排查操作：Windows客户端执行klist purge清空缓存，Linux客户端执行kdestroy，之后重新发起SSO请求；必要时重启客户端机器或Kerberos相关服务。

2. 应用配置硬编码旧UPN或静态映射 #

检查Spring Boot应用的Kerberos与LDAP相关配置，确认是否存在硬编码或静态映射的旧UPN：

• 查看application.properties/application.yml中security.kerberos.service-principal等配置项，是否绑定旧UPN；
• 检查自定义KerberosAuthenticationProvider、UserDetailsService实现，确认是否有固定的用户主体匹配逻辑，而非动态使用认证返回的用户主体。

3. AD用户属性残留旧UPN记录 #

AD修改UPN后，可能存在属性未完全更新的情况：

• 让AD管理员检查用户对象的userPrincipalName属性是否已更新为新值，同时排查servicePrincipalName是否仍关联旧UPN；
• 确认用户的mail等其他属性是否未同步旧UPN，避免应用LDAP查询时误将这些属性作为用户主体查询条件。

4. LDAP查询过滤条件未动态使用认证主体 #

应用通过LDAP查询角色权限时，若过滤条件写死旧UPN，或未正确使用Kerberos认证后的用户主体：

• 检查LdapUserDetailsContextMapper或自定义LDAP查询逻辑，确认是否用Authentication.getName()（即Kerberos返回的当前用户主体）作为LDAP查询的过滤参数；
• 避免硬编码类似(userPrincipalName=JDOE@ABC.COM)的过滤规则，需动态代入认证后的用户主体。

5. Kerberos Keytab文件未更新 #

若应用使用keytab文件进行服务端Kerberos认证，旧keytab是基于旧UPN生成的：

• 重新生成包含新UPN的keytab文件，替换应用中的旧文件；
• 验证keytab有效性：执行kinit -kt <keytab路径> <新UPN>，确认能成功获取Kerberos票据。

6. 域控制器缓存或复制延迟 #

多域控制器环境中，UPN变更可能未同步到所有控制器，或DNS缓存残留旧记录：

• 联系AD管理员刷新域控制器的DNS缓存，等待域内复制完成；
• 临时修改应用LDAP配置，指定已更新UPN的域控制器地址进行测试，排除缓存影响。

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