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

适用范围：SQL Server

注意

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

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

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

先决条件

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

• 安装 WireShark 和问题步骤记录器（PSR.exe）工具。 有关详细信息，请参阅 收集数据的方法，以排查各种类型的错误。

• 收集基于服务帐户的服务提供程序名称（SPN）信息。 为此，请使用 SETSPN -L 命令。

错误的类型

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

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

一致的身份验证问题类型

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

连接字符串

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

• 缺少显式 SPN - 如果未正确配置或注册 SPN，则会出现此问题。

  解决方案：若要解决此问题，请参阅使用 Windows 身份验证连接 SQL Server 时出现“无法生成 SSPI 上下文”错误。

• 显式错放的 SPN - 指与特定服务或帐户错误关联的 SPN 。

  解决方案： 若要解决此问题，请参阅 显式错放的 SPN。

• 显式 SPN 重复 - 如果 SPN 重复，因为多次注册 SPN，则会出现此问题。

  解决方案：若要解决此问题，请参阅使用 Windows 身份验证连接 SQL Server 时出现“无法生成 SSPI 上下文”错误。

• 连接字符串中的服务器名称不正确 - 如果指定的服务器名称不正确或找不到，则会出现此问题。

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

• 连接字符串中的数据库名称错误 - 如果为身份验证提供的数据库名称不正确，则会出现此问题。

  解决方案： 检查名称拼写是否正确。 有关详细信息，请参阅 MSSQLSERVER_4064。

• 错误的显式 SPN 帐户 - 如果 SPN 与 AD DS 中的错误帐户相关联，则可能会出现此问题。

  解决方案： 若要解决此问题，请参阅 “无法生成 SSPI 上下文错误”。

Database

本部分列出了特定于 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 代理服务帐户可以提供的权限以外的权限。

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

• 无法登录到 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），而不是完全限定的域名（例如，SQLPROD01.CONTOSO.COM），则可能会出现此问题。 发生这种情况时，可能会追加错误的 DNS 后缀。

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

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

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

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

  解决方案： 若要解决此问题，请参阅 用户 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 的登录失败。

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

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

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

• 限制对 Access 或 Excel 的委派权限 - 联合引擎技术 （JET） 和 Access 连接引擎 （ACE） 提供程序类似于任何文件系统。 必须使用约束委派使 SQL Server 能够读取位于另一台计算机上的文件。 一般情况下，ACE 提供程序不应在链接服务器中使用，因为此提供程序明确不受支持。 JET 提供程序已弃用，仅在 32 位计算机上可用。

  注意

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

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

  解决方案：有关详细信息，请参阅修复 Kerberos Configuration Manager 的错误（建议）。

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

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

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

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

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

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

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

  解决方案： 使用 TCP 连接允许 Kerberos 身份验证。 还可以使用较新的驱动程序（例如 MSOLEDBSQL 或 ODBC 驱动程序 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 凭据失败;如果 SSPI 凭据无意中与另一台服务器的 SPN 匹配，则会导致 SSPI 失败。

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

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

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

• 使用网站主机标头 - HTTP 主机标头在访问网页的 HTTP 协议中扮演了非常重要的角色。

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

NT LAN 管理器 （NTLM）

本部分列出了特定于 NTLM 的问题（NT LAN 管理器）：

• 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 之前的 Windows Server 2008）和新计算机使用的身份验证协议中存在不匹配，则通常会发生 LAN 管理器（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。 有关详细信息，请参阅用户“用户名>”<登录失败，或者用户“domain>\<username>”<登录失败。

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

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

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

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

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

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

• 只有管理员可以登录 - 如果计算机上的安全日志已满且没有足够的空间来填充事件，则会出现此问题。 系统管理员使用安全功能 CrashOnAuditFail 检查所有安全事件。 有效值为 CrashOnAuditFail 0、 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 身份验证并在 Web.config 文件中设置<identity impersonate="true"/>值。

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

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

第三方信息免责声明

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

详细信息

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