SQL Server 身份验证的 SSPI 错误？
我们有几个使用 SQL Server 身份验证的旧 ASP 和 PHP Web 应用程序。 所有应用程序都会定期失去连接到 SQL Server 2000 数据库服务器的能力，导致访问被拒绝。
大约在同一时间，我们
1115 Cannot generate SSPI Context SQLSTATE HY000
在 SQLServer 2000 服务器上收到错误。
这是奇怪的部分 - 重新启动网络服务器可以解决问题。 重新启动数据库服务器没有任何效果。
这对我来说毫无意义 - 我不认为 SSPI 与 SQL Server 身份验证有任何关系。
有任何想法吗？
编辑：
一些其他详细信息：
Web 服务器位于 DMZ 中。 Web 服务器上的主机文件有一个数据库服务器条目（并且 IP 地址是正确的），因此 Web 服务器（至少理论上）甚至不应该通过 DNS 来连接到数据库服务器。
这似乎不是防火墙问题。
We have several old ASP and PHP web applications which use SQL Server Authentication. Periodically, all the applications lose the ability to connect to our SQL Server 2000 database server, getting access denied.
Corresponding to roughly the same times, we are getting
1115 Cannot generate SSPI Context SQLSTATE HY000
errors on the SQLServer 2000 server.
And here's the weird part - rebooting the web server fixes the problem. Rebooting the database server has no effect.
This makes no sense to me - I didn't think SSPI was in any way involved with SQL Server Authentication.
Any ideas?
Edit:
Some additional details:
The web server is in the DMZ. The hosts file on the web server has an entry for the database server (and the ip address is correct), so the web server (theoretically at least) shouldn't even be going to DNS to connect to the database server.
It does not appear to be a firewall issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你是对的，根据我的经验，该错误与 SQL 身份验证无关。 Web 服务器是否位于任何类型的防火墙后面？ 是否对任一服务器上的“hosts”文件进行了任何更改？ 当遇到这些问题时，您是否尝试过从 Web 服务器 ping SQL Server 以确保 Web 服务器能够解析 SQL Server 的名称？ 我会检查企业管理器中的活动监视器，以确保 Web 应用程序确实使用 SQL 身份验证进行连接。 一种可能性是某种网络或域控制器问题 - 这可以解释从 Web 服务器断开的连接以及 SQL Server 上的 SSPI 上下文错误，但不确定为什么重新启动 Web 服务器可以解决该问题。
I think you are right, that error is not associated with SQL authentication in my experience. Is the web server behind a firewall of any sort? Have any changes been made to the "hosts" file on either server? Have you tried pinging the SQL Server from the web server when you have these issues to make sure the web server is able to resolve the name of the SQL Server? I would check the Activity Monitor in Enterprise Manager to be sure that the web apps are definitely connecting using SQL authentication. One possibility is some kind of network or domain controller problem - that would explain the dropped connections from the web server and the SSPI context errors on the SQL Server, but not sure why restarting the web server would resolve it..
我们的主服务器和其他国家的一些客户之间存在这种情况。
如果这里和那里之间存在太多延迟（例如防火墙），则底层 Kerberos 会丢失情节（技术术语:-)。
我们通过指定端口来修复它。 另外，我建议使用服务器的 FQDN。
所以我们现在使用：“SQLServer.domain.tld\InstanceName,1234”
We had this between our main servers and some clients in other countries.
The underlying Kerberos loses the plot (technical term :-) if there is too much delay (eg firewalls) between here and there.
We fixed it by specifying the port. Also, I'd suggest using the FQDN of the server.
So we now use: "SQLServer.domain.tld\InstanceName,1234"