Question

我的日志中有错误几周，我搜索了很多，但我找不到有用的答案。

我为公共IP关闭了SQL Server端口，但我还有问题。

错误：17806，严重性：20，状态：14   SSPI握手失败，错误代码为0x8009030c，状态为14，同时建立与集成安全性的连接;连接已关闭。原因：AcceptSecurityContext失败。 Windows错误代码指示失败的原因。登录尝试失败[客户端：10.10.3.25]

提出时间：2015年1月27日下午2:23

此系统关闭时出现错误。

Answer 1

情景 - 在尝试连接时，几个单独的Windows ID开始生成这些错误，所有其他Windows登录都正常工作。这些连接最初是通过应用程序进行的，但也是通过sqlcmd进行的。使用违规ID在本地登录服务器时，与SQL的连接将成功。

故障排除流程 - 检查所有常规的SSPI问题，我不会厌烦你的细节，因为它们很容易搜索

检查“简单”身份验证问题的一种相对简单的方法如果可能/适当的话是使用违规ID在本地登录SQL Server并启动sqlcmd并通过sqlcmd -Sservername连接到服务器，端口-E（通过指定强制TCP / IP而不是LPC的端口，从而强制网络进入等式）验证登录是否尝试使用NTLM或Kerberos（许多方法可以执行此操作，但最简单的方法是查看计算机上是否还有其他KERBEROS连接）

SELECT DISTINCT auth_scheme FROM sys.dm_exec_connections

如果正在使用Kerberos，还需要验证一些与SPN相关的其他内容，因为在此服务器上只使用了NTLM我跳过了通过组策略或其他AD设置确定帐户是否被排除在通过网络连接到计算机

在所有这些检查完毕后，我开始尝试找出错误代码0x8009030c的含义，事实证明，相当明显的描述是什么：sec_e_logon_denied。这个描述非常有用，我想把这个服务器变成船锚，但幸运的是，对于我的雇主来说，服务器机房位于很远的地方，并且有武装警卫。

因为我知道我们可以使用SQL拒绝登录的ID在本地登录到SQL Server，否则其他东西试图让我的生活变得悲惨。

我们没有启用登录失败安全审核，所以我无法获得更好的错误描述，幸运的是，虽然这有助于找到根本原因。为了获得更好的错误消息，我发现这篇方便的知识库文章详细说明了将网络登录置于调试模式所需的步骤。

跟我新朋友打招呼吧！ - nltest.exe 下载nltest＆amp;使用它来启用SQL Server上的netlogon调试，我在netlogon.log文件中得到了这个稍微好一点的消息

06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAIN\USER from Laptop Entered

06/15 14:15:39 [CRITICAL] NlPrintRpcDebug: Couldn’t get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064)

06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAIN\USER from Laptop Returns 0xC0000064

The error code 0XC0000064 maps to “NO_SUCH_USER”

Since I was currently logged in to the server with the ID that was returning no such user, something else was obviously wrong, and luckily at this point I knew it wasn’t SQL.

Running “set log” on the server revealed that a local DC (call it DC1) was servicing the local logon request.

After asking our AD guys about DC1 and its synchronization status, as well as whether the user actually existed there, everything still looked OK.

After looking around a bit more I discovered this gem of a command for nltest to determine which DC will handle a logon request

C:\>nltest /whowill:Domain Account

[16:32:45] Mail message 0 sent successfully (\MAILSLOT\NET\GETDC579)
[16:32:45] Response 0: DC2 D:Domain A:Account (Act found)
The command completed successfully

Even though this command returned “act found” it was returning from DC2.  (I dont exactly understand why the same account would authenticate against 2 different DC’s based on a local desktop login or a SQL login but it apparently can)

在询问AD人员关于DC2后，灯泡显然已经为他们服务，因为该服务器实际上存在于一组不同的防火墙后面，位于一个完全不同的位置。虽然DC2将返回ping，但控制台由于某种原因不允许登录。在快速重启DC2之后，以及一些神奇的AD精灵粉尘（我不是AD管理员，如果从我新发现的朋友nltest中并不是很明显），那些遇到麻烦的Windows Id开始验证DC3和我们的SSPI错误了程。

有趣的花絮 - 在故障排除期间，我发现这个特定的SQL Server正在对至少5个不同DC的帐户进行身份验证。其中一些可能是预料之中的，因为有不同的领域在起作用，但是，我还没有听到AD人员关于它是否应该以这种方式工作的最终答案。

The solution

重新启动行为不端的DC，当然可能还有其他方法可以通过将请求重定向到不同的DC而无需重启来解决这个问题，但是因为它无论如何都是行为不端，并且AD专家想要重新启动所以我们就这样做了。重新启动SQL也可能解决了这个问题但是，我讨厌重新启动修复问题，他们似乎总是回来！

reference

SQL Server错误日志条目：错误：17806，严重性：20，状态：14

1 个答案: