kerberos验证_SQL Server中的服务主体名称和Kerberos身份验证概述

kerberos验证

This article gives an overview of Service Principal Name (SPN) for using the Kerberos authentication in SQL Server connections. We use the Kerberos authentication to authenticate windows users securely for providing access to SQL Server.

本文概述了在SQL Server连接中使用Kerberos身份验证的服务主体名称（SPN）。 我们使用Kerberos身份验证来安全地验证Windows用户，以提供对SQL Server的访问。

服务主体名称和Kerberos身份验证SQL Server的介绍 (Introduction of Service Principal Name and Kerberos authentication SQL Server)

Let’s start this article with a scenario that you might have faced in your environment. Suppose you have a SQL Server and its services are running under the local system account. As per the organization requirement, you changed the service account from a local system to a domain account. After the restart of SQL Service, you can connect to SQL Server after taking RDP to the system, but no application users can connect to it. We will understand the solution to this problem in the latter part of this article.

让我们从您在环境中可能遇到的情况开始本文。 假设您有一个SQL Server，并且其服务在本地系统帐户下运行。 根据组织要求，您已将服务帐户从本地系统更改为域帐户。 重新启动SQL Service之后，可以在将RDP引入系统后连接到SQL Server，但是没有应用程序用户可以连接到它。 我们将在本文的后半部分了解该问题的解决方案。

We have two kinds of Server authentication methods in SQL Server.

SQL Server中有两种服务器身份验证方法。

• SQL authentication: We can create a SQL login and provide appropriate rights to that login. SQL Server handles SQL login authentication SQL身份验证：我们可以创建一个SQL登录名并为该登录名提供适当的权限。 SQL Server处理SQL登录身份验证
• Windows authentication: We can use domain accounts to add to SQL Server and connect with the Windows authentication method. SQL Server does not handle the authentication part for a windows login account. It passes the authentication to Windows Security Support Provider Interface (SSPI) which is a component of the operating system Windows身份验证：我们可以使用域帐户添加到SQL Server并使用Windows身份验证方法进行连接。 SQL Server不处理Windows登录帐户的身份验证部分。 它将身份验证传递给Windows安全支持提供程序接口（SSPI），它是操作系统的组成部分

Connect to SQL Server and execute the following query:

连接到SQL Server并执行以下查询：

USE master
GO
 
SELECT distinct auth_scheme FROM sys.dm_exec_connections 
GO

You can see the following results

您可以看到以下结果

• KERBEROS – it shows the connections using the KERBEROS authentication KERBEROS –它显示使用KERBEROS身份验证的连接
• SQL – if the connections are using the SQL authentication, we get auth_scheme SQL SQL –如果连接使用SQL身份验证，我们将获得auth_scheme SQL
• NTLM – it shows the connections using the NTLM authentication NTLM –它显示使用NTLM身份验证的连接

Before we move ahead, let us connect to a SQL Server instance and look at the error logs.

在继续之前，让我们连接到SQL Server实例并查看错误日志。

You will find following logs:

您会发现以下日志：

You can have a high-level overview of the Service Principal Name (SPN) connection process. For a windows user, Kerberos authentication check for valid SPN. In case SPN is not available, it uses the NTLM authentication method.

您可以大致了解服务主体名称（SPN）连接过程。 对于Windows用户，Kerberos身份验证检查有效的SPN。 如果SPN不可用，它将使用NTLM身份验证方法。

SSPI first tries to use the default authentication method (starting from Windows 2000). Kerberos requires SPN for the authentication purpose. If there is no SPN exists, it switches the authentication to the old NTLM process.

SSPI首先尝试使用默认的身份验证方法（从Windows 2000开始）。 Kerberos要求使用SPN进行身份验证。 如果不存在SPN，它将身份验证切换到旧的NTLM进程。

In case SPN exists, but it is not valid, an entry is logged into SQL Server Error logs.

如果SPN存在但无效，则将条目记录到SQL Server错误日志中。

Let’s understand the Service Principal Name (SPN) process in detail.

让我们详细了解服务主体名称（SPN）过程。

• The client machine gets the IP address and fully qualified domain name (FQDN) of SQL Server using forward and reverses lookups
  客户端计算机使用正向和反向查找获取SQL Server的IP地址和完全限定域名（FQDN）
• The client driver generates an SPN in a predefined format. For SQL Server, it uses format MSSQLSvc/FQDN: Port Number
  客户端驱动程序以预定义格式生成SPN。 对于SQL Server，它使用格式MSSQLSvc / FQDN：端口号
• It submits requests to the domain controller with the SPN parameter details. It uses windows API InitializeSecurityContext for this work
  它使用SPN参数详细信息将请求提交到域控制器。 它使用Windows API InitializeSecurityContext进行这项工作
• Domain controller check for the SPN. If valid SPN exists, it issues a token and client machine submit this token to SQL Server for authentication purpose
  域控制器检查SPN。 如果存在有效的SPN，它将发出一个令牌，客户端计算机将此令牌提交给SQL Server进行身份验证。
• SQL Server receives the TDS packet and uses another Windows API AcceptSecurityContext and decrypts the token and contact domain controller to validate the SPN. If validation is successful, SQL Server allows the user to connect to SQL instance as per the assigned permissions
  SQL Server接收TDS数据包，并使用另一个Windows API AcceptSecurityContext并解密令牌，并与域控制器联系以验证SPN。 如果验证成功，则SQL Server允许用户根据分配的权限连接到SQL实例

If there is an error in this AcceptSecurityContext process, SQL Server returns the following error messages:

如果此AcceptSecurityContext进程中存在错误，则SQL Server返回以下错误消息：

• Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. (Microsoft SQL Server, Error: 18456)
  用户“ NT AUTHORITY \ ANONYMOUS LOGON”的登录失败。 （Microsoft SQL Server，错误：18456）
• Login failed for user ‘(null)’
  用户'（null）'登录失败
• SSPI handshake failed error
  SSPI握手失败错误
• Login failed. The login is from an untrusted domain and cannot be used with Windows authentication
  登录失败。 该登录名来自不受信任的域，不能与Windows身份验证一起使用

You can understand the Kerberos authentication process using the following image.

您可以使用下图了解Kerberos身份验证过程。

在SQL Server中使用Kerberos身份验证的先决条件 (Prerequisites to use Kerberos authentication in SQL Server)

SQL Server should meet the following prerequisites to use Kerberos authentication in SQL Server.

SQL Server应该满足以下先决条件，才能在SQL Server中使用Kerberos身份验证。

• SQL Server and client machine should be part of the domain
  SQL Server和客户端计算机应该是域的一部分
• We might use multiple domains in the environment. We can still use Kerberos authentication, but the domain trust relationship should be there
  我们可能在环境中使用多个域。 我们仍然可以使用Kerberos身份验证，但是域信任关系应该存在
• Service Principal Name (SPN) should be registered successfully for the SQL Services
  服务主体名称（SPN）应该为SQL服务成功注册

Once we start SQL Services, you can look entry for the Service principal name in the error logs.

启动SQL Services后，您可以在错误日志中查找Service主体名称的条目。

• Successful SPN Registration message
  成功的SPN注册消息

The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQL.testdomain.in:24629 ] for the SQL Server service.

SQL Server网络接口库已成功为SQL Server服务注册了服务主体名称（SPN）[MSSQLSvc / SQL.testdomain.in：24629]。

• Failed SPN Registration message SPN注册失败消息

Let’s go back to our introduction part scenario. In that example, previous SQL Services were running under the local system. At that time, SQL Server registered the Service Principal Name (SPN) successfully, and users can connect to the SQL using Kerberos authentication. Now once you changed the service account, SQL Server failed to deregister the old SPN associated with the local system account. Once the users try to connect to SQL Server, it fails because existing SPN is not associated with the existing service account. You get Cannot Generate SSPI Context error in this case.

让我们回到引言部分的场景。 在该示例中，以前SQL Services在本地系统下运行。 那时，SQL Server成功注册了服务主体名称（SPN），用户可以使用Kerberos身份验证连接到SQL。 现在，一旦更改了服务帐户，SQL Server便无法注销与本地系统帐户关联的旧SPN。 用户尝试连接到SQL Server后，它将失败，因为现有的SPN与现有的服务帐户没有关联。 在这种情况下，您将收到无法生成SSPI上下文错误。

Kerberos身份验证和NTLM的比较 (Comparison of Kerberos authentication and NTLM )

• Kerberos provides a faster Authentication method compare to the NTLM
  与NTLM相比，Kerberos提供了更快的身份验证方法
• NTLM allows only single hop from the client machine to the SQL Server. Nowadays, we require many hopes between servers. For example, using a linked server, we connect to a different server, or we might think of an SSRS solution in which SSRS components and databases are on different servers
  NTLM仅允许从客户端计算机到SQL Server的单跳。 如今，我们要求服务器之间充满希望。 例如，使用链接服务器，我们连接到其他服务器，或者我们可能想到的SSRS解决方案中，SSRS组件和数据库位于不同的服务器上

Kerberos allows multiple hops, and we can use it to communicate with the end machine using the same credentials. It helps to effectively manage the authentication solution and also reduces the load on the domain controller.

Kerberos允许多个跃点，我们可以使用它使用相同的凭据与终端计算机进行通信。 它有助于有效地管理身份验证解决方案，并减少域控制器上的负载。

At first, a client gets a TGT from the domain controller after providing the credentials. The client uses this TGT and asks a Service ticket from the domain controller. In this example, it asks a service ticket to connect with SQL Server 1.

首先，客户端在提供凭据后会从域控制器获取TGT。 客户端使用此TGT，并向域控制器请求服务票证。 在此示例中，它要求服务票证与SQL Server 1连接。

In SQL Server 1, we have a linked server that connects to another SQL Server using the current login security context. If you have used linked server before, you might know that we do not need to provide the credentials again for the windows user. It automatically takes care of the credentials. It is due to the double hop method of Kerberos authentication.

在SQL Server 1中，我们有一个链接服务器，该服务器使用当前的登录安全上下文连接到另一个SQL Server。 如果您以前使用过链接服务器，则可能知道我们不需要再次为Windows用户提供凭据。 它会自动处理凭据。 这是由于Kerberos身份验证的双跳方法。

Now, SQL Server uses existing TGT and connects with the domain controller to ask for another service ticket to connect with SQL Server 2. Once it gets a service ticket, it can authenticate to SQL Server 2 successfully.

现在，SQL Server使用现有的TGT并与域控制器连接，以请求另一个服务票证与SQL Server 2连接。一旦获得服务票证，它就可以成功地向SQL Server 2进行身份验证。

• Kerberos authentication is more secure than NTLM
  Kerberos身份验证比NTLM更安全
• Kerberos authentication is an open standard solution
  Kerberos身份验证是一种开放标准解决方案
• You can use smart card login using the Kerberos authentication while NTLM does not provide this functionality
  您可以使用Kerberos身份验证使用智能卡登录，而NTLM不提供此功能

服务主体名称概述 (Service Principal Names overview)

Service Principal Names (SPN) is a unique identifier for each service. We must have an SPN for each SQL instance. In the case of multiple instances, we must register all the SPN. It is a mandatory step for SQL Server connections to use Kerberos authentication.

服务主体名称（SPN）是每个服务的唯一标识符。 每个SQL实例都必须有一个SPN。 在多个实例的情况下，我们必须注册所有SPN。 这是SQL Server连接使用Kerberos身份验证的必需步骤。

For SQL Services, the format of SPN is MSSQLSvc/SQLFQDN: Port number.

对于SQL Services，SPN的格式为MSSQLSvc / SQLFQDN：端口号。

默认独立SQL实例的SPN (SPN for the default standalone SQL instance)

Suppose the FQDN for SQL Server is SQLA.TestDomain.com and its running on the default port 1433.

假设SQL Server的FQDN是SQLA.TestDomain.com，并且它在默认端口1433上运行。

SPN for default instance will be as follows.

默认实例的SPN如下。

• MSSQLSvc/ SQLA.TestDomain.com
  MSSQLSvc / SQLA.TestDomain.com
• MSSQLSvc/ SQLA.TestDomain.com:1433
  MSSQLSvc / SQLA.TestDomain.com:1433

In the SQL Error log, you will get the following entry:

在“ SQL错误”日志中，您将获得以下条目：

命名独立实例的服务主体名称（SPN） (Service Principal Name (SPN) for named standalone instance)

Suppose we have a named instance for SQL Server SqlShack and the FQDN for SQL Server is SQLA.TestDomain.com.

假设我们有一个SQL Server SqlShack的命名实例，而SQL Server的FQDN是SQLA.TestDomain.com。

The named instance is also running on port 64234.

命名实例也在端口64234上运行。

SPN for the named instance will be as follows:

命名实例的SPN将如下所示：

• MSSQLSvc/ SQLA.TestDomain.com:SqlShack
  MSSQLSvc / SQLA.TestDomain.com:SqlShack
• MSSQLSvc/ SQLA.TestDomain.com:64234
  MSSQLSvc / SQLA.TestDomain.com:64234

In the SQL Error log, you will get the following entry.

在SQL错误日志中，您将获得以下条目。

故障转移群集实例的SPN (SPN for Failover Cluster instance)

If we are using a failover cluster instance, we do not connect SQL with the individual SQL Services. We use the failover cluster virtual name for this.

如果使用故障转移群集实例，则不会将SQL与单个SQL Services连接。 为此，我们使用故障转移群集虚拟名称。

Instance Type	FQDN
Standalone	FQDN of the standalone instance
Failover Cluster	Failover cluster virtual name

实例类型	合格域名
单机版	独立实例的FQDN
故障转移群集	故障转移群集虚拟名称

Suppose we have the following environment.

假设我们具有以下环境。

• Nodes: SQLA and SQLB
  节点：SQLA和SQLB
• Failover Cluster Virtual name: SQLC
  故障转移群集虚拟名称：SQLC
• SQL Server port: 1433 (default)
  SQL Server端口：1433（默认）

The SPN of this failover instance will be as follows:

此故障转移实例的SPN如下：

• MSSQLSvc/ SQLC.TestDomain.com
  MSSQLSvc / SQLC.TestDomain.com
• MSSQLSvc/ SQLC.TestDomain.com: 1433
  MSSQLSvc / SQLC.TestDomain.com：1433

In the SQL Server error logs, you can see the following entries.

在SQL Server错误日志中，您可以看到以下条目。

In the following image, you can understand the Service Principal Name (SPN) for the failover cluster SQL.

在下图中，您可以了解故障转移群集SQL的服务主体名称（SPN）。

SPN for Always-On SQL侦听器 (SPN for Always-On SQL Listener)

We use SQL Listener to connect with the primary replica in SQL Server Always On. We should create SPN for each availability group SQL Listener. It enables the Kerberos authentication for the client connection. We should use the same SQL Service account for all Availability group replicas.

我们使用SQL Listener来连接SQL Server Always On中的主副本。 我们应该为每个可用性组SQL侦听器创建SPN。 它为客户端连接启用Kerberos身份验证。 我们应该对所有可用性组副本使用相同SQL Service帐户。

We need to use FQDN of SQL Listener along with listener port to configure SPN for SQL Server Always On.

我们需要使用SQL侦听器的FQDN以及侦听器端口来为SQL Server Always On配置SPN。

Suppose we have an availability group SQLAGProd-DB-LSN and all replicas are running with domain service account testdomain\SQLprod. The listener is configured to run with port 81234

假设我们有一个可用性组SQLAGProd-DB-LSN，并且所有副本都使用域服务帐户testdomain \ SQLprod运行。 侦听器配置为使用端口81234运行

In this case, we can use the following SETSPN command to configure an SPN.

在这种情况下，我们可以使用以下SETSPN命令来配置SPN。

setspn -A MSSQLSvc/ SQLAGProd-DB-LSN.testdomain.com: 81234 testdomain\SQLprod

setspn -A MSSQLSvc / SQLAGProd-DB-LSN.testdomain.com：81234 testdomain \ SQLprod

SETSPN命令 (The SETSPN Command)

We can use SETSPN command to list the available SPN for the specific domain account. Execute the following query with administrative rights.

我们可以使用SETSPN命令列出特定域帐户的可用SPN。 以管理权限执行以下查询。

列出所有已注册的SPN (List all registered SPN )

We can use –L parameter with the setspn command to list all available SPN associated with a service account.

我们可以将–L参数与setspn命令一起使用，以列出与服务帐户关联的所有可用SPN。

setspn -L <Domain\Service Account>

setspn -L <域\服务帐户>

手动注册SPN (Manually Register SPN)

A domain administrator can manually register the SPN as well using the following command.

域管理员也可以使用以下命令手动注册SPN。

setspn –a MSSQLSvc/<hostnameFQDN>:1433 <Domain\Service account>

setspn –a MSSQLSvc / <主机名FQDN>：1433 <域\服务帐户>

We need to register SPN for each SQL Service.

我们需要为每个SQL服务注册SPN。

自动注册服务主体名称 (Automatically Register Service Principal Name)

SQL Server can automatically register SPN during startup of SQL Services. In this case, SQL Services should be running under a local system or network service or the domain account has sufficient permissions to register an SPN. It requires Read servicePrincipal name and writes ServicePrincipal name permissions in the active directory.

SQL Server可以在SQL Services启动期间自动注册SPN。 在这种情况下，SQL Services应该在本地系统或网络服务下运行，或者该域帐户具有足够的权限来注册SPN。 它要求读取servicePrincipal名称并在活动目录中写入ServicePrincipal名称权限。

结论 (Conclusion)

In this article, we explored the Service Principal Name along with the Kerberos authentication method to connect to SQL Server. It helps to troubleshoot the issues if you are familiar with the internal processes.

在本文中，我们探讨了服务主体名称以及Kerberos身份验证方法以连接到SQL Server。 如果您熟悉内部流程，则有助于解决问题。

翻译自: https://www.sqlshack.com/overview-of-service-principal-name-and-kerberos-authentication-sql-server/

kerberos验证