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 і дозвіл читати певну таблицю — три окремі результати, і кожен заслуговує на власну перевірку до закриття заявки.