VPN inaunganisha, lakini SQL Server inakataa uthibitishaji wa Windows

Handaki zinapanda, seva zinajibu ping, na kuingia kwenye hifadhidata bado kunashindikana kwa hitilafu ya uthibitishaji. Mchanganyiko huo ni wa kawaida kwenye viungo vya VPN na mara chache humaanisha kwamba mtandao umeharibika, kwa sababu msikilizaji anayefikika na kuingia kulikokubaliwa ni matokeo mawili tofauti. Utambulisho ulioridhisha lango si lazima uwe utambulisho ambao mteja wa hifadhidata hutoa. Kujua ni akaunti gani iliyofika ndiyo kazi yote.

Dalili: seva inayofikika, kuingia kulikataliwa

Muda wa kusubiri unakuambia kwamba kifurushi hakikuwahi kufika kwa msikilizaji. Hitilafu ya uthibitishaji inakuambia kwamba msikilizaji alijibu na kukataa kitambulisho. Ujumbe huo miwili unakutuma kwa timu tofauti, na kuchanganya kwao kunapoteza siku moja kwenye sheria za ngome ambazo hazikuwa tatizo kamwe.

Hitilafu inapokuwa kuingia kushindikana, acha kuangalia bandari. Swali lililobaki ni utambulisho upi wa Windows ambao mteja aliwasilisha, kama seva ilikubali utambulisho huo, na kama ulitatuliwa kuwa mtumiaji wa hifadhidata mwenye ruhusa.

Vitambulisho viwili, handaki moja

Akaunti ya VPN huthibitisha kwenye lango na katika usanidi mwingi huishia hapo. Mteja wa hifadhidata huwasilisha kando tokeni ya Windows, iliyochukuliwa kutoka mchakato unaoifanya, au kuingia kwa SQL ikiwa mnyororo wa muunganisho unaiomba. Mtumiaji wa VPN wa ndani kwenye lango hana uhusiano wowote na kikoa kinachopangisha SQL Server, na handaki haiundi uhusiano huo.

Kuunganisha mashine binafsi kwenye VPN pia hakuiongezi kwenye kikoa. Kubadilisha jina la akaunti ya ndani na kulinganisha nenosiri lake na mtumiaji wa kikoa si utaratibu wa usajili, na hutoa tokeni ambayo kidhibiti cha kikoa hakitakubali kama mtumiaji huyo.

Baadhi ya wateja asilia wa ufikiaji wa mbali wa Windows wanaweza kutumia tena kitambulisho cha VPN kwa rasilimali za mtandao wakati profaili yao imesanidiwa hivyo. Tabia hiyo ni ya mteja na profaili mahususi, si ya miunganisho ya VPN kwa ujumla, kwa hivyo ithibitishe kwa mteja anayetumika badala ya kuichukulia.

Soma hali ambayo mteja aliomba

Mnyororo wa muunganisho huamua njia ya uthibitishaji ambayo mteja huchukua. Usalama jumuishi hutumia tokeni ya Windows; jozi ya mtumiaji na nenosiri huchagua kuingia kwa SQL. Hizi ni hali tofauti katika usanidi wa seva, na ni moja tu kati yao inayoweza kuwashwa kwa jaribio fulani la muunganisho.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Kuhamia kuingia kwa SQL kwa sababu kuingia kwa Windows kumeshindikana ni suluhisho la muda linaloficha swali la utambulisho, na kwa kawaida huhitaji kuunda kuingia na nenosiri jipya hata hivyo. Ikiwa usanidi unahitaji uthibitishaji wa Windows, shikilia hali hiyo na urekebishe njia ya utambulisho. Kuingia kwa SQL pia kunahitaji ruhusa zake, kwa hivyo suluhisho hilo hununua akaunti ya pili ya kuitunza.

Thibitisha pia ni programu gani inaunganisha. Huduma inayoendeshwa kama akaunti ya mfumo, kazi iliyoratibiwa na dirisha la maswali shirikishi zinaweza kuwasilisha tokeni tatu tofauti kwenye mashine moja, na ya mwisho pekee ndiyo inayolingana na kile mtumiaji anachokiona anapotekeleza whoami.

Uliza seva kile ilichokiona kwa hakika

Seva inaweza kukuambia ni kuingia gani iliitatua na jinsi muunganisho ulithibitishwa. Tekeleza swali ndani ya kipindi kinachochunguzwa, kwa sababu muunganisho mzuri tofauti wa msimamizi hauthibitishi chochote kuhusu mteja anayeshindikana.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Safu ya kwanza inatofautisha kuingia kulikofungua kipindi na muktadha wa usalama unaotumika sasa, na hizi hutofautiana chini ya uigaji. Ya pili inataja mpango wa uthibitishaji, kwa hivyo KERBEROS, NTLM na SQL huwa ukweli unaoonekana badala ya makisio. Muunganisho unaoripoti NTLM mahali ulipokuwa unatarajia Kerberos ni tatizo la utatuzi wa majina au SPN, si tatizo la nenosiri.

Nambari ya hitilafu inaibana zaidi. Hali 5 kwa kawaida humaanisha jina la kuingia halikutatuliwa kabisa, hali 8 kwa kawaida humaanisha nenosiri halikulingana, na hali 11 humaanisha kitambulisho kilikubaliwa lakini ufikiaji wa seva ulishindikana. Omba hali kwa msimamizi badala ya ujumbe wote, kwa sababu ujumbe peke yake kwa makusudi hauna uwazi.

Wakati utambulisho unafika na Kerberos bado inashindikana

Ikiwa seva inaona utambulisho wa Windows uliokusudiwa na uthibitishaji jumuishi bado unashindikana, tatizo ni ubadilishanaji wenyewe. Kerberos inahitaji jina kuu la huduma lililosajiliwa kwa akaunti ya huduma ya SQL na mteja anayeomba huduma kwa jina linalolingana nalo. Kuunganisha kwa anwani ya IP hakuwezi kulingana na SPN inayotegemea jina, na jina mbadala linaweza kulingana tu ikiwa limesajiliwa pia. Kagua jina ambalo mteja aliandika kwanza kabisa, kwa sababu muunganisho unaofanya kazi kwa jina la mwenyeji na kushindikana kwa IP unaeleza tatizo hili hasa.

Omba msimamizi akague utambulisho uliosajiliwa na akaunti ya huduma badala ya kuunda SPN nakala kwa kujaribu na kukosea. Usajili wa nakala huzaa hitilafu za vipindi ambazo ni vigumu kuzitambua kuliko tatizo la awali.

Baada ya uthibitishaji kufanya kazi, kuingia bado kunahitaji mtumiaji wa hifadhidata na ruhusa. Kuingia kwa VPN kwa mafanikio, kuingia kwa Windows kwa mafanikio na ruhusa ya kusoma jedwali fulani ni matokeo matatu tofauti, na kila moja linastahili ukaguzi wake kabla ya tiketi kufungwa.