我在两个不同的服务器上的两个不同的数据库中配置了一个服务代理。问题是,我不能接收消息,因为我有这个问题。 Connection handshake failed. The login 'public' does not have CONNECT permission on the endpoint. State 84.
我的端点有证书,我给了权限连接到一个有证书的特定用户(我在两台服务器上做的,因为它是...)。常备组),在查找问题的时候,我发现发起服务器的证书和目标服务器的证书不一样。-initiator - 签名算法:sha1RSA,密钥长度:1024 (sql ver. 11.0.7 ...) -target - 签名算法:sha256RSA,密钥长度:2048 (sql ver. 15.0.4 ...)
当我授予权限。grant connect on endpoint :: BrokerEndPoint to PUBLIC
服务器会进行通信,但这并不能解决问题。
grant connect on endpoint :: BrokerEndPoint to PUBLIC
这样做基本上绕过了授权,因为大家都是有授权连接的。我觉得你应该尝试修复userroles的权限。
我注意到发起服务器的证书与目标服务器的证书不同。
这应该没有任何区别
看起来问题是你以某种方式错误地配置了userslogincerts链。是如此的复杂,很容易打破... ... 这里是正确设置的重述。
CREATE ENDPOINT ... FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE <certname>)
). 证书必须有一个可访问的私钥才能使用(即用一个可以从服务主钥打开的密钥进行加密,通常是通过 master
数据库主密钥)。)master
数据库,而S2需要在它的C1(只有公钥)的 master
.master
是由一个数据库用户(一个数据库委托人)拥有的,比如说是US2。这个用户有一个登录名(一个服务器委托人,比如说是UL2)。登录UL2必须被授予 CONNECT
的权限。master
是由一个拥有登录名(UL1)的用户(US1)所拥有。这个登录用户UL1需要被授予 CONNECT
S2端点上的权限。为了排除故障,请在 "配置文件 "中启用 "审计经纪人登录 "事件(在安全审计组中)。当握手失败时,该事件将启动,并详细说明为什么握手失败。
谢谢你的时间,我再次检查了连接和数据,没有发现任何问题。由于我很困扰的事实,也许这是一个问题,我写的,所以测试我创建了另一个连接,但这一次在服务器上的SHA256证书,因为我认为这是一个问题在这里。为了证实我的理论,我把我之前写过的初始服务器上的证书换成了SHA256(我用这个证书删除并重新创建了端点),在目标服务器上,我换了这个证书,问题就解决了。所以就像我认为证书的编码类型一定是一样的。