Hvers vegna fellur SQL Server um VPN samt aftur á NTLM?

Tengingin þín virkar, innskráningin er samþykkt og SQL Server notar NTLM á meðan allir bjuggust við Kerberos. Þessi niðurstaða er ekki VPN-galli, því göng leiða aðeins til vegar; kerfið ráðguðu heitið sem biðlarinn bað um, aðalhluturinn sem skráður er í skránni og miðinn sem biðlarinn gat í raun fengið. Þrjú skilyrði verða að gilda samtímis og lotan sjálf segir hvert þeirra lét undan. Lestu þetta áður en einhver breytir þjónustuaðalheiti.

Lotan nefnir kerfið sem þú fékkst í raun

Auðkenningarkerfið tilheyrir tengingu en ekki þjóni eða göngum, svo prófið verður að keyra innan þeirrar lotu sem þig varðar. Keyrðu fyrirspurnina hér að neðan frá sama biðlara, verkfæri og reikningi og skráðu markheitið og flutninginn við hlið niðurstöðunnar.

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

Röð úr staðbundnum SSMS-glugga á gagnagrunnsþjóninum lýsir allt annarri tengingu, og þess vegna verður fyrirspurnin að keyra frá biðlarahlið. Vistaðu úttakið með tímastimpli, því næsta manneskja sem les það spyr hvenær það var tekið. Þegar nokkrar forrit nota sama endapunkt skaltu taka sýnishorn af hverju, því munur á gagnauppsprettu milli tveggja forrita er oft öll sagan.

Fyrra skilyrði: passar heitið við SPN?

Kerberos auðkennir nafngreinda þjónustu, svo biðlarinn biður skrána um miða fyrir einn tiltekinn aðalhlut. Fyrir TCP-veituna er skjalfesta formið MSSQLSvc/ og á eftir kemur fullt hýsiheiti og, fyrir sjálfgefna tilvik, gáttin. Nafngreint tilvik skráir MSSQLSvc/db01.corp.example:SQLPROD, þar sem viðskeytið er heiti tilviksins í stað tölustafs. Að ná til hlustandans gegnum samheiti, CNAME sem leysist annars staðar eða bert IP-tölu breytir umbeðnu heitinu, og beiðni án samsvarandi aðalhlutar hefur engan miða til að skila.

Þess vegna virkar eitt forrit á einu neti og fellur aftur á öðru: DNS-svar, samheitispostur eða hosts-færsla breytti heitinu sem biðlarinn notaði. Berðu saman umbeðið heiti við það sem skráin geymir áður en þú snertir skráninguna.

Annað skilyrði: er SPN á réttum reikningi?

SPN verður að tilheyra þeim reikningi sem keyrir SQL-þjónustuna, ekki reikningi biðlarans og ekki tölvuandlagi fyrir tilviljun. SQL Server getur skráð eigin SPN við ræsingu þegar þjónustureikningurinn hefur leyfi til að skrifa þau, sem er þægilegt og útskýrir líka hvernig tvírit verður til eftir breytingu á þjónustureikningi.

Spyrðu skrána um heitið sem þú átt von á og listaðu síðan það sem reikningurinn á í raun. Hvaða andlag heldur færslunni skiptir meira máli en hvort heitið er einhvers staðar í skóginum. Ósamræmi þýðir að innskráningin var aldrei vandamálið, og SPN-leiðarvísir Microsoft skjalfestir sniðin og þau tilvik þar sem lénaumsjónarmaður verður að búa til færsluna.

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

Að bæta við annarri færslu er ekki örugg tilraun. Tvírit eða misvísandi skráning getur brotið biðlara sem virkuðu, svo skoðaðu eignarhald fyrir breytinguna og athugaðu aftur eftir hana.

Þriðja skilyrði: getur biðlarinn yfirleitt fengið miða?

Rétt SPN er gagnslaust ef biðlarinn nær ekki lénaumsjóra eða hefur ekki nothæft skírteinissamhengi. Skiptin þurfa KDC og DNS í gegnum VPN, og göng sem beina aðeins SQL-gáttinni mistakast einmitt á þessu þrepi. Prófa verður aðgengi frá sömu vél og sama reikningi, ekki frá eldveggnum fyrir framan þau.

Skoðaðu miðaminnið á vélinni og undir reikningnum sem keyrir forritið. Vélvíður listi úr hækkuðum glugga segir ekkert um þjónustu sem keyrir sem annar notandi, og tómt minni fyrir þann notanda er niðurstaða en ekki óþægindi.

klist
klist -li 0x3e7

Ákveddu síðan hvað afturhvarf má gera. Ef stefna krefst Kerberos verður að hafna NTLM skýrt, því hljóðlaust afturhvarf breytir stillingarvillu í virka tengingu sem brýtur kröfuna. Ef NTLM er áfram ásættanlegt fyrir sum forrit skaltu nefna þau og hætta að meðhöndla hverja NTLM-lotu sem atvik.

Að breyta ræsiforritinu er ein breyta, ekki lagfæring

Að ræsa SSMS undir öðru skírteini getur læknað óviljandi útleiðandi auðkenni, sem er raunverulegur flokkur vandamála. Það sannar ekkert um markheitið, skráninguna eða miðaleiðina og breytir ekki því sem þjónninn samþykkti.

Hafðu samanburðinn stýrðan: sami endapunktur, sama veita, þekkt keyrslusamhengi, síðan ný tenging sem þú skoðar kerfið á. Staðfestu samþykkta innskráningu og gagnagrunnsheimildir hennar aðskilið, því aðgangur og auðkenning mistakast af ólíkum ástæðum.

Þegar Kerberos er krafist skaltu skrá hvers vegna fyrri leiðin féll aftur, beita einni lagfæringu og keyra fyrirspurnina aftur frá sama biðlara. Árangursrík fyrirspurn eftir breytingu á ræsiforritinu er sönnun um aðgang og enn ekki sönnun þess að auðkenningarkrafan hafi verið uppfyllt.