通过

SQL Server 中的一致身份验证问题

  • 项目

适用于： SQL Server

注意

本文中提供的命令仅适用于 Windows 系统。

Microsoft SQL Server 中出现的一致身份验证问题通常与尝试访问 SQL Server 数据库的用户或应用程序的身份验证和授权有关。 这些问题可能是身份验证失败、拒绝访问错误或其他与安全相关的问题。

有效解决一致身份验证问题的关键是了解不同的错误类型以及每个错误消息的含义。 一些错误可能会出现在多个身份验证问题中。 可以使用错误 类型 部分中提到的故障排除信息来解决错误。

先决条件

在开始进行故障排除之前，请完成 先决条件 清单，准备好以下信息：

错误类型

本部分介绍错误类型和相关信息。

  • 目录服务错误：如果 SQL Server 错误日志文件包含以下消息之一或两条，则此错误与 Active Directory 域服务 (AD DS) 相关。 如果基于 SQL Server 的计算机上的 Windows 无法联系域控制器 (DC) ，或者如果本地安全机构子系统服务 (LSASS) 遇到问题，也可能会出现此错误。

    Error -2146893039 (0x80090311): No authority could be contacted for authentication.
Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.

  • 登录失败错误：排查“登录失败”错误时，SQL Server 错误日志提供错误代码 18456 的其他见解，包括提供有关错误的更多上下文的特定状态值。 有关详细信息，请参阅 SQL 状态值中的 SQL Server 错误日志文件。 可以尝试根据状态值的说明修复问题。

    下表列出了一些特定的“登录失败”错误消息及其可能的原因和解决方案。

    错误消息 更多信息
    “将请求发送到服务器时发生传输级别错误。” 检查 链接服务器帐户映射 是否正确。 有关详细信息，请参阅 sp_addlinkedsrvlogin。
    “无法生成 SSPI 上下文”
    “无法打开登录名请求的数据库 <测试> 。 登录失败。” 数据库可能处于脱机状态，或者权限可能不够。 有关详细信息，请参阅 MSSQLSERVER_18456 中的数据库脱机。
    此外，请检查连接字符串中的数据库名称是否正确。
    “用户 <用户名>登录失败。” 如果 代理帐户 未正确进行身份验证，则会发生此错误。
    “用户登录失败：'NT AUTHORITY\ANONYMOUS LOGON'” 如果 缺少 SPN、SPN 重复或 SPN 位于错误的帐户上，则可能会出现此错误。
    “用户<用户名>登录失败。”
    “用户'database\username>'<登录失败”
    		 检查 连接字符串是否包含不正确的服务器名称。 此外，检查用户是否属于用于授予服务器访问权限的本地组。 有关更多原因，请参阅 NT AUTHORITY\ANONYMOUS LOGON。
    “用户'用户名>'<登录失败。 原因：密码与提供的登录名的密码不匹配。” 如果使用的密码不正确，则可能会出现此错误。 有关详细信息，请参阅用户“用户名>”的登录失败或用户“<域><用户名>”<的登录失败。
    “SQL Server 不存在或访问被拒绝。” 命名管道连接 失败，因为用户无权登录到 Windows。
    “登录名来自不受信任的域，不能与 Windows 身份验证一起使用。” 此错误可能与 本地安全子系统 问题有关。
    “不允许用户帐户使用网络登录类型。” 可能无法 登录到网络。

一致身份验证问题的类型

本部分介绍一致身份验证问题的典型原因及其各自的解决方案。 选择问题类型以查看相关问题、原因和解决方案。

连接字符串

本部分列出了与应用程序用于连接到数据库的配置设置相关的问题。

数据库

本部分列出了特定于 SQL Server 的各个方面的问题：

  • 数据库脱机 - 是指 SQL Server 数据库尝试重新连接到为 Windows 身份验证模式配置的 SQL Server 实例的方案。

    解决 方案： 有关详细信息，请参阅 MSSQLSERVER_18456。

  • 数据库权限 - 指启用或限制对 SQL Server 数据库的访问。

    解决 方案： 有关详细信息，请参阅 MSSQLSERVER_18456。

  • SQL Server 中的链接服务器连接错误 - 遇到影响 SQL Server 上下文中链接服务器的身份验证过程问题。

    解决 方案： 若要解决此问题，请参阅 SQL Server 中的链接服务器连接错误。

  • 链接服务器的元数据不一致 - 是指链接服务器的元数据不一致或与预期元数据不匹配的问题。

    视图或存储过程查询链接服务器中的表或视图，但即使从过程复制的分布式 SELECT 语句不接收登录失败。

    如果视图已创建，然后重新创建了链接服务器，或者在未重新生成视图的情况下修改了远程表，则可能会出现此问题。

    解决方案：通过运行 sp_refreshview 存储过程来刷新链接服务器的元数据。

  • 代理帐户没有权限 - SQL 代理运行的 SQL Server Integration Service (SSIS) 作业可能需要 SQL 代理服务帐户可以提供的权限以外的权限。

    解决 方案： 若要解决此问题，请参阅 从 SQL Server 代理作业步骤调用时 SSIS 包不运行。

  • 无法登录到 SQL Server 数据库 - 无法登录可能会导致身份验证失败。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18456。

目录服务

本部分列出了与目录服务和服务器相关的问题。

  • 帐户被禁用 - 如果用户帐户被管理员或用户禁用，则可能会遇到这种情况。 在这种情况下，不能使用此帐户登录，或者不能使用此帐户启动服务。 这可能会导致一致的身份验证问题，因为它可能会阻止你访问资源或执行需要身份验证的操作。

    解决 方案： 域管理员可以通过重新启用帐户来解决此问题。 禁用帐户时，通常是因为用户尝试使用错误密码登录次数过多，或者应用程序或服务尝试使用旧密码。

  • 帐户不在组中 - 如果用户尝试访问限制为特定组的资源，则可能会出现此问题。

    解决 方案： 检查 SQL 登录名以枚举允许的组，并确保用户属于其中一个组。

  • 帐户迁移失败 - 如果旧用户帐户无法连接到服务器，但新创建的帐户可以，则帐户迁移可能不正确。 此问题与 AD DS 相关。

    解决 方案： 有关详细信息，请参阅 在 SQL Server 实例之间传输登录名和密码。

  • 域控制器脱机 - 指无法访问域控制器的问题。

    解决 方案：nltest使用 命令强制计算机切换到另一个域控制器。 有关详细信息，请参阅 Active Directory 复制事件 ID 2087：DNS 查找失败导致复制失败。

  • 防火墙阻止域控制器 - 管理用户对资源的访问时可能会遇到问题。

    解决 方案： 确保可从客户端或服务器访问域控制器。 为此，请使用 nltest /SC_QUERY:CONTOSO 命令。

  • 登录来自不受信任的域 - 此问题与域之间的信任级别有关。 你可能会看到以下错误消息：“登录失败。 登录名来自不受信任的域，不能与 Windows 身份验证一起使用。 (18452) 。

    错误 18452 指示登录名使用 Windows 身份验证，但登录名是无法识别的 Windows 主体。 无法识别的 Windows 主体指示 Windows 无法验证登录名。 这可能是因为 Windows 登录名来自不受信任的域。 域之间的信任级别可能会导致帐户身份验证失败或服务提供商名称 (SPN) 可见性。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18452。

  • 跨域组没有权限 - 远程域中的用户应属于 SQL Server 域中的组。 如果尝试使用域本地组从另一个域连接到 SQL Server 实例，则可能有问题。

    解决 方案： 如果域缺乏适当的信任，将用户添加到远程域中的组中可能会阻止服务器枚举该组的成员身份。

  • 选择性身份验证被禁用 - 指域信任的一项功能，它允许域管理员限制哪些用户有权访问远程域中的资源。 如果未启用选择性身份验证，则受信任域中的所有用户都可以访问远程域。

    解决 方案： 若要解决此问题，请启用选择性身份验证，以确保不允许用户在远程域中进行身份验证。

Kerberos 身份验证

本部分列出了与 Kerberos 身份验证相关的问题：

  • 将错误的 DNS 后缀追加到 NetBIOS 名称 - 如果仅使用 NetBIOS 名称 (例如，SQLPROD01) 而不是 FQDN (完全限定的域名) (例如 SQLPROD01.CONTOSO.COM) ，则可能会出现此问题。 发生这种情况时，可能会追加错误的 DNS 后缀。

    解决 方案： 检查网络设置中的默认后缀以确保它们正确，或使用 FQDN 避免出现问题。

  • 时钟偏差过高 - 如果网络上的多个设备未同步，则可能会出现此问题。 若要使 Kerberos 身份验证正常工作，设备之间的时钟不能关闭超过五分钟，否则可能会发生一致的身份验证失败。

    解决 方案： 将计算机设置为定期将其时钟与中心时间服务同步。

  • 将敏感帐户委托给其他服务 - 某些帐户可能会在 AD DS 中标记为 Sensitive 。 在双跃点方案中，无法将这些帐户委托给另一个服务。 敏感帐户对于提供安全性至关重要，但它们可能会影响身份验证。

    解决 方案： 若要解决此问题，请参阅 用户 NT AUTHORITY\ANONYMOUS LOGON 的登录失败。

  • 委派到文件共享 - 是指用户或应用程序委托其凭据来访问文件共享的情况。 如果没有适当的约束，将凭据委托给文件共享可能会造成安全风险。

    解决 方案： 若要解决此类问题，请确保使用 约束委派。

  • 不连续的 DNS 命名空间 - 指域成员和 DNS 之间的 DNS 后缀不匹配时可能发生的一致身份验证问题。 如果使用不连续的命名空间，可能会遇到身份验证问题。 如果 AD DS 和 DNS 中的组织层次结构不匹配，如果在数据库应用程序连接字符串中使用 NETBIOS 名称，则可能生成错误的 SPN。 在这种情况下，找不到 SPN，并且使用新技术 LAN 管理器 (NTLM) 凭据而不是 Kerberos 凭据。

    解决 方案： 若要缓解此问题，请使用服务器的 FQDN 或在连接字符串中指定 SPN 名称。 有关 FQDN 的信息，请参阅 计算机命名。

  • 重复 SPN - 指域中两个或多个 SPN 相同的情况。 SPN 用于唯一标识在 Windows 域中的服务器上运行的服务。 重复的 SPN 可能会导致身份验证问题。

    解决 方案： 若要解决此问题，请参阅 使用 Kerberos Configuration Manager 修复错误 (建议) 。

  • 在 SPN 上启用 HTTP 端口 - 通常，HTTP SPN 不使用端口号 (例如 http/web01.contoso.com ，) 。

    解决 方案： 若要解决此问题，可以通过在客户端上使用策略来启用此功能。 然后，SPN 必须采用 格式 http/web01.contoso.com:88 才能使 Kerberos 正常工作。 否则，使用 NTLM 凭据。

    不建议使用 NTLM 凭据，因为它们可能难以诊断问题。 此外，这种情况可能会产生过多的管理开销。

  • 过期票证 - 指 Kerberos 票证。 使用过期的 Kerberos 票证可能会导致身份验证问题。

    解决 方案： 若要解决此问题，请参阅 过期票证。

  • HOSTS 文件不正确 - HOSTS 文件可能会中断 DNS 查找，并可能生成意外的 SPN 名称。 这种情况会导致使用 NTLM 凭据。 如果 HOSTS 文件中有意外的 IP 地址，则生成的 SPN 可能与指向的后端服务器不匹配。

    解决 方案： 查看 HOSTS 文件并删除服务器的条目。 SQLCHECK 报表中显示了 HOSTS 文件条目。

  • 每个服务的安全标识符 (SID) 权限的问题 - Per-service-SID 是 SQL Server 的一项安全功能，它限制本地连接使用 NTLM 而不是 Kerberos 作为身份验证方法。 该服务可以使用 NTLM 凭据向另一个服务器创建一个跃点，但如果不使用约束委派，则无法进一步委派该服务。 有关详细信息，请参阅 用户 NT AUTHORITY\ANONYMOUS LOGON 的登录失败。

    解决 方案： 若要解决此问题，域管理员需要设置约束委派。

  • 内核模式身份验证 - Web 服务器通常需要应用池帐户上的 SPN。 但是，使用内核模式身份验证时，将使用计算机的 HOST SPN 进行身份验证。 此操作在内核中发生。 如果服务器托管多个使用相同主机标头 URL、不同应用池帐户和 Windows 身份验证的不同网站，则可能会使用此设置。

    解决 方案： 如果启用了内核模式身份验证，请删除 HTTP SPN。

  • 限制对 Access 或 Excel 的委派权限 - 联合引擎技术 (JET) 和 Access Connectivity Engine (ACE) 提供程序与任何文件系统类似。 必须使用约束委派使 SQL Server 能够读取位于另一台计算机上的文件。 通常，不应在链接服务器中使用 ACE 提供程序，因为显式不支持此提供程序。 JET 提供程序已弃用，仅在 32 位计算机上可用。

    注意

    当支持 32 位安装的最后一个版本 SQL Server 2014 不再受支持时，JET 方案将不再受支持。

  • 缺少 SPN - 如果不存在与 SQL Sever 实例相关的 SPN，则可能会出现此问题。

    解决 方案： 有关详细信息，请参阅 使用 Kerberos Configuration Manager 修复错误 (建议) 。

  • 不是受约束的目标 - 如果为特定服务帐户启用了约束委派，则如果目标服务器的 SPN 不在受约束委派的目标列表中，Kerberos 将失败。

    解决 方案： 若要解决此问题，域管理员必须将目标服务器的 SPN 添加到中间层服务帐户的目标 SPN。

  • NTLM 和约束委派 - 如果目标是文件共享，则中间层服务帐户的委派类型必须为 约束-Any ，而不是 约束 Kerberos。 如果委托类型设置为 Constrained-Kerberos，则中间层帐户只能分配给特定服务，但 Constrained-Any 允许服务帐户委托给任何服务。

    解决 方案： 若要解决此问题，请参阅 用户 NT AUTHORITY\ANONYMOUS LOGON 的登录失败。

  • 在 AD 中无法信任服务帐户进行委派 - 在双跃点方案中，必须信任中间层服务的服务帐户才能在 AD DS 中委派。 如果委托不信任服务帐户，则 Kerberos 身份验证可能会失败。

    解决 方案： 如果你是管理员，请启用 “受信任的委派 ”选项。

  • 某些旧式提供程序不支持通过命名管道使用 Kerberos - 旧版 OLE DB 提供程序 (SQLOLEDB) 和 ODBC 提供程序 (与 Windows 捆绑的 SQL Server) 不支持通过命名管道进行 Kerberos 身份验证。 相反，它们仅支持 NTLM 身份验证。

    解决 方案： 使用 TCP 连接允许 Kerberos 身份验证。 还可以使用较新的驱动程序（例如 MSOLEDBSQL 或 ODBC Driver 17）。 但是，无论驱动程序的版本如何，TCP 仍优先于命名管道。

  • SPN 与错误的帐户相关联 - 如果 SPN 与 AD DS 中的错误帐户相关联，则可能会出现此问题。 有关详细信息，请参阅 使用 Kerberos Configuration Manager 修复错误 (建议) 。

    如果在 AD DS 中的错误帐户上配置了 SPN，则可能会收到错误消息。

    解决 方案： 若要解决此错误，请执行以下步骤：

    1. 使用 SETSPN -Q spnName 查找 SPN 及其当前帐户。
    2. 使用 SETSPN -D 删除现有 SPN。
    3. SETSPN -S使用 将 SPN 迁移到正确的帐户。

  • SQL 别名可能无法正常工作 - SQL Server 别名可能会导致生成意外的 SPN。 如果找不到 SPN，这会导致 NTLM 凭据失败;如果它无意中与另一个服务器的 SPN 匹配，则会导致 SSPI 失败。

    解决 方案： SQLCHECK 报表中显示了 SQL 别名。 若要解决此问题，请识别并更正任何不正确或配置错误的 SQL 别名，以便它们指向正确的 SQL Server。

  • 用户属于多个组 - 如果用户属于多个组，则 Kerberos 中可能会出现身份验证问题。 如果通过 UDP 使用 Kerberos，则整个安全令牌必须适合单个数据包。 属于多个组的用户的安全令牌大于属于较少组的用户。

    解决 方案： 如果通过 TCP 使用 Kerberos，可以增加 [MaxTokenSize] 设置。 有关详细信息，请参阅 MaxTokenSize 和 Kerberos Token Bloat。

  • 使用网站主机标头 - HTTP 主机标头在访问网页的 HTTP 协议中起着非常重要的作用。

    解决 方案： 如果网站具有主机标头名称，则无法使用 HOSTS SPN。 必须使用显式 HTTP SPN。 如果网站没有主机标头名称，则使用 NTLM。 无法将 NTLM 委托给后端 SQL Server 实例或其他服务。

NT LAN 管理器 (NTLM)

本部分列出了特定于 NTLM (NT LAN Manager) 的问题：

  • NTLM 对等登录名的访问被拒绝 - 指与 NTLM 对等登录名相关的问题。

    解决 方案： 在工作站或不相互信任的域中的计算机之间通信时，可以在两台计算机上设置相同的帐户并使用 NTLM 对等身份验证。

    仅当用户帐户和密码在两台计算机上都匹配时，登录名才起作用。 客户端或服务器端可能禁用或不支持 NTLM 身份验证。 这种情况可能会导致身份验证失败。 有关详细信息，请参阅 MSSQLSERVER_18456。

  • 多台计算机上的双跃点方案 - 如果使用 NTLM 凭据，则双跃点进程将失败。 需要 Kerberos 凭据。

    解决 方案： 若要解决此问题，请参阅 用户 NT AUTHORITY\ANONYMOUS LOGON 的登录失败。

  • 环回保护未正确设置 - 环回保护旨在禁止应用程序调用同一计算机上的其他服务。 如果未正确配置环回保护，或者出现任何故障，这种情况可能会间接导致身份验证问题。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18456。

  • 连接到 Always-on 侦听器时环回保护失败 - 此问题与环回保护有关。 从主节点连接到 Always-On 侦听器时，连接将使用 NTLM 身份验证。

    解决 方案： 有关详细信息，请参阅 MSSQLSERVER_18456。

  • 影响 LANMAN 兼容级别的问题 - 如果旧 (Windows Server 2008 之前的) 和较新的计算机使用的身份验证协议不匹配，则通常会出现 LAN Manager (LANMAN) 身份验证问题。 将兼容级别设置为 5 时，不允许使用 NTLMv2。

    解决 方案： 切换到 Kerberos 可避免此问题，因为 Kerberos 更安全。 有关详细信息，请参阅 用户 NT AUTHORITY\ANONYMOUS LOGON 的登录失败。

SQL 登录名

本部分列出了与身份验证凭据相关的问题：

  • 密码错误 - 指与登录相关的问题。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18456。

  • 用户名无效 - 指与登录相关的问题。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18456。

  • 未启用 SQL Server 登录名 - 是指尝试使用 SQL Server 身份验证连接到 Microsoft SQL Server 实例，但禁用与帐户关联的登录名的方案。

    解决 方案： 若要解决此问题，请参阅 MSSQLSERVER_18456。

  • 命名管道连接失败，因为用户无权登录到 Windows - 指 Windows 中的权限问题。

    解决 方案： 若要解决此问题，请参阅 SQL Server 中的命名管道连接问题。

Windows 权限

本部分列出了特定于 Windows 权限或策略设置的问题：

  • 通过本地组授予访问权限 - 如果用户不属于用于授予服务器访问权限的本地组，提供程序将显示“用户'contoso/user1'登录失败”错误消息。

    解决 方案： 数据库管理员可以通过检查 SQL Server Management Studio (SSMS) 中的 “安全>登录名” 文件夹来检查这种情况。 如果数据库是包含的数据库，请在 下 databasename检查 。 有关详细信息，请参阅用户“username>”的登录失败或用户“<domain>\<username>”<的登录失败。

  • 凭据防护已启用 - 此方案指示在 Windows 系统上启用了 Credential Guard 功能，并用于创建用于存储敏感信息的安全环境。 但是，在某些情况下，此功能可能会导致身份验证问题。

    解决 方案： 若要解决此问题，请要求域管理员设置约束委派。 有关详细信息，请参阅 使用 Credential Guard 时的注意事项和已知问题。

  • 本地安全子系统错误 - 遇到本地安全子系统错误时，尤其是那些链接到 LSASS 的错误变得无响应时，它可能表明影响身份验证的基础问题。

    解决 方案： 若要解决这些错误，请参阅 SQL Server 中的本地安全子系统错误。

  • 不允许网络登录 - 当你尝试登录到网络，但登录请求因某些原因被拒绝时，会出现这种情况。

    解决 方案： 若要解决此问题，请参阅 用户没有登录到网络的权限。

  • 只有管理员才能登录 - 如果计算机上的安全日志已满且没有足够的空间来填充事件，则会出现此问题。 系统管理员使用 安全功能 CrashOnAuditFail 来检查所有安全事件。 的有效值为 CrashOnAuditFail0、 1 和 2。 如果 的 CrashOnAuditFail 密钥设置为 2，则表示安全日志已满，并显示“只有管理员才能登录”错误消息。

    解决 方案： 若要解决此问题，请执行以下步骤：

    1. 启动注册表编辑器。
    2. 找到并检查 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail 子项，查看值是否设置为 2。 此值指示安全日志需要手动清除。
    3. 将值设置为 0，然后重启服务器。 可能还需要更改安全日志，使事件能够滚动更新。 有关设置如何影响所有服务（如 SQL、IIS、文件共享和登录名）的详细信息，请参阅 安全事件日志已满时用户无法访问网站。

    注意

    此问题仅影响集成登录名。 命名管道连接也会在 SQL Server 登录名中受到影响，因为命名管道在连接到 SQL Server 之前首先登录到 Windows Admin Pipe。

  • 委托不信任服务帐户 - 如果不允许服务帐户将凭据分配给其他服务器，则通常会发生此类问题。 此问题可能会影响需要委派的服务。

    解决 方案： 如果未启用委派方案，请检查 SQL Server secpol.msc 以确定 SQL Server 服务帐户是否在身份验证安全策略设置 后“本地策略 > 用户权限分配 > 模拟客户端 ”下列出。 有关详细信息，请参阅启用要信任委派的计算机和用户帐户。

  • 无法在 SQL Server 中加载 Windows 用户配置文件 - 指 Windows 用户配置文件问题。

    解决 方案： 有关如何排查用户配置文件损坏问题的详细信息，请参阅 无法在 SQL Server 中加载 Windows 用户配置文件。

其他方面

本部分列出了与 Web 环境中的身份验证和访问控制相关的问题：

  • 集成身份验证未启用 - 指未正确配置集成 Windows 身份验证 (IWA) 的配置问题。

    解决 方案：若要解决此问题，请确保在“Internet 选项”设置中启用了“集成 Windows 身份验证”选项。

  • 不允许 IIS 身份验证 - 出现此问题的原因是 IIS 中的错误配置。 在 Web 应用程序的 Web.config 文件中定义的身份验证设置可能与 IIS 中配置的设置冲突。 这种情况可能会导致身份验证问题。

    解决 方案： 若要解决此问题，请将网站配置为启用 Windows 身份验证， <identity impersonate="true"/> 并在 Web.config 文件中设置 值。

  • 错误的 Internet 区域 - 如果尝试访问不在 Internet Explorer 中正确 Internet 区域中的网站，则可能会出现此问题。 如果网站位于本地 Intranet 区域，则凭据将不起作用。

    解决 方案： 将 Web 服务器添加到 IE 的本地 Intranet 区域。

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。

更多信息

收集数据以排查 SQL Server 连接问题