我们正在部署一个java应用到RHEL 7.5，这个java应用需要连接到SQL Server 2016。作为安全要求，我们必须使用集成安全来连接SQL Server 2016。按照微软网站的建议，我们在Windows AD Server和RHEL 7.5中实现了Kerberos。
不幸的是，我们面临着一个凭证问题，klist命令在RHEL7.5上工作正常，意味着已经安装在RHEL7.5中的Kerberos clinet可以正常与Kerberos Server(Windows AD服务器)对话。而且RHEL7.5可以ping Talnet AD Server和SQL Server。
我们按照微软的规范设置SPN如下。
setspn -A HTTP/[email protected] devdc.local\admin.
按照微软的指导，我们应该使用MSSQLSvc而不是HTTP，但是当我们使用MSSQLSvc的时候出现了问题，我们认为原因是AD服务器的操作系统版本是Windows Server 2012，所以不能支持MSSQLSvc。 改成HTTP后，kerberos工作正常。可以用kinit生成ticket，用klist查看ticket信息。
我们的部分Java代码如下。
System.setProperty("java.security.krb5.conf", "~/krb5.conf");
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("192.168.100.150");
ds.setPortNumber(1234);
ds.setIntegratedSecurity(true);
ds.setAuthenticationScheme("JavaKerberos");
ds.setDatabaseName("DB_TEST");
错误详情如下
错误连接到数据库：(using class com.microsoft.sqlserver.jdbc.SQLServerDriver)GSSException: 没有提供有效的凭证(机制级别：未找到服务器)KrbException: 在Kerberos数据库中找不到服务器(7)KrbException: Identifier doesn't match expected value(906)
如果您能帮助我，我将感激不尽。
你似乎没有设置SPN。 请看
服务主名称(SPN)是客户端用来唯一标识服务实例的名称。
您可以使用serverSpn连接属性指定SPN，或者干脆让驱动程序为您构建它（默认）。这个属性的形式是 "MSSQLSvcfqdn:port@REALM" 其中 fqdn 是完全限定的域名，port 是端口号，REALM 是 SQL Server 的 Kerberos 领域，用大写字母表示。如果您的 Kerberos 配置的默认境界与服务器的境界相同， 则此属性的境界部分是可选的， 默认情况下并不包含。如果您希望支持跨境界的身份验证场景， 即 Kerberos 配置的默认境界与服务器的境界不同， 则必须使用 serverSpn 属性来设置 SPN。
例如， 您的 SPN 可能是这样的 "MSSQLSvcsome-server.zzz.corp.contoso.com:[email protected]"
使用 Kerberos 集成的身份验证来连接到 SQL Server - 服务委托人名称.
驱动程序会尝试从其他连接属性中为你建立SPN，但你得到的是一个IP地址而不是FQDN，所以它无法建立正确的SPN。 在默认配置中，SQL Server会注册自己的SPN，你可以在SQL Server日志中看到正确的SPN，但有些情况下，必须为服务账户注册额外的SPN，这时你需要使用 setspn 命令来查看它们。
假设你的SQL Server是在1234端口监听，并且你没有改变SQL Server实例的服务账户，那么SPNs应该是为机器账户注册的，并且是在 setspn 语句应该是。
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\SERVER_01$
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\SERVER_01$
如果你已经设置了一个域名账户作为服务账户，比如说： devdc\sqlsvc 然后用它来代替。
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\sqlsvc
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\sqlsvc
TLDR使用SQL Server的完全限定域名（FQDN）来设置ServerName()，而不是IP地址。 如果这样还不行， 你就得问问你的网络安全人员为 SQL Server 服务帐户注册了哪些 SPN。 如果你放弃了Kerberos，就退回到NTLM。
另外在较新的JDBC驱动中，微软已经实现了NTLM，也就是我们所说的 其他 Windows认证协议。
但要注意以下安全注意事项。
NTLM协议是一个古老的认证协议，存在各种漏洞，存在安全隐患。它是基于一个相对较弱的加密方案，容易受到各种攻击。它被Kerberos取代了，Kerberos更安全，推荐使用。NTLM认证只能在安全可信的环境中使用，或者在不能使用Kerberos的情况下使用。
Microsoft JDBC Driver for SQL Server只支持NTLM v2，NTLM v2比原来的v1协议有一些安全改进。同时建议启用扩展保护，或者使用SSL加密来提高安全性。