Защо 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 е задължителен, запишете защо първият път е отстъпил, приложете една корекция и изпълнете заявката отново от същия клиент. Успешната заявка след промяна на стартиращия механизъм е доказателство за достъп и все още не е доказателство, че изискването за удостоверяване е изпълнено.