Зашто 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 обавезан, запишите зашто је први пут попустио, примените једну исправку и поново извршите упит са истог клијента. Успешан упит после промене покретача је доказ приступа и још није доказ да је захтев за аутентификацију испуњен.