Почему SQL Server через VPN всё равно переходит на NTLM?

Ваше подключение работает, вход принимается, и SQL Server использует NTLM, хотя все ожидали Kerberos. Этот результат не является дефектом VPN, потому что туннель даёт только путь; схему определили имя, запрошенное клиентом, субъект, зарегистрированный в каталоге, и билет, который клиент действительно смог получить. Три условия должны выполняться одновременно, и сама сессия говорит, какое уступило. Прочитайте это, прежде чем кто-либо изменит имя субъекта-службы.

Сессия называет схему, которую вы действительно получили

Схема проверки подлинности принадлежит соединению, а не серверу или туннелю, поэтому проверку нужно выполнять внутри интересующей вас сессии. Выполните запрос ниже с того же клиента, инструмента и учётной записи, которые создали отчёт, и запишите имя цели и транспорт рядом с результатом.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Строка из локального окна SSMS на узле базы данных описывает совершенно другое соединение, поэтому запрос нужно выполнять со стороны клиента. Сохраните вывод с отметкой времени, потому что следующий человек, который его прочитает, спросит, когда он был снят. Когда несколько приложений совместно используют одну конечную точку, возьмите выборку из каждого, потому что разница в источнике данных между двумя приложениями часто и есть вся история.

Условие первое: совпадает ли имя с SPN?

Kerberos проверяет подлинность именованной службы, поэтому клиент запрашивает у каталога билет для одного конкретного субъекта. Для поставщика TCP документированная форма — MSSQLSvc/, за которой следуют полное имя узла и, для экземпляра по умолчанию, порт. Именованный экземпляр регистрирует MSSQLSvc/db01.corp.example:SQLPROD, где суффикс — это имя экземпляра вместо числа. Доступ к прослушивателю через псевдоним, CNAME, разрешаемый в другом месте, или чистый IP-адрес меняет запрошенное имя, а запрос без подходящего субъекта не имеет билета, который можно вернуть.

Вот почему одно приложение работает в одной сети и откатывается в другой: ответ DNS, запись псевдонима или запись hosts изменили имя, которое использовал клиент. Сравните запрошенное имя с тем, что содержит каталог, прежде чем трогать регистрацию.

Условие второе: находится ли SPN на нужной учётной записи?

SPN должен принадлежать учётной записи, которая запускает службу SQL, а не учётной записи клиента и не объекту компьютера по случайности. SQL Server может регистрировать свои SPN при запуске, когда его служебная учётная запись имеет право их записывать, что удобно и одновременно объясняет, как после смены служебной учётной записи появляется дубликат.

Спросите каталог об ожидаемом имени, затем перечислите, чем учётная запись действительно владеет. То, какой объект хранит запись, важнее того, существует ли имя где-то в лесу. Несовпадение означает, что вход никогда не был проблемой, а руководство по SPN от Microsoft описывает форматы и случаи, когда администратор домена должен создать запись.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Добавление ещё одной записи — не безопасный эксперимент. Дубликат или конфликтующая регистрация может сломать работающих клиентов, поэтому проверьте владение до изменения и перепроверьте после.

Условие третье: может ли клиент вообще получить билет?

Правильный SPN бесполезен, если клиент не может достичь контроллера домена или не имеет пригодного контекста учётных данных. Для обмена нужны KDC и DNS через VPN, а туннель, маршрутизирующий только порт SQL, терпит неудачу именно на этом шаге. Доступность нужно проверять с той же машины и той же учётной записи, а не с межсетевого экрана перед ними.

Проверьте кэш билетов на машине и под учётной записью, которая запускает приложение. Список по всей машине из окна с повышенными правами ничего не говорит о службе, работающей от другого пользователя, а пустой кэш для этого пользователя — это находка, а не неудобство.

klist
klist -li 0x3e7

Затем решите, что может делать откат. Если политика требует Kerberos, NTLM должен отклоняться явно, потому что молчаливый откат превращает ошибку конфигурации в работающее соединение, нарушающее требование. Если NTLM остаётся допустимым для некоторых приложений, назовите их и перестаньте считать каждую сессию NTLM инцидентом.

Смена средства запуска — одна переменная, а не исправление

Запуск SSMS с другими учётными данными может вылечить непреднамеренную исходящую идентичность, что действительно является классом проблем. Это ничего не доказывает об имени цели, регистрации или пути билета и не меняет того, что принял сервер.

Держите сравнение контролируемым: та же конечная точка, тот же поставщик, известный контекст выполнения, затем новое соединение, схему которого вы проверяете. Подтвердите принятый вход и его права в базе данных отдельно, потому что доступ и проверка подлинности терпят неудачу по разным причинам.

Когда Kerberos обязателен, запишите, почему первый путь откатился, примените одну правку и повторно выполните запрос с того же клиента. Успешный запрос после смены средства запуска — это доказательство доступа, и это ещё не доказательство того, что требование проверки подлинности выполнено.