PN(Service Principal name)服务器主体名称。
SPN 是服务在应用 Kerberos 身份验证的网络上的惟一标识符，它由服务类、主机名和端口组成。在应用 Kerberos 身份验证的网络中，必须在内置计算机帐户（如 NetworkService 或 LocalSystem）或用户帐户下为服务器注册 SPN。对于内置帐户，SPN 将主动进行注册。然而，如果在域用户帐户下运行服务，则必须为要应用的帐户手动注册 SPN。
客户端连贯 Sqlserver 实例报 SPN 谬误的解决办法
1、先登录 Sqlserver 实例服务器执行 setspn -L dai\sqlprocess |find “machine name” 查看相干 Sqlserver 实例对应的服务器信息, 看是否有有效信息, 有有效信息或反复信息则应用 setspn - D 删除它
2、再通过 Microsoft Kerberos Configuration Manager for SQL Server 客户端工具，连贯相干 Sqlserver 实例的服务器，只输出服务器名即可，查看相干服务器是否失常
3、最初应用 setspn -D、setspn - A 重建该 Sqlserver 实例对应服务器的所有 SPN 信息，应用 setspn 时须要 administrator 模式运行 cmd
4、换一个客户端机器试试，有时是某个客户端机器本身无奈取得域、dns、dhcp 服务器上的信息，或该机器还没及时同步到域、dns、dhcp 服务器上的信息，连贯 Sqlserver 也会报 SPN 谬误
5、如果服务器有别名，而后 AG 的监听应用了别名，则必须应用服务器别名 alias 注册到 spn 中，即 setspn -A aliasname:1433 dai\sqlprocess
6、邮件报警 Server Name 对应 DBPROD2 示意 DBPROD2 的 spn 出了问题，对应 DBPROD2\BI1 示意 DBPROD2\BI1 的 spn 出了问题，DBPROD2 可能是别名也可能是服务器名
7、重建 SPN 后，如果没有及时失效，可能须要等等过一会游戏才会失效。
8、最好的验证办法就是，间接点击某个 linked server，看是否连贯测试胜利，如下示意 DBDEV1 拜访不了 12.2.37.123 对应的 linked server。
DBDEV1 Logon Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. Reason: Could not find a login matching the name provided. [CLIENT:12.2.37.123]
9、linked server 报错，Cannot generate SSPI context，是因为 netlogon 服务起不来导致，computer management–local user and groups–groups–adminstrator 组上面的用户都是一些阿拉伯数字，看不到域用户。netlogon 起不来是因为 workstation 起不来，而 workstation 起不来，是因为应用了 local system account，应用 network service 用户并保留明码框为空即可，这种状况下，kerberos 外面输出这台服务器都无奈登录，会报错：The was an issue with accessing UserAccount information from the system
10、linux 服务器拜访 sqlserver 实例报错 SSPI Provider: Server not found in Kerberos database (851968) (SQLDriverConnect)
解决办法 1：
个别 windows 服务器拜访 sqlserver 实例，在 SPN 外面写的是 sqlserver 实例对应的服务器名称，linux 的话，看 linux 配置的字符串，如果字符串外面是实例名称，则须要把实例名称写入 SPN，比方开发的配置文件写的是 sqlserver 实例名称 ibdwonstagedbalias，该服务器名称 stagingdbaws1，SPN 外面的信息只有服务器 stagingdbaws1 名称，增加实例名称到 SPN 即可
setspn -A MSSQLSvc/ibdwonstagedbalias.d.com:1433 dai\sqlprocess
setspn -A MSSQLSvc/ibdwonstagedbalias.d.com dai\sqlprocess
解决办法 2：
如果不是以上 1 的情景，那么起因可能是 linux 服务器上 crontab 服务呈现问题导致 crontab 的外面的 credential-renew.sh 没有运行，能够通过 less /var/log/cron |grep “credential-renew.sh” 查看这个 crontab 的运行记录，credential-renew.sh 可执行文件外面命令是 kinit
解决办法 3：
如果不是以上 1、2 的情景，通过 date 查看 linux 服务器工夫，如果是 linux 服务器的工夫和域控工夫不一样，这个时候在 linux 服务器上顺次执行 systemctl status ntpd、systemctl stop ntpd、ntpdate 12.2.10.66(域控服务器 ip)、systemctl start ntpd
1、In SSMS, connect to the SQL instance that you are going to recreate the SPN records for
2、Open the SQL Server logs
3、Filter results based on “spn” in the message text
Don’t forget to click the “Apply filter” checkbox
4、You may have to filter through older logs and not just the “Current” log to find the records that start with the message:
“The SQL Server Network Interface library succesfully registered the Service Principal Name…”
5、Copy the SPN portion of both messages and paste them into a Notepad
One record has the port number at the end and the other has the instance name
If it is the default instance then the port number will be 1433 and the instance name will be absent
6、With the two SPN records in Notepad, replace the machine name of the server with the alias
The alias is either a C-NAME DNS record or an Availability www.sangpi.comGroup listener such as: PROD2, PDBALIAS, etc
7、Remote into the server as your domain-admin account
8、In your RDP session to the server, run CMD as administrator
9、Use the following syntax to delete the existing SPN record (if it exists) then recreate it
setspn -D MSSQLSvc/PROD2.d.com:52219 dai\sqlprocess
setspn -A MSSQLSvc/PROD2.d.com:52219 dai\sqlprocess
10、Do the same for both records (port and instance name)
setspn -D MSSQLSvc/PROD2.d.com:BI1 dai\sqlprocess
setspn -A MSSQLSvc/PROD2.d.com:BI1 dai\sqlprocess
集体域账号登录服务器，运行 cmd 以 administrator 权限模式，执行如下
setspn -L dai\sqlprocess | find “ 服务器名称 PROD2” > C:\spn.txt
setspn -D MSSQLSvc/PROD2.d.com:52219 dai\sqlprocess
setspn -A MSSQLSvc/PROD2.d.com:52219 dai\sqlprocess
setspn -D MSSQLSvc/PROD2.d.com:BI1 dai\sqlprocess
setspn -A MSSQLSvc/PROD2.d.com:BI1 dai\sqlprocess