使用 Windows 身份验证的 Service Broker 连接失败,除非服务帐户在两端都是管理员

发布于 2024-11-23 16:15:13 字数 495 浏览 0 评论 0原文

拓扑:

计算机 A - Windows Server 2008 - SQL 2008 R2 Dev SQL Server 以 mydomain\user1 身份运行

计算机 B -Windows 7 -SQL 2008 R2 Dev SQL Server 以 mydomain\user1 身份运行

我已在任一端授予服务帐户连接权限到任一 SQL 服务器上的端点。如果我将 mydomain\user1 添加到任一端的计算机管理员组中,则可以毫无问题地建立连接。如果我将其从这些组中删除,我会收到以下消息:

连接握手失败。操作系统调用失败:(8009030c) 0x8009030c(登录尝试失败)。状态 67.

如有任何帮助,我们将不胜感激。我们确实不确定所需的最低权利。我们计划最终将其迁移到生产环境,但我不希望 sql 服务以本地计算机管理员身份运行。顺便说一句,我已经让我的服务器管理员了解了情况,据他们所知,SPN 似乎设置正确。

我在 MSDN 论坛上问了同样的问题

Topology:

Machine A - Windows Server 2008 - SQL 2008 R2 Dev SQL Server is running as mydomain\user1

Machine B -Windows 7 -SQL 2008 R2 Dev SQL Server is running as mydomain\user1

I have granted the service account at either end connect permissions to the endpoints on either SQL server. If I add the mydomain\user1 into the machine administrators group at either end, connections are made without a problem. If I remove it from these groups I receive the following message:

Connection handshake failed. An OS call failed: (8009030c) 0x8009030c(The logon attempt failed). State 67.

Any help is appreciated. We are really unsure of the necessary minimum rights required. We are planning to eventually migrate this to production and I would not prefer the sql service to run as a local machine administrator. BTW I have gotten my server admins in the loop and the SPN's appear to be set up correctly to the best of their knowledge.

I asked the same question on the MSDN forums here.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

巷子口的你 2024-11-30 16:15:13

如果两台计算机都作为域用户服务帐户运行,并且您授予了必要的权限(在 SSB 端点上 CONNECT),则在 SSB 配置方面您无需执行任何其他操作。该错误是操作系统错误,最好的调查方法是使用 Kerberos 故障排除文档:Kerberos 错误疑难解答

最可能的原因是 SPN 格式错误。 Service Broker 要求提供 SPN,例如 MSSQLSvc\:。它将格式化请求的 SPN (DsMakeSpn)来自路由地址,因此如果您在路由中使用 FQDN,则 SPN 必须是 FQDN,如果您仅使用主机名,则 SPN 必须基于主机名。该部分也来自路由,如果省略则为默认的 4022。

If both machines are running as the domain user service account and you granted the necessary permission (CONNECT on the SSB endpoints) there is nothing else in the SSB configuration side you need to do. The error is an OS error and the best way to investigate is to use the Kerberos troubleshooting document: Troubleshooting Kerberos Errors.

The most likely cause though is a bad formatted SPN. Service Broker asks for and SPN like MSSQLSvc\<hostname>:<port>. It will format the requested SPN (DsMakeSpn) from the route address, so if you use FQDN in route then the SPN must be FQDN, if you use just hostname then SPN must be hostname based. The part also comes from the route, if omitted then is the default 4022.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文