VPN подключается, но SQL Server отклоняет проверку подлинности Windows

Туннели поднимаются, серверы отвечают на ping, а вход в базу данных всё равно завершается ошибкой проверки подлинности. Такое сочетание часто встречается на VPN-каналах и редко означает, что сеть сломана, ведь доступный прослушиватель и принятый вход — разные результаты. Удостоверение, удовлетворившее шлюз, не обязательно то же самое, которое предлагает клиент базы данных. Выяснить, какая учётная запись пришла, — это вся задача.

Симптом: сервер доступен, вход отклонён

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

Когда ошибка — это неудачный вход, перестаньте смотреть на порты. Остаётся вопрос, какое удостоверение Windows предъявил клиент, принял ли сервер это удостоверение и разрешилось ли оно в пользователя базы данных с разрешением.

Два удостоверения, один туннель

Учётная запись VPN проходит проверку подлинности на шлюзе и в большинстве развёртываний на этом заканчивается. Клиент базы данных отдельно предъявляет токен Windows, взятый из процесса, который его запускает, или вход SQL, если строка подключения требует его. Локальный для шлюза пользователь VPN не имеет никакого отношения к домену, в котором размещён SQL Server, и туннель такого отношения не создаёт.

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

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

Прочитайте режим, который запросил клиент

Строка подключения решает, какой путь проверки подлинности выберет клиент. Встроенная безопасность использует токен Windows; пара «пользователь и пароль» выбирает вход SQL. Это отдельные режимы в конфигурации сервера, и для данной попытки подключения может быть включён только один из них.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

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

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

Спросите сервер, что он на самом деле увидел

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

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Первая строка отличает вход, открывший сеанс, от контекста безопасности, действующего сейчас, и при олицетворении они различаются. Вторая называет схему проверки подлинности, поэтому KERBEROS, NTLM и SQL становятся видимыми фактами вместо догадок. Подключение, которое сообщает NTLM там, где вы ждали Kerberos, — это проблема разрешения имён или SPN, а не проблема пароля.

Номер ошибки сужает ещё сильнее. Состояние 5 обычно означает, что имя входа вообще не разрешено, состояние 8 обычно означает, что пароль не совпал, а состояние 11 означает, что учётные данные приняты, но доступ к серверу не удался. Попросите у администратора состояние, а не всё сообщение, потому что само сообщение намеренно расплывчато.

Когда удостоверение приходит, а Kerberos всё равно срывается

Если сервер видит нужное удостоверение Windows, а встроенная проверка подлинности всё равно не удаётся, проблема в самом обмене. Kerberos нуждается в имени участника службы, зарегистрированном для учётной записи службы SQL, и в клиенте, который запрашивает службу по совпадающему имени. Подключение по IP-адресу не может совпасть с SPN на основе имени, а псевдоним может совпасть только если он тоже зарегистрирован. Проверьте прежде всего имя, введённое клиентом, потому что подключение, которое работает по имени хоста и срывается по IP, описывает именно эту проблему.

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

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