MSSQLSvc 服务主体名称、Kerberos 和 NTLM

MSSQLSvc 服务主体名称、Kerberos 和 NTLM

最近正在帮助一位 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 版本的不同而变化。

这是一篇很好的后续文章,尽管它很旧,但仍然具有很大的相关性:

http://blogs.msdn.com/b/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx


更新:

如果有任何安慰的话,我刚刚使用 SQL Server 2012 和运行 Server 2012 R2 和 SQL Management Studio 的远程客户端运行了测试。当 SPN 正确注册时,使用 Kerberos。当 SPN 缺失时,SQL Management Studio 故障转移到 NTLM。当我故意在服务帐户的 SPN 中输入拼写错误时,连接仍然建立,并故障转移到 NTLM。所以这是个好消息,但事实是其他未指定的应用程序可能无法正确实现 Windows 身份验证以利用该协商协议……所以如果你有奇怪的应用程序,你仍然需要测试它们。在测试中,不要忘记 NTLM 将总是用于当地的连接,无论 SPN 如何...取决于操作系统版本。:D

相关内容