我正面临着一个奇怪的情况..。在windows2019上的SQL2016上,我有一个运行在windows2019上的应用程序,它使用域服务帐户(与server相同的域)连接到Server。
在SQL server日志中,我可以看到以下错误:
Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. [CLIENT: x.x.x.x]
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. The logon attempt failed [CLIENT: x.x.x.x]嗯,第一个错误是没有意义的,因为登录是在同一个域中。
奇怪的是,当他们重新启动应用服务器,然后突然,这些错误消失,并被替换为“登录成功”。几个小时或几天后,它又开始发福了。
如果是spn的话,那就行不通了。如果这是TLS的问题,我猜它永远也不会起作用。
是什么让它在一段时间内工作,然后失败呢?
谢谢。
发布于 2022-08-18 10:48:25
这个链接值得一看:
在那里,我将发表一段引文,这正是你的情况:
为了共享有关SSPI的一些信息:SSPI()是传输级应用程序(如Microsoft远程过程调用(RPC) )和安全提供者(如Windows分布式安全)之间的接口。SSPI允许传输应用程序调用多个安全提供程序之一以获得经过身份验证的连接。以下参数通常用于具有可信连接的Windows身份验证的连接字符串中:集成的Security=SSPI可以有两个变体:“无法生成SSPI上下文”和“SSPI握手失败”不能生成SSPI上下文:当客户端尝试Kerberos身份验证时通常会出现此错误,但不会退回到NTLM。SSPI握手失败:当用户未经过身份验证时,我们就会得到这个结果。在我们处理的问题中,我们遇到了“SSPI握手失败”,这表明Server无法对用户进行身份验证。
该网站继续展示隔离和处理问题的方法。
在隔离问题方面,我要做的是使用有问题的帐户登录到sql环境中,然后从那里查看。
就在昨天,我遇到了一个类似的问题,在我的环境中,它被证明与等待应用的最新微软补丁程序有关。
应用了这些补丁之后,所有的身份验证都开始正常地流动,在我的例子中,它与复制有关-因此它开始赶上.
发布于 2020-05-21 14:58:55
也许你的账户被封锁了..。你在其他地方用吗?您在DC中登记了此帐户的事件吗?您可以使用Server登录名而不是域帐户。
https://dba.stackexchange.com/questions/267624
复制相似问题