![MSSQLSvc 服务主体名称、Kerberos 和 NTLM](https://linux22.com/image/635783/MSSQLSvc%20%E6%9C%8D%E5%8A%A1%E4%B8%BB%E4%BD%93%E5%90%8D%E7%A7%B0%E3%80%81Kerberos%20%E5%92%8C%20NTLM.png)
最近正在帮助一位 DBA 解决一个似乎与无效 SPN 有关的问题。发现很多 SQL 服务帐户根本没有设置 SPN,导致 NTLM 身份验证。
我已经将 SPN 配置添加到我们的构建过程中,但不确定回到使用 NTLM 的现有系统并配置 SPN 以允许 Kerberos 身份验证是否会破坏任何东西。
是否存在一些常见情况,其中配置 MSSQLSvc SPN 以允许 Kerberos 身份验证会破坏通过 NTLM 正常运行的现有系统?
这是我正在使用的代码:
#Query to identify authentication type for various connections on a SQL server
$query = "SELECT
s.session_id,
c.connect_time,
s.login_time,
s.login_name,
c.protocol_type,
c.auth_scheme,
s.HOST_NAME,
s.program_name
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c
ON s.session_id = c.session_id"
#Everything comes back NTLM
#Source: https://raw.githubusercontent.com/RamblingCookieMonster/PowerShell/master/Invoke-Sqlcmd2.ps1
Invoke-Sqlcmd2 -ServerInstance ServerInQuestion -query $query
#Get a list of SPNs associated with ServerInQuestion
#Results indicate no SPNs exist
#Source: http://gallery.technet.microsoft.com/scriptcenter/Get-SPN-Get-Service-3bd5524a
Get-SPN -ServiceType MSSQLSvc -ComputerName ServerInQuestion
#Configuring SPNs for test systems results in Kerberos working without issue
setspn -A "MSSQLSvc/ServerInQuestion.DOMAIN.XXX:1433" DOMAIN\SVCACCOUNT
setspn -A "MSSQLSvc/ServerInQuestion.DOMAIN.XXX" DOMAIN\SVCACCOUNT
我担心的是,如果我回到现有系统并配置 SPN,我可能会破坏使用 NTLM 但不使用 Kerberos 的现有应用程序或流程。我假设他们会在需要时故障恢复到 NTLM,但这不是我的专业领域,我不太愿意做出这样的假设。
谢谢!
答案1
您至少有一点担心,这可能是对的。不幸的是,特定应用程序是否会中断完全取决于应用程序。但一般来说,只要您正确设置 SPN,就不太可能出现任何问题。
我的主要建议是: 不正确的 SPN 比没有 SPN 更糟糕。
我认为对您来说唯一可能存在的问题是 SPN 设置是否正确。
请看这个例子:
- 如果远程客户端尝试对 SQL 进行身份验证并找到有效的 SPN,它将使用 Kerberos。
- 如果远程客户端尝试连接但找不到 SPN,它将使用 NTLM。
- 如果远程客户端尝试连接并找到 SPN,然后尝试使用该 SPN 通过 Kerberos 进行身份验证,但由于 SPN 无效而失败……它是否仍会失败回到 NTLM?
最后一个问题是一个非常具体的行为,根据应用程序和 Windows 版本的不同而变化。
这是一篇很好的后续文章,尽管它很旧,但仍然具有很大的相关性:
更新:
如果有任何安慰的话,我刚刚使用 SQL Server 2012 和运行 Server 2012 R2 和 SQL Management Studio 的远程客户端运行了测试。当 SPN 正确注册时,使用 Kerberos。当 SPN 缺失时,SQL Management Studio 故障转移到 NTLM。当我故意在服务帐户的 SPN 中输入拼写错误时,连接仍然建立,并故障转移到 NTLM。所以这是个好消息,但事实是其他未指定的应用程序可能无法正确实现 Windows 身份验证以利用该协商协议……所以如果你有奇怪的应用程序,你仍然需要测试它们。在测试中,不要忘记 NTLM 将总是用于当地的连接,无论 SPN 如何...取决于操作系统版本。:D