Bakit bumabalik pa rin sa NTLM ang SQL Server sa VPN?

Gumagana ang koneksyon mo, tinatanggap ang pag-login, at gumagamit ang SQL Server ng NTLM habang inaasahan ng lahat ang Kerberos. Ang resultang iyon ay hindi depekto ng VPN, dahil nagbibigay lamang ng landas ang tunnel; ang scheme ay pinagpasyahan ng pangalang hiniling ng kliyente, ng principal na nakarehistro sa direktoryo at ng ticket na aktwal na nakuha ng kliyente. Tatlong kundisyon ang dapat totoo nang sabay, at ang session mismo ang nagsasabi kung alin ang sumuko. Basahin iyon bago baguhin ng sinuman ang pangalan ng service principal.

Pinangalanan ng session ang scheme na aktwal na nakuha mo

Ang authentication scheme ay kabilang sa isang koneksyon at hindi sa isang server o tunnel, kaya ang pagsusuri ay dapat tumakbo sa loob ng session na mahalaga sa iyo. Patakbuhin ang query sa ibaba mula sa parehong kliyente, tool at account na gumawa ng ulat, at itala ang pangalan ng target at transport sa tabi ng resulta.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Ang isang hilera mula sa lokal na window ng SSMS sa host ng database ay naglalarawan ng ganap na ibang koneksyon, kaya dapat tumakbo ang query mula sa panig ng kliyente. I-save ang output na may timestamp, dahil ang susunod na taong magbabasa nito ay magtatanong kung kailan ito kinuha. Kapag maraming application ang nagbabahagi ng isang endpoint, kumuha ng sample mula sa bawat isa, dahil ang pagkakaiba ng data source sa pagitan ng dalawang application ay madalas ang buong kuwento.

Unang kundisyon: tumutugma ba ang pangalan sa SPN?

Inaathentika ng Kerberos ang isang pinangalanang serbisyo, kaya humihingi ang kliyente ng ticket sa direktoryo para sa isang partikular na principal. Para sa TCP provider, ang dokumentadong anyo ay MSSQLSvc/ na sinusundan ng fully qualified na hostname at, para sa default na instance, ang port. Ang pinangalanang instance ay nagrerehistro ng MSSQLSvc/db01.corp.example:SQLPROD, kung saan ang suffix ay ang pangalan ng instance sa halip na numero. Ang pag-abot sa listener sa pamamagitan ng alias, CNAME na niresolba sa ibang lugar o hubad na IP address ay nagbabago ng hiniling na pangalan, at ang kahilingang walang tugmang principal ay walang ticket na ibabalik.

Iyon ang dahilan kung bakit gumagana ang isang application sa isang network at bumabalik sa isa pa: binago ng sagot ng DNS, tala ng alias o entry ng hosts ang pangalang ginamit ng kliyente. Ihambing ang hiniling na pangalan sa kung ano ang hawak ng direktoryo bago hawakan ang rehistro.

Ikalawang kundisyon: nasa tamang account ba ang SPN?

Ang SPN ay dapat pag-aari ng account na nagpapatakbo ng serbisyo ng SQL, hindi ng account ng kliyente at hindi ng isang computer object nang hindi sinasadya. Maaaring irehistro ng SQL Server ang sarili nitong SPN sa pagsisimula kapag ang service account nito ay may pahintulot na isulat ang mga ito, na maginhawa at nagpapaliwanag din kung paano lumilitaw ang duplicate pagkatapos ng pagbabago ng service account.

Tanungin ang direktoryo para sa pangalang inaasahan mo, pagkatapos ilista kung ano ang aktwal na pag-aari ng account. Aling object ang humahawak ng entry ang mas mahalaga kaysa sa kung ang pangalan ay umiiral saanman sa forest. Ang hindi pagtutugma ay nangangahulugang ang pag-login ay hindi kailanman naging problema, at ang gabay sa SPN ng Microsoft ay nagdodokumento ng mga anyo at ng mga kaso kung saan kailangang gawin ng domain administrator ang entry.

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

Ang pagdaragdag ng isa pang entry ay hindi ligtas na eksperimento. Ang duplicate o magkasalungat na rehistro ay maaaring makasira ng mga kliyenteng gumagana, kaya siyasatin ang pagmamay-ari bago ang pagbabago at muling suriin pagkatapos.

Ikatlong kundisyon: makakakuha ba ng ticket ang kliyente?

Ang tamang SPN ay walang silbi kung hindi maabot ng kliyente ang domain controller o walang magagamit na konteksto ng kredensyal. Ang palitan ay nangangailangan ng KDC at DNS sa pamamagitan ng VPN, at ang tunnel na nagruruta lamang ng port ng SQL ay nabigo sa eksaktong hakbang na ito. Ang maabot ay dapat subukan mula sa parehong makina at parehong account, hindi mula sa firewall sa harap nila.

Siyasatin ang cache ng ticket sa makina at sa ilalim ng account na nagpapatakbo ng application. Ang listahan sa buong makina mula sa nakataas na window ay walang sinasabi tungkol sa serbisyong tumatakbo bilang ibang user, at ang walang laman na cache para sa user na iyon ay isang natuklasan at hindi abala.

klist
klist -li 0x3e7

Pagkatapos ay magpasya kung ano ang maaaring gawin ng pagbalik. Kung ang patakaran ay nangangailangan ng Kerberos, ang NTLM ay dapat tahasang tanggihan, dahil ang tahimik na pagbalik ay ginagawang gumaganang koneksyon ang error sa configuration na lumalabag sa pangangailangan. Kung ang NTLM ay nananatiling katanggap-tanggap para sa ilang application, pangalanan ang mga ito at itigil ang pagtrato sa bawat session ng NTLM bilang insidente.

Ang pagbabago ng launcher ay isang variable, hindi pag-aayos

Ang pagsisimula ng SSMS sa ilalim ng ibang kredensyal ay maaaring gumamot ng hindi sinasadyang papalabas na pagkakakilanlan, na isang tunay na uri ng problema. Wala itong pinapatunayan tungkol sa pangalan ng target, rehistro o landas ng ticket, at hindi nito binabago ang tinanggap ng server.

Panatilihing kontrolado ang paghahambing: parehong endpoint, parehong provider, kilalang execution context, pagkatapos ay isang bagong koneksyon na iyong sinusuri ang scheme. Kumpirmahin nang hiwalay ang tinanggap na pag-login at ang mga pahintulot nito sa database, dahil nabigo ang access at authentication sa magkaibang dahilan.

Kapag kailangan ang Kerberos, itala kung bakit bumabalik ang unang landas, maglapat ng isang pagwawasto at patakbuhin muli ang query mula sa parehong kliyente. Ang matagumpay na query pagkatapos ng pagbabago ng launcher ay ebidensya ng access, at hindi pa ito ebidensya na natugunan ang pangangailangan sa authentication.