Неге SQL Server VPN арқылы әлі де NTLM-ге ауысады?

Сіздің қосылымыңыз жұмыс істейді, кіру қабылданады, бірақ бәрі Kerberos күткенде SQL Server NTLM қолданып отыр. Бұл нәтиже 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-дерін тіркей алады, егер оның қызмет тіркелгісінде оларды жазу рұқсаты болса, бұл ыңғайлы және қызмет тіркелгісі ауысқаннан кейін көшірменің қалай пайда болатынын да түсіндіреді.

Каталогтан күтілетін атауды сұрап, содан кейін тіркелгінің шын мәнінде иеленетінін тізімдеңіз. Жазбаны қай нысан ұстайтыны атаудың орманның бір жерінде бар-жоғынан маңыздырақ. Сәйкессіздік кірудің ешқашан мәселе болмағанын білдіреді, ал Microsoft-тың SPN нұсқаулығы форматтарды және домен әкімшісі жазбаны жасауға тиіс жағдайларды құжаттайды.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Тағы бір жазба қосу қауіпсіз эксперимент емес. Көшірме немесе қайшы тіркеу жұмыс істеп тұрған клиенттерді бұзуы мүмкін, сондықтан өзгерістерге дейін меншікті тексеріп, кейін қайта тексеріңіз.

Үшінші шарт: клиент билетті мүлде ала ала ма?

Дұрыс SPN пайдасыз, егер клиент домен контроллеріне жете алмаса немесе қолданылатын тіркелгі деректері контексі болмаса. Айырбастауға VPN арқылы KDC және DNS қажет, ал тек SQL портын бағдарлайтын туннель дәл осы қадамда сәтсіздікке ұшырайды. Қолжетімділікті олардың алдындағы брандмауэрден емес, сол машина мен сол тіркелгіден тексеру керек.

Билет кэшін машинада және қолданбаны жүргізетін тіркелгі астында тексеріңіз. Жоғарылатылған терезеден алынған машина бойынша тізім басқа пайдаланушы атымен жұмыс істейтін қызмет туралы ештеңе айтпайды, ал сол пайдаланушы үшін бос кэш қолайсыздық емес, табылым.

klist
klist -li 0x3e7

Содан кейін шегінудің не істей алатынын шешіңіз. Егер саясат Kerberos-ті талап етсе, NTLM ашық түрде қабылданбауы керек, өйткені үнсіз шегіну конфигурация қатесін талапты бұзатын жұмыс қосылымына айналдырады. Егер NTLM кейбір қолданбалар үшін қолайлы болып қалса, оларды атаңыз және әр NTLM сессиясын оқиға ретінде қарауды тоқтатыңыз.

Іске қосқышты өзгерту — бір айнымалы, түзету емес

SSMS-ті басқа тіркелгі деректерімен іске қосу кездейсоқ шығыс сәйкестілігін емдеуі мүмкін, бұл мәселенің нақты класы. Бұл мақсат атауы, тіркеу немесе билет жолы туралы ештеңе дәлелдемейді және сервер қабылдаған нәрсені өзгертпейді.

Салыстыруды бақылауда ұстаңыз: сол соңғы нүкте, сол провайдер, белгілі орындалу контексі, содан кейін схемасын тексеретін жаңа қосылыс. Қабылданған кіруді және оның дерекқор рұқсаттарын бөлек растаңыз, өйткені қатынау мен аутентификация әртүрлі себептермен сәтсіз болады.

Kerberos талап етілгенде, бірінші жолдың неге шегінгенін жазыңыз, бір түзету қолданыңыз және сұрауды сол клиенттен қайта орындаңыз. Іске қосқышты өзгерткеннен кейінгі сәтті сұрау қатынаудың дәлелі, және бұл әлі аутентификация талабының орындалғанының дәлелі емес.