Как настроить аутентификацию между связанными серверами?

Я пытаюсь проверить доказательство того, что я могу выполнять распределенную транзакцию между двумя связанными SQL-серверами, связанными с помощью sp_addlinkedserver — их имена — Server1 и Server2, оба работают в экземплярах по умолчанию. Каждый сервер содержит одну базу данных, Source и Destination соответственно, а целевая база данных содержит одну таблицу с именем Output, т.е.

Server1.Source
Server2.Destination.Output

Таблица OUTPUT имеет следующую структуру:

OUT_PKEY int identity(1,1) primary key,
OUT_TEXT nvarchar(255)

С сервера Server1 я вызвал sp_addlinkedserver 'Server2', чтобы связать две базы данных, и попытался выполнить следующий запрос, чтобы проверить, действительно ли связь работает:

Select   *
From     Server2.Destination.dbo.Output

Мне возвращается следующее исключение:

Доступ к удаленному серверу запрещен, так как не существует сопоставления входа в систему.

Достаточно справедливо, поэтому с сервера 1 я запускаю sp_addlinkedsrvlogin 'Server2', который, согласно документации, должен принимать учетные данные пользователя от того, кто запускает запрос удаленно (т. е. с сервера 1), и применять эти учетные данные к серверу 2. . Это означает, что, поскольку я подключен к серверу 1 с использованием проверки подлинности Windows, это должно означать, что мои учетные данные Windows также применяются к серверу 2.

Теперь сообщение об исключении меняется на:

Ошибка входа в систему для пользователя «NT AUTHORITY\ANONYMOUS LOGON».

Погуглив это исключение, я не нашел ничего полезного, что указывало бы мне в правильном направлении. Что мне не хватает? Я ожидаю, что [в случае сбоя входа в систему] исключение будет ссылаться на мои учетные данные Windows, не на учетные данные анонимного входа.

Похоже, что как только я заработаю саму ссылку, сами распределенные транзакции должны быть довольно простым делом - документация подразумевает, что мне просто нужно убедиться, что служба DTC работает на сервере 1 и что любые запросы выполняются на сервере 1, которые будут выполняться транзакциями. по ссылке:

  • Включить SET XACT_ABORT ON перед инициализацией моей распределенной транзакции
  • Я использую НАЧАТЬ РАСПРЕДЕЛЕННУЮ ТРАНЗАКЦИЮ вместо НАЧАТЬ ТРАНЗАКЦИЮ
  • Если я хочу сослаться на нестандартный экземпляр SQL Server на сервере Server2, я заменяю все экземпляры с именем Server2 в своем запросе на [Server2\InstanceName].

Мои вопросы таковы:

  • как решить эту проблему со входом? Сама по себе хранимая процедура sp_addlinkedsrvlogin, похоже, не помогает.
  • Действительно ли так просто запустить распределенную транзакцию, как следует из документации?

ТИА


tsql transactions distributed-transactions sql-server-2005
person BenAlabaster    schedule 16.01.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если вы находитесь в домене, то настройка должна быть «Выполнена с использованием текущего контекста безопасности входа», но есть еще один шаг — вам нужно предоставить имя участника-службы каждому из серверов, участвующих в транзакции.

Предполагая, что вы запускаете службы SQL на обоих серверах в качестве пользователя домена (что вам нужно, чтобы это работало — LocalSystem этого не сделает), вот инструкции, которые вам понадобятся:

http://technet.microsoft.com/en-us/library/bb735885.aspx

Помните, что пользователю потребуется имя участника-службы для обоих серверов, но не для клиента. Например, если вы переходите от клиента -> сервер1 -> сервер2, учетной записи службы SQL потребуется имя участника-службы как для сервера1, так и для сервера2.

Если вы запутались (это запутанный процесс), оставьте комментарий, и я уточню инструкции.

person SqlRyan    schedule 16.01.2009

arrow_upward
0
arrow_downward

Предположим, что эти серверы находятся в одном домене. Включили ли вы доверенное делегирование, чтобы ваш сервер мог передавать учетные данные на целевой сервер? Вы должны получить объект Active Directory для сервера, перейти на вкладку «Делегирование» и выбрать «Доверять этому компьютеру только для делегирования указанным службам», а затем ввести данные SQL Server, которым серверу разрешено передавать учетные данные:

Тип службы = MSSQLSvc
Пользователь/Компьютер = YourTargetServer.Your.Domain
Порт = 1433

К сожалению, многие из этих типов проблем аутентификации со связанными серверами требуют перезагрузки для полного вступления в силу (поэтому, если это рабочие серверы, их трудно устранить в течение дня).

Что касается распределенных транзакций - если вы в конечном итоге правильно установите соединение со связанным сервером, то распределенные транзакции будут работать отлично. Хотя следующее, с чем вы, вероятно, столкнетесь после того, как заработаете, — это обнаружение огромного недостатка, заключающегося в том, что вы не можете использовать любую форму SCOPE_IDENTITY(), @@IDENTITY и т. д. для получения первичных ключей. после вставки чего-либо в связанную базу данных. Но это еще одна проблема со своими забавными обходными путями...

person Lance McNearney    schedule 16.01.2009