SQL Server在Windows应用程序中返回错误“登录失败，用户为'NT AUTHORITY\ANONYMOUS LOGON'。”

Question

SQL Server在Windows应用程序中返回错误“登录失败，用户为'NT AUTHORITY\ANONYMOUS LOGON'。”

82

一款长期正常运行的应用程序（大约已经有6个月左右没有进行任何活跃的开发），最近开始连接数据库时出现了问题。运维管理员无法确定可能导致这个问题的原因。客户端应用程序使用硬编码的连接字符串，并带有Integrated Security=True，但当应用程序尝试创建到数据库的连接时，它会抛出一个SQLException，显示“Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON”。我可以使用这个账户在Management Studio中登录数据库而没有问题。关于这个问题，我看到的所有东西都是针对ASP.NET项目的，并且显然是“双跳问题”，但客户端应用程序理当不会出现这个问题。如果有任何帮助，将不胜感激。

编辑: 客户端机器和服务器机器以及用户帐户都在同一个域中。这种情况发生在Windows防火墙关闭的情况下。领先的理论是：服务器大约在一周前重新启动，并未注册服务主体名称（SPN）。未注册SPN可能会导致集成身份验证退回到NTLM而不是Kerberos。

- CodeWarrior

10个回答

10

首先，我的问题并非与您完全相同，但这篇文章是我在撰写时通过谷歌搜索“Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'”出现的第一篇文章。本文的解决方案可能会对像我一样在网上没有找到特定解决方案的人有用。

在我的情况下，在使用Xampp/Apache和PHP sqlsrv尝试使用Windows身份验证连接到MSSQL数据库时，我收到了您所描述的“Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'”错误。最终我发现问题在于Apache服务本身是以“LOCAL SERVICE”用户而不是我登录的用户帐户运行的。换句话说，它实际上在使用匿名帐户。解决方法是进入services.msc，右键单击Apache服务，转到属性，然后进入登录选项卡，并输入用户的凭据。这与您与SPN相关的问题相关，因为您的SPN设置为从域上的特定用户运行。因此，如果正确的SPN未运行，Windows身份验证将默认为错误的用户（可能是“LOCAL SERVICE”用户），并给您提供匿名错误。

这里与您的问题不同之处在于，本地网络上的计算机都不属于域，它们只属于工作组。要在工作组中使用Windows身份验证，服务器（在我的情况下是MSSQL Server）和请求数据的服务所在的计算机（在我的情况下是Apache）都需要具有相同名称和相同密码的用户。

总之，我们两个案例中的“Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'”错误似乎是由于未运行和/或不在正确用户上的服务引起的。确保正确的SPN或其他服务正在运行并在正确的用户下，应该解决问题的匿名部分。

- Caboosetp

6

我已经得到了答案，所以我认为将它放在谷歌上搜索的人会很有帮助。许多其他论坛都有类似问题的帖子，链接到这篇文章并得到了不同的回复，因此我想要帮助解决这些问题，即添加相关信息和可能的解决方案而非请求帮助。 - Caboosetp

感谢您发布这篇文章，它让我找到了一个安装程序失败的原因（一个自定义操作尝试连接到 SQL，而对于 VS 安装程序，默认情况下自定义操作在 SYSTEM 下运行）。 - Paul

非常感谢 @Caboosetp！我在连接MSSQL数据库时遇到了麻烦，而你解决了它。 - Arnaud Stephan

6

我认为在用于对数据库进行身份验证的AD组中一定发生了一些更改。将Web服务器名称以domain\webservername$的格式添加到具有访问数据库权限的AD组中。此外，还尝试将web.config属性设置为“false”。希望这可以帮助解决问题。

编辑：根据您所做的编辑，很可能表明您的SQL Server的身份验证协议已从Kerberos（如果您使用Windows集成身份验证，则为默认值）回退到NTLM。要使用Kerberos，必须在Active Directory目录服务中注册服务主体名称（SPN）。 Service Principal Name（SPN）是运行在服务器上的服务的唯一标识符。每个将使用Kerberos身份验证的服务都需要为其设置一个SPN，以便客户端可以在网络上识别服务。它在计算机帐户或用户帐户下在Active Directory中注册。虽然Kerberos协议是默认值，但如果默认值失败，将尝试使用NTLM进行身份验证过程。

在您的情况下，客户端必须进行TCP连接，并且最有可能在LocalSystem帐户下运行，并且没有为SQL实例注册SPN，因此使用了NTLM，但是，LocalSystem帐户继承自系统上下文而不是真正的基于用户的上下文，因此失败为“ANONYMOUS LOGON”。

要解决此问题，请请求您的域管理员手动注册SPN，如果您的SQL Server在域用户帐户下运行。以下链接可能会更有帮助：
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801

- Saurabh R S

实际上，经过更深入的挖掘，看起来这是一个链接服务器的问题。我们进行了一些人事变动，出于安全考虑，服务器帐户被更改了。客户端应用程序的首要任务是查询具有到所有其他服务器的链接的视图。在Management Studio中运行该查询会导致相同的错误消息。我们现在正在调整链接。 - CodeWarrior

5

您可能只需在连接字符串中提供用户名和密码，并将Integrated Security设置为false。

- shabber

请参见上面的被接受的答案。问题出在链接服务器和SPN上。 - CodeWarrior

4

尝试在连接字符串中设置 "Integrated Security=False"。

<add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/>

- Ummer Irshad

2

我的一个SQL作业也遇到了同样的问题。它涉及从一个服务器上传数据到另一个服务器。错误发生的原因是我使用了SQL Server代理服务帐户。我创建了一个凭据，使用了一个对所有服务器都通用的用户ID（使用Windows身份验证）。然后使用此凭据创建了一个代理。在SQL Server作业中使用代理，现在正常运行。

- Vipul

2

顺便提一句，在我们的情况中，一个运行在IIS上的(PHP)网站在尝试连接数据库时显示了这个消息。

解决方法是编辑该网站上的匿名身份验证方式，使用应用程序池标识(同时我们设置了应用程序池入口，使用专门针对该网站设计的服务账户)。

注：FWIW意为"For What It's Worth"，意为"值得一提"。

- youcantryreachingme

这也可能发生在IIS中。在_IIS管理器_中，选择应用程序，双击其身份验证图标，单击编辑链接，在编辑模态中选择“应用程序池标识”单选按钮，单击确定，获得利润。 - ruffin

1

类似的案例已经解决：

我们的情况是，我们想要使用cnames设置链接服务器，并使用当前安全上下文的登录。

为了一切顺利，我们检查了运行SQL Server的服务帐户是否有其适当的spns设置，并且AD对象是否受信任进行委派。但是，尽管我们能够直接连接到cname，但仍然存在在其cname上调用链接服务器的问题：用户“NT AUTHORITY\ANONYMOUS LOGON”的登录失败。

我们花费了太长时间才意识到我们使用的cnames是针对更高级别的dns设置的A记录[A]，而不是在其自己的域AD级别中。最初，我们将cname定向到[A].example.com而不是（应该）到：[A].domain.ad.example.com

当然，我们会遇到关于匿名登录的这些错误。

- dba

0

只需前往应用程序池，选择高级设置中的进程模型，然后选择身份验证，在身份验证中设置您的帐户详细信息，例如系统的用户名和密码。

- Ajit Kumar Pandey

-1

明白了！通过修改 SQL Server 安全会话中用户属性解决了问题。在 SQL Server Management 中，进入安全性 -> 登录 -> 选择用于数据库连接的用户并进入其属性。转到“保护程序”选项卡，查找“连接 SQL”的行，标记“授予”选项并尝试。对我有效！

此致敬礼

- Luiz Gustavo David Ferreira

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Code Magician · Accepted Answer

如果您的问题与链接服务器有关，您需要查看一些内容。

首先，您的用户需要启用委派，如果唯一更改的是这个，那么他们可能已经启用了。否则，您可以在AD中的用户属性中取消选中“帐户是敏感的，不能进行委派”复选框。

其次，您的服务帐户必须受信任以进行委派。由于您最近更改了服务帐户，我怀疑这是罪魁祸首。（http://technet.microsoft.com/en-us/library/cc739474(v=ws.10).aspx）

您提到可能存在一些SPN问题，因此请务必为两个端点设置SPN，否则您将无法在AD中看到委派选项卡。还要确保您在“活动目录用户和计算机”中处于高级视图。

如果即使在纠正了SPN后仍然看不到委派选项卡，请确保您的域不处于2000模式。如果是，则可以“提高域功能级别”。

此时，您现在可以将帐户标记为受信任以进行委派：

在详细信息窗格中，右键单击您想要委派信任的用户，然后单击“属性”。单击“委派”选项卡，选择“帐户已被信任以进行委派”复选框，然后单击“确定”。最后，您还需要将所有机器设置为受信任的委派。完成此操作后，请重新连接到您的SQL服务器并测试您所喜欢的服务器。它们应该可以正常工作。