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