Я пытаюсь настроить ограниченное делегирование Kerberos, чтобы решить мою проблему. двойной прыжок проблема.
Я использую стандартную конфигурацию SQL Server с виртуальной учетной записью (NT СЕРВИС\МССКЛСЕРВЕР
) в качестве служебной учетной записи для всех моих экземпляров.
Когда я пытаюсь выполнить запрос с двойным переходом через Linked Server, я получаю эту типичную ошибку:
Ошибка входа в систему для пользователя «NT AUTHORITY\ANONYMOUS LOGON»
Настройка выглядит следующим образом:
Компьютер пользователя > HOP > SQL Server A > HOP (связанный сервер) > SQL Server B
И мой запрос просто базовый Выбирать
просто для тестирования. Как это:
Выберите * Из [Сервер B].[БД].[Схема].[Таблица]
С использованием Диспетчер конфигурации Kerberos для SQL Server Я проверил имена участников-служб и параметры делегирования для своих серверов.
SPN настраиваются автоматически:
И делегирование настроено на Никто
:
Я также проверил, какой тип аутентификации использует SQL Server. Чтобы проверить это, я выполнил этот запрос на сервере A (от эта статья):
ВЫБЕРИТЕ auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid ;
И получил NTLM
как ответ.
Судя по этим результатам, мне не хватает настроек делегирования. Но у меня вопрос, как мне поступить?
Я прочитал бесчисленное количество статей и сообщений, и я до сих пор не могу понять это. Похоже, что для этого можно просто использовать виртуальную учетную запись по умолчанию.
Но в каждом учебнике, который я нашел, говорится либо об учетных записях домена, либо об учетных записях управляемых служб. В таких случаях у нас есть эти учетные записи внутри Active Directory, но как насчет виртуальных учетных записей по умолчанию? Эти учетные записи являются локальными. Как предоставить им права делегирования?
Должен ли я предоставить разрешение делегирования на машине? Но как?
Я пытался это сделать. Я перешел в Active Directory, открыл свой компьютерный объект Server A и сделал следующее:
Таким образом, он должен позволить серверу A делегировать полномочия серверу B. Но это все равно не работает. И диспетчер конфигурации Kerberos по-прежнему показывает Никто
как тип делегирования.
Я использую Windows Server 2019 и SQL Server 2019.
@РЕДАКТИРОВАТЬ
Пробовал использовать разные настройки. Вместо "Только Керберос" Я выбрал "Использовать любой протокол аутентификации" и через 10 минут он начал работать!.
Теперь все это имеет смысл, так как соединение с SSMS все еще было выполнено с помощью NTLM
настройки «Только Kerberos» не будут работать.
Но вопрос в том, почему он все еще использует NTLM
? Это плохо, и я должен попытаться изменить его? Если да - то как?