我的日志中有几周的错误，我搜索了很多但找不到有用的答案。
我确实关闭了公共 IP 的 SQL Server 端口，但我还有问题。
错误：17806，严重性：20，状态：14。
SSPI 握手失败，错误代码为 0x8009030c，状态 14，同时建立具有集成安全性的连接；连接已关闭。原因：AcceptSecurityContext 失败。 Windows 错误代码指示失败的原因。登录尝试失败 [CLIENT: 10.10.3.25]提出的时间：2015 年 1 月 27 日下午 2:23
此系统关闭时引发错误。
【问题讨论】：
标签： sql-server
情景—— 尝试连接时，几个单独的 Windows ID 开始生成这些错误，所有其他 Windows 登录都正常工作。连接最初是通过应用程序发生的，但也通过 sqlcmd 发生。当使用有问题的 ID 在本地登录到服务器时，与 SQL 的连接将成功。
故障排除过程 – 检查所有常规的 SSPI 问题，我不会让您厌烦详细信息，因为它们很容易搜索
检查“简单”身份验证问题的一种相对简单的方法 如果可能/适当的话，使用违规 ID 在本地登录 SQL Server 并启动 sqlcmd 并通过 sqlcmd –Sservername,port –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 并使用它在 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 对帐户进行身份验证。由于涉及不同的域，其中一些可能是意料之中的，但我还没有听到广告人员关于它是否应该以这种方式工作的最终答案。
The solution
重新启动行为不端的 DC，当然可能有其他方法可以通过将请求重定向到不同的 DC 而不重新启动来解决此问题，但是，因为它无论如何都行为不端，并且 AD 专家想要重新启动，所以我们就这样做了。重新启动 SQL 也可能解决此问题，但是，我讨厌重新启动修复问题，它们似乎总是回来！
【讨论】：