服务主体名称（SPN）是 Kerberos 认证体系中用来唯一标识某个服务实例的字符串。在 Windows 活动目录环境里，当客户端尝试通过 Kerberos 协议访问一台服务器上的特定服务时，它会向密钥分发中心（KDC）请求一张服务票据，而 KDC 必须依靠 SPN 来定位该服务所绑定的域账户。如果 SPN 缺失、写错或者被多个账户重复注册，客户端就会 fallback 到 NTLM 甚至直接认证失败。理解 SPN 的构成与注册机制，是排错的第一步。
SPN 的格式规范与自动注册逻辑
一个标准的 SPN 由三部分组成：服务类、主机名以及可选的端口或实例名。例如 MSSQLSvc/sql01.contoso.com:1433 就表示一台名为 sql01 的机器上、1433 端口的 SQL Server 服务。服务类通常由微软或第三方软件预先定义，像 HTTP、MSSQLSvc、ldap 都是常见类型。主机部分必须使用全限定域名（FQDN）或者 NetBIOS 名，但同一个服务往往要同时注册两种形式，否则跨子网客户端可能匹配不到。
当服务进程以本地系统（Local System）或网络服务（Network Service）账户运行时，活动目录会自动以计算机账户（如 CONTOSOSQL01$）注册对应的 SPN，管理员无需干预。但一旦将服务改为域用户账户运行，自动注册就会失效，必须手工维护。很多运维在更换服务账户后忘记补登 SPN，这是 Kerberos 双跳认证断裂的最常见诱因。此外，如果在故障转移群集中承载服务，还应当为群集的虚拟网络名注册 SPN，而不是物理节点名。
重复 SPN 是另一个隐蔽问题。假如两台机器都用本地系统账户提供同名服务，或者手工注册时把同一个 SPN 挂到了不同域账户上，KDC 在收到票据请求时会发现歧义而拒绝签发。通过 setspn -X 可以全域扫描冲突，但这个操作在大型目录里会比较慢，建议在变更前先在单 Ou 范围核查。
使用 setspn 命令完成注册与查看
Windows 自带的 setspn 工具是管理 SPN 的命令行入口，它直接修改活动目录里的 servicePrincipalName 属性。查看某个账户已有的 SPN，可以执行 setspn -L 域名账户名，系统会列出全部绑定项。若要确认某个具体 SPN 落在哪个账户，使用 setspn -Q MSSQLSvc/sql01.contoso.com:1433 即可，而不用遍历所有用户。
添加 SPN 的基本语法是 setspn -S 服务类/主机:端口 域账户。这里的 -S 参数会在添加前先做重复性检查，比老版本的 -A 更安全。举例来说，把 SQL 服务绑定到域账户 svc_sql 的命令如下：
# 为 SQL Server 注册 SPN，使用域用户 svc_sql 运行服务 setspn -S MSSQLSvc/sql01.contoso.com:1433 CONTOSOsvc_sql setspn -S MSSQLSvc/sql01:1433 CONTOSOsvc_sql # 验证注册结果 setspn -L CONTOSOsvc_sql
删除错误条目则用 setspn -D。如果某台旧服务器退役后其 SPN 仍留在目录里，就可能造成新服务器注册同名的冲突，此时应优先清理。对于运行在本地系统账户的服务，若要改为域账户，典型流程是先在被替换账户上删除旧 SPN，再于新账户上加回，最后重启服务让凭证缓存刷新。
在 PowerShell 较新版本中，也可以用 Get-ADUser 配合 Set-ADAccountControl 等模块读写属性，但底层依旧调用同样的目录接口。无论哪种方式，操作账户都需要对目标计算机或用户对象具备写 servicePrincipalName 的权限，域管理员或 delegated 的管理组通常满足要求。
Kerberos 认证失败的典型排错路径
当应用层抛出“登录失败，用户未信任用于委派”或事件日志出现 4769 失败审计时，应当先从客户端抓包或启用 Kerberos 日志。在客户端执行 klist purge 清空票据缓存后重新访问服务，再用 klist 观察是否拿到了对应 SPN 的服务票据。若只看到 TGT 而没有服务票据，说明 KDC 未返回，问题多在 SPN 解析。
事件查看器中，域控制器安全日志的 4769 事件会带错误码。比如 0x7 表示请求加密类型不支持，0x20 常见于 SPN 不存在，0x22 则指向重复 SPN 导致 KDC 无法选定唯一账户。针对 0x20，回到上文的 setspn -Q 确认是否漏登；针对 0x22，用 setspn -X 找出重复项并删除多余绑定。有时服务账户被设为“敏感且无法委派”，也会让双跳场景失败，需要在 Active Directory 用户和计算机控制台里取消该勾选。
还有一种情况是 DNS 解析与 SPN 主机名不一致。客户端依据自己连接的地址构造 SPN，如果连接的是 IP 或别名，而 SPN 只注册了 FQDN，Kerberos 便无法匹配。建议在接入层统一使用 A 记录域名访问，并为别名（CNAME）对应的真实主机补登 SPN。下表列出常见服务与默认端口的 SPN 类：
| 服务 | 服务类 | 默认端口 |
|---|---|---|
| SQL Server | MSSQLSvc | 1433 |
| IIS 网站 | HTTP | 80/443 |
| LDAP | ldap | 389 |
排错时也应检查时间同步，因为 Kerberos 对时钟偏移容忍度仅默认五分钟。如果域成员与 DC 时间相差过大，无论 SPN 多正确都会认证失败。用 w32tm /query /status 确认同步源，必要时强制 w32tm /resync。把 SPN、DNS、时间、委派设置四项结合起来看，绝大多数 Kerberos 登录故障都能在半小时内定位。