MSSQLSERVER_18456
适用于：
SQL Server
详细信息
| 属性 | 值 |
|---|---|
| 产品名称 | SQL Server |
| 事件 ID | 18456 |
| 事件来源 | MSSQLSERVER |
| 组件 | SQLEngine |
| 符号名称 | LOGON_FAILED |
| 消息正文 | 用户 '%.*ls'.%.*ls 登录失败 |
说明
由于身份验证失败而拒绝连接尝试时，会收到此错误消息。 由于多种原因，用户登录失败，例如凭据无效、密码过期和启用错误的身份验证模式。 在许多情况下，错误代码包括说明。
用户操作
以下示例是一些常见的登录失败。 选择你遇到的确切错误来排查问题：
用户“username>”<登录失败，或者用户“domain>\<username>”<登录失败
如果未指定域名，则问题在于 SQL Server 登录尝试失败。 如果指定了域名，则问题在于 Windows 用户帐户登录失败。 有关潜在原因和建议的解决方案，请参阅：
| 可能原因 | 建议的解决方法 |
|---|---|
| 你尝试使用 SQL Server 身份验证，但 SQL Server 实例已配置为 Windows 身份验证模式。 | 验证 SQL Server 是否已配置为使用 SQL Server 和 Windows 身份验证模式。 可以在 SQL Server Management Studio（SSMS）中相应实例的属性下的“安全”页上查看和更改 SQL Server 实例的身份验证模式。 有关详细信息，请参阅更改服务器身份验证模式。 或者，可以将应用程序更改为使用 Windows 身份验证模式 连接到 SQL Server。 注意：在此方案中，可以在 SQL Server 错误日志中看到如下消息： Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| 尝试通过组访问 SQL Server，并看到错误消息。 | 如果没有访问服务器所需的权限，提供程序会显示“用户”contoso/user1 登录失败“错误消息。 使用“通过组访问”功能，该功能可帮助你基于组成员身份访问服务器。 运行 xp_logininfo 'contoso/user1' 存储过程时，可能会发生以下情况：- 如果看到错误，SQL Server 根本无法解析用户名。 很可能 Active Directory（AD）中不存在名称，或者连接到域控制器（DC）时可能会出现问题。 尝试使用其他名称来检查问题是否特定于特定帐户。 - 如果要连接到跨域服务器，则组必须位于 SQL Server 域中，而不是用户域，以便可以解析其成员身份。 - 当数据库查询不返回任何行时，这意味着没有提供对服务器的访问的组。 当查询返回一个或多个行时，这意味着用户属于提供访问权限的组。 DBA 可以通过检查 SQL Server Management Studio （SSMS） 中的 Security\Logins 文件夹来仔细检查权限。 Security\Logins 显示已创建的登录名列表。 如果它是包含的数据库，DBA 可以在数据库名称下检查 Security\Logins ，以检查和管理登录名。 有关详细信息，请参阅“配置用户访问控制和权限”。 |
| 未启用 SQL 登录名 | 数据库管理系统（DBMS）可能会显示消息的 Login failed for user '<username>' 一些变化。 若要解决此错误，请执行以下步骤：1.检查 SQL Server 错误日志是否包含错误消息“用户'<用户名>登录失败”。 原因：尝试使用 SQL 身份验证登录失败。 服务器仅配置为Windows 身份验证。” 2.使用以下方法之一解决错误： - 使用集成登录名。 例如，对于 OLE DB 提供程序，请添加到 INTEGRATED SECURITY=SSPI连接字符串，对于 ODBC 驱动程序，请添加 TRUSTED_CONNECTION=YES。 .NET 提供程序接受任一语法。注意： 如果它们未正确配置为允许集成身份验证，并且需要作为单独的问题进行调查，则可能会导致其他问题。 - 在服务器上启用 SQL 登录名： a. 在 SQL Server Management Studio 中，右键单击对象资源管理器中的 SQL Server 名称，然后选择“属性”。 b. 在 “安全 ”窗格中，选择 SQL Server 和 Windows 身份验证 模式。 c. 选择“确定”。 d. 重启 SQL Server，使更改发生。 注意： 这可能会导致其他问题，例如定义 SQL 登录名。 - 尝试为用户名指定本地 Windows 帐户或域帐户。 仅允许 SQL 登录名。 应用程序应使用集成安全性。 |
| 尝试连接到的 SQL Server 实例上不存在登录名。 | 验证 SQL Server 登录名是否存在且拼写正确。 如果登录不存在，请创建。 如果存在但拼写错误，请更正应用程序中连接字符串。 SQL Server Errorlog 将包含以下消息之一： - Login failed for user 'username'. Reason: Could not find a login matching the name provided.- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.如果将使用 DEV 或 QA 服务器的应用程序部署到生产环境，并且无法更新连接字符串，则这是一个常见问题。 若要解决此问题，请验证是否连接到相应的服务器。 如果不是，请璨正连接字符串。 如果是，请授予对 SQL Server 的登录访问权限。 或者，如果是 Windows 登录名，则直接授予访问权限，或将其添加到允许连接到数据库服务器的本地或域组。 有关详细信息，请参阅 创建登录名。 |
| 你使用的是 SQL Server 身份验证，但为 SQL Server 登录指定的密码不正确。 | 检查 SQL 错误日志中是否存在“原因：密码与提供的登录名不匹配”等消息以确认原因。 若要解决此问题，请在应用程序中使用正确的密码，或者如果忘记密码，请使用其他帐户。 或者，请与 SQL Server 管理员协作重置帐户的密码。 如果应用程序是 SQL Server Integration Services （SSIS），则作业可能有多个级别的配置文件，这可能会覆盖包的连接管理器设置。 如果应用程序是由公司编写的，并且以编程方式生成连接字符串，请让开发团队解决问题。 作为临时解决方法，对连接字符串进行硬编码并测试。 使用 UDL 文件或脚本来证明可以通过硬编码连接字符串建立连接。 |
| 连接字符串语法、服务器名称或用户凭据不正确。 | 若要解决此问题，请执行以下操作：
|
| 无登录名 | 检查 SQL Server 是否显示以下消息：Logon Error: 18456, Severity: 14, State: 11.Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]某些错误属于匿名登录帐户。 这与 Kerberos 问题相关。 HOSTS 文件中存在错误的手动条目，即给定了错误的服务器名称。 其余问题可能分为以下类别：
|
| 你尝试使用 Windows 身份验证 进行连接，但已登录到不正确的域。 | 验证是否已正确登录到正确的域。 错误消息通常显示域名。 |
| 检查数据库权限 | 数据库不会在 SQL Server Management Studio 中脱机显示。 其他用户，例如 DBA 能够连接到它。 必须向有问题的用户帐户授予对数据库的显式访问权限，或被添加到 SQL Server 角色或有权访问数据库的本地 Windows 组或域组。 有关详细信息，请参阅 CREATE USER、 ALTER ROLE 和 ALTER SERVER ROLE |
| 你未以管理员身份运行应用程序（例如 SSMS）。 | 如果尝试使用管理员凭据进行连接，请使用“以管理员身份运行”选项启动应用程序。 在连接后，将您的 Windows 用户作为单独的登录名添加。 |
| 迁移到包含的数据库用户后，将删除登录名。 | 如果数据库引擎支持包含的数据库，请确认在迁移到包含的数据库用户后未删除该登录名。 有关详细信息，请参阅 包含的数据库身份验证：简介。 |
| 登录名的默认数据库处于脱机状态，否则不可用。 | 请与 SQL Server 管理员联系并解决与数据库可用性相关的问题。 如果登录名有权访问服务器上的其他数据库，并且无需访问应用程序中当前配置的默认数据库，请使用以下选项之一： - 请求管理员使用 ALTER LOGIN 语句或 SSMS 更改登录的默认数据库。 - 在应用程序中显式指定不同的数据库连接字符串。 或者，如果使用 SSMS 切换到 “连接属性 ”选项卡来指定当前可用的数据库。SSMS 等应用程序可能会显示如下错误消息： Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)SQL Server Errorlog 将有如下所示的错误消息： Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]有关详细信息，请参阅 MSSQLSERVER_4064。 |
| 在 连接字符串 或 SSMS 中显式指定的数据库拼写错误、脱机或不可用。 | - 修复连接字符串中的数据库名称。 如果在服务器上使用区分大小写的排序规则，请注意区分大小写。 - 如果数据库名称正确，请与 SQL Server 管理员联系并解决与数据库可用性相关的问题。 检查数据库是否处于脱机状态、未恢复等。 - 如果登录名已映射到具有服务器上其他数据库权限的用户，并且无需访问应用程序中当前配置的数据库，请在连接字符串中指定其他数据库。 或者，如果要使用 SSMS 进行连接，请使用“ 连接属性 ”选项卡指定当前可用的数据库。 SQL Server Errorlog 将有如下所示的错误消息： Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]注意：如果登录名的默认数据库可用，SQL Server 允许连接成功。 有关详细信息，请参阅 MSSQLSERVER_4064。 |
| 用户无权访问请求的数据库。 | - 尝试作为另一个具有 sysadmin 权限的用户进行连接，以查看是否可以建立连接。 - 通过创建相应的用户（例如， CREATE USER [<UserName>] FOR LOGIN [UserName]）授予对数据库的登录访问权限 |
此外，请查看故障排除错误 18456 中的大量错误代码列表。
有关更多故障排除帮助，请参阅 SQL 客户端/服务器连接问题疑难解答。
用户 NT AUTHORITY\ANONYMOUS LOGON 登录失败
此问题至少有四种方案。 在下表中，检查每个适用的潜在原因，并使用适当的解决方法：请参阅下表下面的说明，了解术语 双跃点的说明。
| 可能的原因 | 建议的解决方案 |
|---|---|
| 尝试将 NT LAN 管理器 （NTLM） 凭据从一个服务传递到同一台计算机上的另一个服务（例如：从 IIS 到 SQL Server），但在此过程中发生失败。 | 添加 DisableLoopbackCheck 或 BackConnectionHostNames 注册表项。 |
| 跨多台计算机存在 双跃点 （约束委派）方案。 如果 Kerberos 连接因服务主体名称（SPN）问题而失败，则可能会出现此错误。 | 在每个 SQL Server 和 Web 服务器上运行 SQLCheck 。 使用故障排除指南： 0600 凭据委派问题和 0650 SQL Server 链接服务器委派问题。 |
| 如果没有涉及双跃点（约束委派），则可能存在重复的 SPN，并且客户端作为 LocalSystem 或其他获取 NTLM 凭据而不是 Kerberos 凭据的计算机帐户运行。 | 使用 SQLCheck 或 Setspn.exe 诊断和修复任何 SPN 相关问题。 另请查看 适用于 SQL Server 的 Kerberos Configuration Manager 概述。 |
| Windows 本地安全策略可能已配置为阻止计算机帐户用于远程身份验证请求。 | 导航到本地安全策略本地策略>>安全选项>网络安全：允许本地系统使用 NTLM 的计算机标识，如果禁用设置，请选择“已启用”选项，然后选择“确定”。 注意：如“ 说明 ”选项卡上的详细信息，默认情况下，此策略在 Windows 7 及更高版本中启用。 |
| 使用约束委派时出现此问题的间歇性事件可能表示中间层无法续订的过期票证。 这是具有链接服务器方案或任何持有登录会话超过 10 小时的应用程序的预期行为。 | 将中间层服务器上的委派设置从信任此计算机更改为仅委派到指定服务 - 仅使用 Kerberos 仅信任此计算机以委派到指定服务 - 使用任何协议。有关详细信息，请参阅 SQL Server 链接服务器双跃点的间歇性匿名登录。 |
| NTLM 对等登录 | 此错误与 Microsoft Windows OS 使用的 NTLM 身份验证协议相关。 在工作站或不相互信任的域中的计算机之间通信时，可以在两台计算机上设置相同的帐户并使用 NTLM 对等身份验证 NTLM 对等身份验证 NTLM 对等登录名。 仅当用户帐户和密码都匹配这两台计算机时，登录才起作用。 |
| 环回保护 | 环回保护旨在禁止应用程序在同一台计算机上调用其他服务。 可以设置 DisableLoopbackCheck 或 BackConnectionHostNames （首选）注册表项以允许此操作。 有关详细信息，请在安装 Windows Server 2003 Service Pack 1 后尝试使用其 FQDN 或其 CNAME 别名在本地访问服务器时看到 错误消息：访问被拒绝或未接受给定网络路径的网络提供程序。 |
| Always-On 侦听器环回保护 | 从主节点连接到 Always-On 侦听器时，连接将为 NTLM。 这将参与环回检查，并导致“登录失败”错误，指出用户来自不受信任的域。 若要解决此错误，请在可用性组中的所有计算机上键入侦听器 NETBIOS 名称和完全限定的名称 BackConnectionHostNames 。 有关详细信息，请在安装 Windows Server 2003 Service Pack 1 后尝试使用其 FQDN 或其 CNAME 别名在本地访问服务器时看到 错误消息：访问被拒绝或未接受给定网络路径的网络提供程序。 |
| LANMAN 兼容性级别 | 这通常发生在较旧的计算机（Windows 2008 之前的）与较新的计算机之间。 在所有计算机上将 LANMAN 兼容性级别设置为 5 。 这也不允许 NTLM v1。 还可以切换到 Kerberos 以避免此问题。 |
| 敏感帐户 | 某些帐户可能在 Active Directory 中标记为敏感。 这些帐户无法在双跃点方案中委托给另一个服务。 |
| 不是受约束的目标 | 如果为特定服务帐户启用了约束委派，则如果目标服务器的 SPN 不在受约束委派的目标列表中，Kerberos 将失败。 |
| Per-Service-SID | 此功能将本地连接限制为使用 NTLM，而不是 Kerberos 作为身份验证方法。 该服务可以使用 NTLM 凭据向另一台服务器发出单个跃点，但在不使用约束委派的情况下无法进一步委派该服务。 |
| NTLM 和约束委派 | 如果目标为文件共享，则中间层服务帐户的委派类型必须为“约束-Any”，而不是“约束-Kerberos”。 |
注意
双跃点通常涉及跨多个远程计算机委派用户凭据。 例如，假设你有一个名为 SQL1 的 SQL Server 实例，在其中为名为 SQL2 的远程 SQL Server 创建了链接服务器。 在链接服务器安全配置中，你选择了使用登录名的当前安全上下文进行的选项。 使用此配置时，如果从名为 Client1 的远程客户端计算机对 SQL1 执行链接服务器查询，则 Windows 凭据首先必须从 Client1 跳到 SQL1，然后从 SQL1 跳到 SQL2（因此，它称为双跃点）。 有关详细信息，请参阅 了解 Kerberos 双跃点 和 Kerberos 约束委派概述
用户登录失败（空）
当用户尝试登录失败时，会发生此错误。 如果计算机未连接到网络，则可能会发生此错误。 例如，你可能会收到类似于以下错误消息：
Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain 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.
空字符串表示 SQL Server 试图将凭据移交给本地安全机构子系统服务（LSASS），但由于某些问题，无法执行此操作。 LSASS 不可用，或者无法联系域控制器。
可能还会看到以下相应的 SSPI 错误代码：
SSPI 握手失败，错误代码0x80090311，同时与集成安全性建立连接;连接已关闭。
在建立具有集成安全性的连接时，SSPI 握手失败，错误代码0x80090304;连接已关闭。
这些错误代码如下所示：
错误 -2146893039（0x80090311）：无法联系颁发机构进行身份验证。 错误 -2146893052 （0x80090304）：无法联系本地安全机构。
若要解决这些错误，可以将有问题的 DC 脱机，或使用 NLTEST.EXE 来切换 DC。
- 若要查询 DC，请运行 NLTEST /SC_QUERY:CONTOSO 命令。
- 若要更改 DC，请运行 NLTEST /SC_RESET:CONTOSO\DC03 命令。
如果需要进一步的帮助，请联系 Microsoft Active Directory 团队。
检查客户端和服务器上的事件日志，了解在故障发生时记录的任何与网络相关的或 Active Directory 相关的消息。 如果发现任何问题，请与域管理员协作来解决问题。
用户“（null）”登录失败
指示“null”可能意味着 LSASS 无法使用 SQL Server 服务帐户凭据解密安全令牌。 此条件的主要原因是 SPN 与错误的帐户相关联。
要解决该问题，请执行以下步骤：
使用 SQLCheck 或Setspn.exe诊断和修复 SPN 相关问题。
使用 SQLCheck 检查是否信任 SQL 服务帐户进行委派。 如果输出指示帐户不受信任进行委派，请与 Active Directory 管理员合作，为帐户启用委派。
注意
用于SETSPN -X-Q检查重复 SPN 或错放 SPN 的有用命令。
诊断和修复域名系统（DNS）名称解析问题。 例如：
使用 PowerShell 脚本 Ping IP 地址：
ping -a <your_target_machine>-4（专用于 IPv4 和-6IPv6）ping -a <your_remote_IPAddress>
使用 NSLookup 多次输入本地和远程计算机名称和 IP 地址。
在返回的结果中查找任何差异和不匹配。 网络上 DNS 配置的准确性对于成功的 SQL Server 连接非常重要。 不正确的 DNS 条目可能会导致以后出现许多连接问题。
确保防火墙或其他网络设备不会阻止客户端连接到域控制器。 SPN 存储在 Active Directory 中。 如果客户端无法与目录通信，则连接无法成功。
其他错误信息
为了增强安全性，返回到客户端的错误消息有意隐藏身份验证错误的本质。 但是，在 SQL Server 错误日志中，相应的错误包含映射到身份验证失败条件的错误状态。 将错误状态与以下列表进行比较以确定登录失败的原因。
| 状态 | 说明 |
|---|---|
| 1 | 错误信息不可用。 此状态通常意味着你无权接收错误详细信息。 有关详细信息，请联系 SQL Server 管理员。 |
| 2 | 用户 ID 无效。 |
| 5 | 用户 ID 无效。 |
| 6 | 尝试同时使用 SQL Server 身份验证与 Windows 登录名。 |
| 7 | 登录已禁用，密码不正确。 |
| 8 | 密码不正确。 |
| 9 | 密码无效。 |
| 11 | 登录有效，但服务器访问失败。 此错误的一个可能原因是 Windows 用户作为本地管理员组的成员有权访问 SQL Server，但 Windows 不提供管理员凭据。 若要连接，请使用 “以管理员 身份运行”选项启动连接程序，然后将 Windows 用户作为特定登录名添加到 SQL Server。 |
| 12 | 登录是有效的登录，但服务器访问失败。 |
| 18 | 必须更改密码。 |
| 38、46 | 找不到用户请求的数据库。 |
| 58 | 将 SQL Server 设置为仅使用 Windows 身份验证，而客户端尝试使用 SQL 身份验证登录时。 另一个原因是 SID 不匹配。 |
| 102 - 111 | Azure AD 故障。 |
| 122 - 124 | 由于用户名或密码为空导致的失败。 |
| 126 | 用户请求的数据库不存在。 |
| 132 - 133 | Azure AD 故障。 |
存在其他错误状态，并表示一个意外的内部处理错误。
更罕见的原因
尝试使用 SQL 身份验证登录失败的错误原因。服务器仅针对Windows 身份验证进行配置。在以下情况下可以返回。
当服务器配置为混合模式身份验证，ODBC 连接使用 TCP 协议时，连接不会显式指定连接应使用受信任的连接。
为混合模式身份验证配置 SQL Server 时，ODBC 连接使用命名管道，并且用于打开命名管道的客户端用于自动模拟用户的凭据，并且连接字符串不会显式指定使用受信任的身份验证。
若要解决此问题，应在连接字符串中包含 TRUSTED_CONNECTION = TRUE。
示例
在此示例中，身份验证错误状态为 8。 这表示密码不正确。
| 日期 | Source | 消息 |
|---|---|---|
| 2007-12-05 20:12:56.34 | 登录 | 错误: 18456，严重性: 14，状态: 8。 |
| 2007-12-05 20:12:56.34 | 登录 | 用户“user_name>”<登录失败。 [CLIENT： <ip address>] |
注意
使用 Windows 身份验证模式安装 SQL Server 后，将更改为 SQL Server 和 Windows 身份验证模式时， 最初禁用 sa 登录名。 这会导致状态 7 错误：“用户'sa'登录失败”。若要启用 sa 登录名，请参阅 “更改服务器身份验证模式”。