同一服务器双SQL Server实例的跨服务器客户端双跳认证疑问

这确实是个反直觉的情况，我来帮你梳理几种最可能的原因，解释为什么没配置Kerberos委派还能顺利执行分布式查询：

• 链接服务器实际用的是SQL身份认证
  你提到的“直通身份认证”如果是指使用SQL Server自身的登录账号（而非Windows集成身份认证），那Kerberos委派根本派不上用场。SQL身份认证是在SQL Server内部完成验证的，完全不依赖Windows域的委派机制。你可以用下面的查询检查链接服务器的安全配置：

  SELECT srvname, useself, locallogin, remotelogin 
  FROM sys.sysservers 
  WHERE srvname = '你的链接服务器名称'
  

  如果useself的值是0，说明链接服务器使用的是指定的remotelogin（SQL账号），这种场景下自然不会有身份认证失败的问题。

• 调用服务的运行账号是机器账号，且域内已授权
  如果你的调用服务是用本地系统（Local System）或网络服务（Network Service）账号运行的，它的身份其实是服务器的机器账号（格式为DOMAIN\你的服务服务器名称$）。如果两台SQL服务器在同一个Active Directory域中，且实例B已经给这个机器账号分配了登录权限，那么链接服务器在直通认证时，会直接用这个机器账号访问实例B——域内的机器账号默认是可以完成身份验证的，不需要额外配置SPN或委派。

• 分布式查询并未真正跨实例执行
  有时候看起来是跨实例的查询，但实际目标对象可能是实例A本地的资源，或者链接服务器的配置有误（比如不小心指向了实例A自己）。你可以用EXEC sp_testlinkedserver '你的链接服务器名称'测试链接服务器是否真的指向实例B，同时检查你的查询语句，确认是否真的访问了实例B上的对象。

• 环境中存在隐性的Kerberos配置
  虽然你明确说没有配置SPN和委派信任，但可能存在你不知道的隐性配置：比如域管理员已经为SQL Server实例注册了SPN，或者调用服务所在的服务器被配置了约束性委派。你可以用setspn -L 你的SQL实例B服务器名称命令检查实例B的SPN注册情况，也可以在Active Directory用户和计算机中查看服务服务器的属性，确认是否有委派权限设置。

• 自动 fallback到NTLM认证
  当Kerberos认证无法完成时（比如缺少SPN），SQL Server会自动 fallback到NTLM认证。NTLM是一种挑战-响应式的认证方式，不需要SPN和委派配置，虽然安全性不如Kerberos，但在很多场景下都能正常工作。你可以查看实例B的SQL Server错误日志，查找类似“Login succeeded for user 'DOMAIN\UserName'. Connection made using NTLM authentication.”的记录，确认是否使用了NTLM。

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