spn重复是kerberos认证在请求服务票据时静默失败的主因，表现为http 401、sql错误18456等；排查需从客户端错误出发，用setspn -q定位冲突账户，确认spn格式合规并注册到正确账户，最后清理冗余后验证。
spn重复是kerberos认证失败最常见也最容易被忽略的原因之一。它不会阻止用户拿到tgt（登录看起来成功），但会在请求服务票据（st）时静默失败，表现为http 401、sql连接中断、smb访问拒绝或“目标帐户名不正确”等错误。排查核心思路是：**从客户端错误出发，反向定位spn归属，确认唯一性，再清理冗余注册**。
看客户端日志，抓关键错误码
客户端报错是第一线索。重点关注以下信号：
-
Event ID 4 或 21（System 日志）：出现
KDC_ERR_S_PRINCIPAL_UNKNOWN、KDC_ERR_REPEAT或KDC_ERR_PRINCIPAL_NOT_UNIQUE（错误码0x80090322）直接指向SPN问题 - HTTP 401.1 或 401.2：IIS或Web应用返回，尤其在启用Windows集成身份验证后反复弹窗
- SQL Server错误 18456，状态 11 或 12：说明Kerberos票据申请失败，NTLM回退又被策略禁用
-
Wireshark抓包验证：过滤
kerberos && kerberos.sname == "HTTP/app.contoso.com"，若看到多个相同sname的TGS-REQ但KDC持续返回error-code=25（repeat），就是SPN重复的网络层证据
用 setspn -Q 快速定位冲突账户
setspn -Q 是排查的黄金命令——它回答的是“这个SPN被谁注册了？”，而不是“这个账号注册了哪些SPN？”。操作简单，结果明确：
- 在域控制器或有域管理员权限的机器上运行：
setspn -Q HTTP/intranet.contoso.com - 输出会列出所有注册该SPN的账户，例如：
CN=webapp01,CN=Computers,DC=contoso,DC=comCN=webapp02,CN=Computers,DC=contoso,DC=com - 如果返回多行，说明已存在冲突；如果返回“no such SPN found”，则可能是SPN拼写错误、大小写不一致，或根本没注册
检查SPN格式与注册位置是否合规
即使查到唯一注册，也要确认SPN本身是否符合Kerberos匹配逻辑：
-
FQDN必须精确匹配：客户端用
https://app.contoso.com访问，SPN就必须是HTTP/app.contoso.com，不能是HTTP/app（除非同时注册短名）或HTTP/APPCONTOSO.COM（大小写敏感） -
SQL Server需带端口或实例名：如
MSSQLSvc/sql01.contoso.com:1433，省略端口会导致KDC无法匹配 -
必须注册到服务运行账户：比如IIS站点由
CONTOSO\svc-iis运行，SPN就要注册到该用户，而非计算机账户或域管理员 -
避免NetBIOS名注册：注册
HTTP/WEBAPP没用，客户端发的是FQDN请求，KDC不会做自动解析
清理与验证修复效果
确认问题账户后，执行精准清理，再验证：
- 删除冲突项（仅对确认废弃的账户）：
setspn -D HTTP/intranet.contoso.com CONTOSO\oldweb$ - 重新用安全方式注册（推荐
-S）：setspn -S HTTP/intranet.contoso.com CONTOSO\svc-web - 验证是否清除干净：
setspn -Q HTTP/intranet.contoso.com应只返回一行预期账户 - 客户端清空票据缓存：
klist purge（Windows）或rm -f /tmp/krb5cc_*（Linux），然后重试访问
