Чому 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 обов’язковий, запишіть, чому перший шлях відступив, застосуйте одне виправлення й повторно виконайте запит з того самого клієнта. Успішний запит після зміни засобу запуску — це доказ доступу, і це ще не доказ того, що вимогу автентифікації виконано.