Сервисный брокер не использует пользователя, указанного в маршруте
Я пытаюсь отправить сообщение с одного сервера на другой, используя имя пользователя Windows. Я создал маршрут для этого:
CREATE ROUTE [SB_Server1_Server2Route]
AUTHORIZATION [COMPANY\SVC.SQLServiceBroker]
WITH SERVICE_NAME = '//Server1/Server2/UpdatedRecord_TargetService',
ADDRESS = 'tcp://Server2:4022';
Я отправляю сообщение, используя следующий запрос / процедуру:
EXEC [dbo].[SB_SendBrokerMessage] '//Server1/Server2/UpdatedRecord_InitiatorService',
'//Server1/Server2/UpdatedRecord_TargetService', @XML;
CREATE PROCEDURE [dbo].[SB_SendBrokerMessage]
@FromService sysname ,
@ToService sysname ,
@MessageBody XML
AS
BEGIN
SET NOCOUNT ON;
IF ( @MessageBody IS NOT NULL
AND @FromService IS NOT NULL
AND @ToService IS NOT NULL
)
BEGIN
DECLARE @conversation_handle UNIQUEIDENTIFIER;
BEGIN TRANSACTION;
BEGIN DIALOG CONVERSATION @conversation_handle
FROM SERVICE @FromService
TO SERVICE @ToService
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @conversation_handle (@MessageBody);
COMMIT TRANSACTION;
END;
END;
GO
И я получаю следующую ошибку в журнале:
Попытка входа компонента Service Broker пользователем 'COMPANY\AnotherUser.' Ошибка: ошибка установления соединения. Имя входа "COMPANY \ AnotherUser" не имеет разрешения CONNECT для конечной точки. Состояние 84.'. [КЛИЕНТ: 192.168.21.61]
Итак, вопрос: почему он не использует пользователя, указанного в маршруте?
2 ответа
Условие авторизации на маршруте (или что-либо еще) указывает, кто является владельцем маршрута, а не кто будет подключаться. К счастью, есть простое решение для вашей ситуации: предоставьте разрешение на подключение на конечной точке всем пользователям, которым это нужно.
Бен уже говорил вам, почему использование предложения AUTHORIZATION не имеет ничего общего с соединениями компонента Service Broker.
Чтобы настроить два экземпляра для обмена сообщениями компонента Service Broker, необходимо настроить компонент "Безопасность Service Broker Transport Security". Вы можете выбрать между аутентификацией на основе сертификатов (см. Как работает аутентификация на основе сертификатов) или аутентификацией на основе Windows. Безопасность транспортного уровня не имеет абсолютно никакого отношения к текущему пользователю. Не имеет значения, какой текущий пользователь использует глаголы компонента Service Broker, он позволяет только двум задействованным экземплярам соединяться друг с другом. Я настоятельно рекомендую использовать проверку подлинности на основе сертификатов, но если вам необходимо * использовать Windows, вы должны предоставить разрешение CONNECT учетной записи равноправной службы.
В Service Broker существует второй уровень безопасности, а именно безопасность диалога (см. Аутентификация бесед). Это позволяет двум сервисам Service Broker аутентифицировать друг друга и обмениваться сообщениями. Это, опять же, не имеет никакого отношения к текущему подключенному пользователю. Если указано, то это требует создания объектов привязки удаленных сервисов. Всегда на основе сертификата.
В конце концов, когда вся безопасность компонента Service Broker настроена как на транспортном уровне, так и на уровне диалога, необходимо также указать, какие пользователи SQL имеют разрешение на использование этой инфраструктуры, и это контролируется с помощью разрешения RECEIVE, предоставленного для очереди, которая хосты службы.