Чаму SQL Server праз VPN усё яшчэ пераходзіць на NTLM?

Kerberos патрэбна правільнае імя службы, SPN на патрэбным уліковым запісе і білет, які кліент можа атрымаць. Прачытайце auth_scheme, перш чым нешта змяняць.

Ваша злучэнне працуе, уваход прымаецца, і 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 патрабуецца, запішыце, чаму першы шлях адкаціўся, унясіце адно выпраўленне і паўторна выканайце запыт ад таго ж кліента. Паспяховы запыт пасля змены запускальніка — гэта доказ доступу, і пакуль не доказ таго, што патрабаванне аўтэнтыфікацыі было выканана.

Падобныя артыкулы