Linked Server双跳Kerberos TCP配置问题求助

我之前帮不少用户踩过Linked Server双跳身份验证的坑，结合你描述的场景——两台全新生产SQL Server，域服务账户运行MSSQLSvc，SPN已注册，单跳正常但双跳失败，咱们一步步来排查解决：

先再确认核心前提（别嫌麻烦，细节容易漏） #

• 虽然你已经验证过SPN，但还是建议用命令再核对一遍：
  运行setspn -L DOMAIN\YourServiceAccount，检查是否包含所有必要格式的SPN：
  • 命名实例：MSSQLSvc/SQLServerName:Port、MSSQLSvc/SQLServerName.FQDN:Port
  • 默认实例：MSSQLSvc/SQLServerName、MSSQLSvc/SQLServerName.FQDN
    缺任何一个都可能导致Kerberos身份验证失败。

双跳失败的关键排查点 #

1. 先确认Kerberos是否真的生效了 #

在两台SQL Server上分别执行这个查询，检查当前连接的身份验证协议：

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

如果返回NTLM，说明Kerberos根本没启动，先回退到SPN注册步骤补全遗漏项；只有返回KERBEROS，才继续往下排查。

2. 调整Linked Server的安全配置 #

打开Linked Server属性的安全性标签页：

• 必须选择使用登录的当前安全上下文（这是身份传递的核心设置）
• 别勾选“针对所有远程登录使用此安全上下文”，那是硬编码账户的场景，不适合双跳身份传递

3. 配置AD中的委派权限 #

这是双跳最容易忽略的环节：

• 计算机对象委派：在AD中找到第一台SQL Server的计算机对象，打开属性→委派标签，选择信任此计算机以委派到指定服务，然后添加第二台SQL Server的MSSQLSvc服务（要包含FQDN和端口两个条目）
• 服务账户委派：同样在AD中找到运行SQL Server的域服务账户，在委派标签选择信任此用户以委派到指定服务，添加两台SQL Server的MSSQLSvc服务

4. 验证身份是否真的传递成功 #

做个简单测试：

1. 用域用户登录客户端机器，连接到第一台SQL Server（SQL1）
2. 执行双跳查询：SELECT * FROM SQL2.YourDB.dbo.YourTable;
3. 立刻在SQL2上执行：SELECT SUSER_SNAME();
   • 如果返回你的客户端域用户，说明身份传递成功；如果返回SQL1的服务账户，说明委派配置有问题

5. 排查环境限制 #

• 确认域控制器和两台SQL Server之间的防火墙没有阻止Kerberos流量（默认端口88）
• 检查域组策略中的Kerberos约束委派规则，是否有设置限制了服务之间的委派行为

兜底的小技巧 #

如果所有配置都没问题但还是失败：

• 重启两台SQL Server服务（SPN注册后有时候需要重启才能生效）
• 在客户端和两台服务器上运行klist purge清除Kerberos缓存，再重新测试

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