通过

SQL Server 中的间歇性或定期身份验证问题

  • 项目

注意

在开始故障排除之前，我们建议查看先决条件并核对清单。 有关详细信息，请参阅 自助文章。

本文介绍 SQL Server 连接中间歇性身份验证问题的常见原因，并提供解决方案。

现象

当用户或应用程序面临使用 SQL Server 数据库进行身份验证的零星困难时，SQL Server 连接中的间歇性或定期身份验证问题会发生。 这会导致数据访问和应用程序功能中断。

最常见的错误消息

  • 无法生成 SSPI 上下文

  • 用户登录失败

    • 用户登录失败''
    • 用户“NT AUTHORITY\ANONYMOUS LOGON”登录失败
    • 用户“UserName>”<登录失败
    • 用户“Domain>\<UserName>”<登录失败
    • 登录失败。 登录名来自不受信任的域，不能与Windows 身份验证一起使用。

原因

最常见的问题是由 SQL Server 性能或域控制器响应缓慢引起的。 如果使用 NT LAN 管理器（NTLM），则本地安全机构子系统服务（LSASS）存在瓶颈，并限制一次可以处理多少个新连接。 其他请求已备份，可能会超时。某些原因（如防病毒）可能难以证明，但仍很常见，即使其他调查途径无效，也应进行调查。

疑难解答流程

由于此问题是间歇性的，因此配置（如 Kerberos 服务主体名称（SPN）可能是正确的。 若要解决此问题，请尝试以下故障排除步骤：

多个域或数据中心之间的延迟差异

如果涉及多个域或数据中心，请检查本地域或数据中心中的用户是否在其他域或数据中心的用户遇到问题。 如果是这样，则可能表示数据中心或域控制器之间的通信延迟。 使用以下命令调查问题：

  • 若要检查网络延迟，请使用 ping。 例如：

    1. 运行 ping <DatabaseServer> 命令。

    2. 查看时间列，并将该时间与其他域或数据中心中的时间进行比较：

      Pinging <DatabaseServer> [10.10.10.3] with 32 bytes of data:
Reply from 10.10.10.3: bytes=32 time=68ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116

  • 若要测试凭据验证延迟问题，请 对各种用户使用 Runas 。 例如：

    1. 运行 runas /user:<DomainName>\<UserAccountName> cmd.exe。
    2. 在命令提示符显示后输入用户的密码。

如果在使用这些命令进行测试后仍存在此问题，则问题与 SQL Server 不一样，而是具有网络基础结构或域控制器性能。

在 SQL Server 错误日志中查找性能问题

SQL Server 错误日志可能会显示 SQL Server 上的性能问题，例如指示 I/O 花费的时间超过 15 秒的条目。 SQL 性能团队具有 PSSDIAG 来运行和分析。 如果网络跟踪显示 SQL Server 响应中的延迟，则可能需要执行此操作。

错误日志可能包括其他域相关的错误，例如以下错误日志，指示某些 Active Directory 性能问题：

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed.

以下操作系统错误代码指示失败的原因：

  • 错误 -2146893039（0x80090311）：无法联系颁发机构进行身份验证。

  • 错误 -2146893052 （0x80090304）：无法联系本地安全机构。

查看客户端系统上的事件日志，了解网络错误

系统事件日志具有各种事件，例如 Kerberos、Local Security Authority （LSA）和 Netlogon 事件。 这些事件指示计算机在一段时间内无法连接到域控制器。 若要使其更易于查找，请仅 筛选错误、 警告和 严重 事件。 事件时间需要在中断时间左右。 如果存在匹配项，则可能是 Active Directory 问题。

在某些情况下，此问题可能发生在 SQL Server 上。 检查该计算机上的日志。

Source: NETLOGON
Date: <DateTime>
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLPROD01
Description:
This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following: The remote procedure call was cancelled. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

在安全事件日志中，筛选 事件 ID 4625。 此事件显示有关登录失败的详细信息。

收集和查看 SQL 连接环缓冲区

环形缓冲区是 SQL Server 上连接事件的历史日志，这意味着可以在服务中断后进行。 许多事件包括登录计时器，用于告知你花费的时间：

  • 网络上花费的时间表示可能存在的网络或客户端延迟。
  • 在安全套接字层（SSL）或安全支持提供程序接口（SSPI）API 上花费的时间表明 Windows 安全子系统可能存在的问题。
  • 排队时间表示 SQL Server 性能问题。

有关详细信息，请参阅 “收集连接环缓冲区”。

连接池

缺少 连接池 可能会导致间歇性登录失败。

注意

与已建立的连接相比，缺少连接池将在输出中NETSTAT显示大量TIME_WAIT状态代码。

如果未启用连接池，客户端可能会耗尽出站端口，并且还会重载服务器。 此重载可能导致服务器拒绝传入的连接请求或淹没性能不佳的域控制器。

最好的做法是让应用程序开发人员在其应用程序中使用连接池。 默认情况下，连接池在 .NET 和 Internet Information Services （IIS） 应用程序中处于打开状态，但出于某种原因可能已关闭。

强烈建议应用程序使用自定义池代码。 我们遇到的几乎所有自定义池实现都有问题。 最好使用内置连接池机制。

耗尽临时端口是间歇性连接超时的相对常见的原因。

问题：SQL Server 计算机上的内核内存不足。

解决方案：在 SQL Server Management Studio 的“属性”窗格中调整最大服务器内存（MB）。 最好将最大服务器内存（MB）设置为比计算机上的物理内存少约 4 GB 到 8 GB。 如果计算机上运行多个实例、IIS 或其他一些应用程序服务器，则此值应更小。 有关最大服务器内存（MB）设置的建议，请参阅服务器内存配置选项。

注意

默认值为 2147483647 MB，这意味着服务器可能会导致操作系统（OS）耗尽内存。