SQL Server Service Broker — 通过 VPN 在非域服务器之间进行通信
如果这两个服务器都不在域中,但我们可以完全控制登录和凭据,是否有任何好的选择可以通过 Service Broker 连接两个 SQL Server 2008 实例?
我们正在考虑使用此技术进行企业级数据整合,但我们的服务器在客户端站点运行,并且未配置为任何域的成员。我们正在寻找让 Service Broker 在此环境中进行通信的最简单的选项。
Are there any good options for connecting two SQL Server 2008 instances via Service Broker if neither of those servers are in a domain, but we have full control over the logins and credentials?
We're thinking of using this technology for enterprise-level data consolidation, but our servers run at client sites and are not configured as members of any domain. We're looking for the least-pain option to get Service Broker communicating in this environment.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以使用证书,这是专为像您这样的场景而设计的 Service Broker 身份验证选项。请参阅基于证书的身份验证如何工作 。当端点配置了基于证书的身份验证时,握手包将包含基于 SSPI Schannel 的身份验证交换(通常称为 SSL 或 TLS)。对等方使用的结果证书用于根据从证书部署派生的信任来授权连接。这意味着所使用的证书未针对特定属性进行验证,例如“https://example.com”在这种情况下,“example.com”必须在证书上具有特定的 OID 和受信任的权威签名,但如果证书已部署(即在主数据库中找到),则部署的证书的所有者就是身份。这允许您以安全的方式使用自签名证书,并在部署中使用信任根(即系统管理员),而不是权威机构(即 Verisign)。这可能比您需要的更多信息:)
其要点如下:
You use certificates, which is the Service Broker authentication option designed specifically for a scenario like your. See How does Certificate based Authentication work. When endpoints are configured with certificates based authentication the handhsake will contain an SSPI Schannel based authentication exchange (better known as SSL or TLS). The resulting certificate used by the peer is used to authorize the connection based on trust derived from certificate deployment. What that means is that the certificates used are not validated for a specific property like in the 'https://example.com' case where 'example.com' has to e a specific OID on the certificate and a trusted authorithy signature, but instead if the certificate is deployed (ie. found in the master database) then the owner of the deployed certificate is the identity. This allows you to use self-signed certificates in a safe manner with root of trust in deployment (ie. the sysadmin), not an authorithy (ie. Verisign). This is a probably more info than you need :)
The gist of it goes like this: