目标主体名称不正确。无法生成 SSPI 上下文（SQL 或 AD 问题）？

Question

昨晚我们停电了，当服务器恢复时，我们的域用户无法访问我们的 SQL Server 2000 实例名称：MASSQL。

我们可以使用 SQL 身份验证进行访问。

1. 我们尝试确保运行该服务的用户具有 SSPI 读写权限
2. 我们尝试创建一个新用户
3. 我们尝试使用 NETWORK SERVICE 帐户运行该服务
4. 我们尝试以本地系统帐户运行
5. 我们尝试创建一个新的域管理员帐户并作为新的域管理员帐户运行服务

我还针对有问题的 SQL Server 实例运行了以下命令：

setspn -L xsql2

结果

已注册 CN=MASSQL、CN=Computers、DC=ABC、DC=com 的 ServicePrincipalNames：
        主机/MASSQL
        主机/MASSQL.ABC.COM

我对一个没有问题的 SQL 实例运行了以下命令：

setspn -L xensql1

结果

注册 CN=XENSQL1、CN=Computers、DC=ABC、DC=com 的 ServicePrincipalNames：
        WSMAN/XENSQL1
        WSMAN/XENSQL1.ABC.com
        受限KrbHost/XENSQL1
        主机/XENSQL1
        受限KrbHost/XENSQL1.ABC.COM
        主机/XENSQL1.ABC.COM

看来无问题实例的结果有更多数据。我不知道这是否与一个是2000年，另一个是2012年有关。

可能发生了什么？如何允许域用户再次登录？

Answer 1

SQL Server SPN 不是在计算机帐户本身上设置的，而是在运行 SQL Server 的帐户上设置的。如果服务帐户没有创建 SPN 的权限，则需要为 SQL Server 服务创建两个 SPN。以下示例假设使用默认端口 1433。

SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"
SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>:1433" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"

请参阅为 Kerberos 连接注册服务主体名称

要检查它们是否已经存在：

SetSPN -L ServiceAccountName

然而，你似乎可能遇到了更大的问题。如果您将 SQL Server 配置为使用域管理员帐户运行，则它应该具有创建 SPN 的权限。