跨域SQL Server连接：Host2无法使用Kerberos认证的解决方法

环境配置与问题现象 #

• SQL Server部署在xyz.com域的服务器上
• Host1归属xyz.com域，通过SSMS连接SQL Server时Kerberos认证正常
• Host2归属abc.com域，该域与xyz.com域为双向信任关系，但Host2通过SSMS连接SQL Server时默认采用NTLM而非Kerberos认证
• SQL Server端点的DNS A记录为sqlserver-instance.differentdomain.com，已在xyz.com域完成服务主体名称(SPN)MSSQLSvc/sqlserver-instance.differentdomain.com的注册

核心解决方案（保留现有端点） #

要让Host2通过Kerberos认证连接目标SQL Server，需解决跨域SPN的信任与解析问题，具体操作步骤如下：

1. 验证域信任的Kerberos协议支持
   • 在xyz.com和abc.com的域控制器中，通过Active Directory Domains and Trusts检查双向信任属性，确认"Kerberos AES 128"、"Kerberos AES 256"等Kerberos相关选项已勾选（默认双向信任已启用，但需确认无配置异常）。
2. 配置SPN跨域访问权限
   • 在xyz.com域中，将注册SPN的SQL Server运行账户添加到abc.com域的Allowed to Authenticate组；或者在该服务账户的属性中配置Allowed to Authenticate From，将abc.com域的计算机或用户对象纳入允许范围。
3. 调整Host2的DNS与Kerberos缓存
   • 在Host2的网卡TCP/IP设置中，将differentdomain.com添加到DNS搜索列表，确保DNS能正确解析sqlserver-instance.differentdomain.com到SQL Server的IP地址。
   • 执行命令klist purge清除Host2本地的Kerberos缓存，重启SSMS后重新测试连接。
4. 确认SPN注册有效性
   • 在xyz.com域控制器上执行setspn -L <SQL服务账户名>，确认MSSQLSvc/sqlserver-instance.differentdomain.com（若SQL Server使用非默认1433端口，需同时确认带端口的SPN已注册）存在且正确。
   • 在Host2上执行setspn -Q MSSQLSvc/sqlserver-instance.differentdomain.com，验证跨域环境下能正常查询到该SPN（查询成功依赖域信任正常）。

关于Java Kerberos配置指南的适用性 #

你提到的Java应用Kerberos配置指南仅适用于Java环境，它依赖Java专属的krb5.conf配置文件和JDBC驱动的Kerberos实现逻辑，无法直接应用于SSMS这类Windows原生客户端场景。Windows原生客户端的Kerberos认证依赖Active Directory的域内配置和本地系统安全策略，与Java的Kerberos实现路径完全不同。

替代方案 #

若上述配置无法生效，可尝试以下方案：

• 在abc.com域中注册相同的SPN MSSQLSvc/sqlserver-instance.differentdomain.com，指向xyz.com域的SQL Server服务账户（需域管理员权限，且需确保该SPN在整个森林中无冲突）。
• 在Host2的C:\Windows\System32\drivers\etc\hosts文件中添加sqlserver-instance.differentdomain.com的IP映射，同时配置Host2本地Kerberos策略，允许对该端点发起Kerberos认证请求。

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