Kwa nini SQL Server kupitia VPN bado inarudi kwenye NTLM?

Muunganisho wako unafanya kazi, kuingia kunakubaliwa, na SQL Server inatumia NTLM wakati kila mtu alitarajia Kerberos. Matokeo hayo si kasoro ya VPN, kwa sababu handaki hutoa njia pekee; mpango uliamuliwa na jina ambalo mteja aliliomba, mkuu aliyesajiliwa kwenye saraka na tikiti ambalo mteja alifanikiwa kupata. Masharti matatu lazima yatimizwe kwa wakati mmoja, na kikao chenyewe kinasema lipi lilikubali. Soma hilo kabla ya mtu yeyote kuhariri jina la mkuu wa huduma.

Kikao kinataja mpango uliouipata kwa kweli

Mpango wa uthibitishaji ni wa muunganisho na si wa seva au handaki, kwa hivyo ukaguzi lazima uendeshwe ndani ya kikao unachokijali. Tekeleza swali lililo hapa chini kutoka kwa mteja, chombo na akaunti zile zile zilizotengeneza ripoti, na uandike jina la lengo na usafiri kando ya tokeo.

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

Safu kutoka kwa dirisha la SSMS la ndani kwenye mwenyeji wa hifadhidata inaeleza muunganisho tofauti kabisa, ndiyo sababu swali lazima liendeshwe kutoka upande wa mteja. Hifadhi matokeo pamoja na muhuri wa muda, kwa sababu mtu anayefuata kuyasoma atauliza yalichukuliwa lini. Wakati programu kadhaa zinashiriki ncha moja ya mwisho, chukua sampuli kutoka kwa kila moja, kwa sababu tofauti ya chanzo cha data kati ya programu mbili mara nyingi ndiyo hadithi yote.

Sharti la kwanza: je, jina linalingana na SPN?

Kerberos huthibitisha huduma yenye jina, kwa hivyo mteja anaomba saraka tikiti kwa mkuu mmoja maalum. Kwa mtoa huduma wa TCP umbo lililoandikwa ni MSSQLSvc/ likifuatiwa na jina kamili la mwenyeji na, kwa mfano wa chaguo-msingi, bandari. Mfano wenye jina husajili MSSQLSvc/db01.corp.example:SQLPROD, ambapo kiambishi ni jina la mfano badala ya nambari. Kufikia msikilizaji kupitia jina la utani, CNAME inayotatuliwa mahali pengine au anwani tupu ya IP hubadilisha jina lililoombwa, na ombi lisilo na mkuu anayelingana halina tikiti la kurudisha.

Ndiyo sababu programu moja inafanya kazi kwenye mtandao mmoja na kurudi kwenye mwingine: jibu la DNS, rekodi ya jina la utani au ingizo la hosts lilibadilisha jina ambalo mteja alitumia. Linganisha jina lililoombwa na lile ambalo saraka inalo kabla ya kugusa usajili.

Sharti la pili: je, SPN iko kwenye akaunti sahihi?

SPN lazima iwe mali ya akaunti inayoendesha huduma ya SQL, si ya akaunti ya mteja na si kwa bahati kitu cha kompyuta. SQL Server inaweza kusajili SPN zake yenyewe wakati wa kuanza ikiwa akaunti yake ya huduma ina ruhusa ya kuziandika, jambo ambalo ni rahisi na pia linaeleza jinsi nakala inavyoonekana baada ya kubadilisha akaunti ya huduma.

Uliza saraka kuhusu jina unalotarajia, kisha oorodhesha kile ambacho akaunti inamiliki kwa kweli. Kitu gani kinashikilia ingizo ni muhimu zaidi kuliko kama jina lipo mahali pengine msituni. Kutolingana kunamaanisha kuingia hakikuwa tatizo kamwe, na mwongozo wa SPN wa Microsoft unaandika maumbo na kesi ambazo msimamizi wa kikoa lazima atengeneze ingizo.

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

Kuongeza ingizo lingine si jaribio salama. Nakala au usajili unaogongana unaweza kuvunja wateja waliokuwa wakifanya kazi, kwa hivyo kagua umiliki kabla ya mabadiliko na uangalie tena baada yake.

Sharti la tatu: je, mteja anaweza kupata tikiti hata kidogo?

SPN sahihi haina maana ikiwa mteja hawezi kufikia kidhibiti cha kikoa au hana muktadha wa vitambulisho unaoweza kutumika. Ubadilishanaji unahitaji KDC na DNS kupitia VPN, na handaki inayopitisha bandari ya SQL pekee inashindwa katika hatua hii hasa. Ufikivu lazima ujaribiwe kutoka kwa mashine moja na akaunti moja, si kutoka kwa ukuta wa moto ulio mbele yao.

Kagua akiba ya tikiti kwenye mashine na chini ya akaunti inayoendesha programu. Orodha ya mashine yote kutoka kwa dirisha lililoinuliwa haisemi chochote kuhusu huduma inayoendeshwa kama mtumiaji mwingine, na akiba tupu kwa mtumiaji huyo ni ugunduzi na si usumbufu.

klist
klist -li 0x3e7

Kisha amua nini kurudi nyuma kunaweza kufanya. Ikiwa sera inahitaji Kerberos, NTLM lazima ikataliwe waziwazi, kwa sababu kurudi nyuma kwa utulivu hubadilisha hitilafu ya usanidi kuwa muunganisho unaofanya kazi unaovunja sharti. Ikiwa NTLM inabaki kukubalika kwa programu fulani, zitaje na acha kuchukua kila kikao cha NTLM kama tukio.

Kubadilisha kianzishi ni kigezo kimoja, si marekebisho

Kuanzisha SSMS chini ya kitambulisho kingine kunaweza kuponya utambulisho wa nje usiotarajiwa, ambao ni tabaka halisi la matatizo. Haimithirii chochote kuhusu jina la lengo, usajili au njia ya tikiti, na haibadilishi kile seva ilichokubali.

Weka ulinganisho chini ya udhibiti: ncha moja ya mwisho, mtoa huduma yule yule, muktadha unaojulikana wa utekelezaji, kisha muunganisho mpya ambao unakagua mpango wake. Thibitisha kuingia kulikokubaliwa na ruhusa zake za hifadhidata kwa tofauti, kwa sababu ufikiaji na uthibitishaji hushindwa kwa sababu tofauti.

Wakati Kerberos inahitajika, andika kwa nini njia ya kwanza ilirudi nyuma, tumia marekebisho moja na uendeshe swali tena kutoka kwa mteja yule yule. Swali lililofanikiwa baada ya kubadilisha kianzishi ni ushahidi wa ufikiaji, na bado si ushahidi kwamba sharti la uthibitishaji lilitimizwa.