Pse SQL Server përmes VPN vazhdon të bjerë përsëri në NTLM?

Lidhja juaj funksionon, hyrja pranohet dhe SQL Server përdor NTLM ndërsa të gjithë prisnin Kerberos. Ky rezultat nuk është defekt i VPN-së, sepse tuneli ofron vetëm një rrugë; skemën e përcaktuan emri që kërkoi klienti, principali i regjistruar në drejtori dhe bileta që klienti arriti realisht të merrte. Tre kushte duhet të plotësohen njëkohësisht, dhe vetë sesioni thotë cila populloi. Lexojeni këtë përpara se dikush të modifikojë një emër principali shërbimi.

Sesioni emërton skemën që keni marrë realisht

Skema e vërtetimit i përket një lidhjeje dhe jo një serveri ose tuneli, prandaj kontrolli duhet të ekzekutohet brenda sesionit që ju intereson. Ekzekutoni pyetjen më poshtë nga i njëjti klient, mjet dhe llogari që prodhuan raportin, dhe shënoni emrin e synuar dhe transportin pranë rezultatit.

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

Një rresht nga një dritare lokale e SSMS në hostin e bazës së të dhënave përshkruan një lidhje krejt tjetër, prandaj pyetja duhet të ekzekutohet nga ana e klientit. Ruani daljen me një vulë kohore, sepse personi i radhës që do ta lexojë do të pyesë kur u mor. Kur disa aplikacione ndajnë një pikë fundore, merrni një mostër nga secili, sepse një diferencë burimi të dhënash midis dy aplikacioneve shpesh është e gjithë historia.

Kushti i parë: a përputhet emri me SPN?

Kerberos vërteton një shërbim me emër, prandaj klienti i kërkon drejtorisë një biletë për një principal të caktuar. Për ofruesin TCP forma e dokumentuar është MSSQLSvc/ e ndjekur nga emri i plotë i hostit dhe, për një instancë të paracaktuar, porta. Një instancë me emër regjistron MSSQLSvc/db01.corp.example:SQLPROD, ku prapashtesa është emri i instancës në vend të një numri. Arritja e dëgjuesit përmes një pseudonimi, një CNAME që zgjidhet diku tjetër ose një adrese IP të zhveshur ndryshon emrin e kërkuar, dhe një kërkesë pa një principal përputhës nuk ka biletë për të kthyer.

Kjo është arsyeja pse një aplikacion funksionon në një rrjet dhe bie përsëri në një tjetër: një përgjigje DNS, një regjistrim pseudonimi ose një zë hosts ndryshuan emrin që përdori klienti. Krahasoni emrin e kërkuar me atë që mban drejtoria përpara se të prekni regjistrimin.

Kushti i dytë: a është SPN në llogarinë e saktë?

SPN duhet t'i përkasë llogarisë që ekzekuton shërbimin SQL, jo llogarisë së klientit dhe jo, nga aksidenti, një objekti kompjuteri. SQL Server mund të regjistrojë SPN-të e veta në nisje kur llogaria e shërbimit ka lejen t'i shkruajë ato, gjë që është e përshtatshme dhe gjithashtu shpjegon se si shfaqet një dublikatë pas një ndryshimi të llogarisë së shërbimit.

Pyetni drejtorinë për emrin që prisni, më pas listoni çfarë zotëron realisht llogaria. Cili objekt mban zërin ka më shumë rëndësi sesa nëse emri ekziston diku në pyll. Mospërputhja do të thotë që hyrja nuk ishte kurrë problemi, dhe udhëzuesi i SPN i Microsoft dokumenton formatet dhe rastet kur një administrator domeni duhet të krijojë zërin.

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

Shtimi i një zëri tjetër nuk është eksperiment i sigurt. Një dublikatë ose regjistrim konfliktual mund të thyejë klientë që funksiononin, prandaj inspektoni pronësinë përpara ndryshimit dhe rikontrollojeni pas tij.

Kushti i tretë: a mundet klienti të marrë fare një biletë?

Një SPN i saktë është i padobishëm nëse klienti nuk arrin një kontrollues domeni ose nuk ka një kontekst kredencialesh të përdorshëm. Shkëmbimi kërkon KDC dhe DNS përmes VPN-së, dhe një tunel që rrugëton vetëm portën SQL dështon pikërisht në këtë hap. Arritshmëria duhet testuar nga i njëjti makinë dhe e njëjta llogari, jo nga muri i zjarrit përpara tyre.

Inspektoni memorie e përkohshme e biletave në makinë dhe nën llogarinë që ekzekuton aplikacionin. Një listë në nivel makine nga një dritare e ngritur nuk thotë asgjë për një shërbim që ekzekutohet si përdorues tjetër, dhe një memorie e përkohshme bosh për atë përdorues është një gjetje dhe jo një shqetësim.

klist
klist -li 0x3e7

Më pas vendosni çfarë mund të bëjë një rënie përsëri. Nëse politika kërkon Kerberos, NTLM duhet të refuzohet në mënyrë të qartë, sepse një rënie e heshtur e kthen një gabim konfigurimi në një lidhje funksionale që shkel kërkesën. Nëse NTLM mbetet i pranueshëm për disa aplikacione, emërtoni ato dhe ndaloni trajtimin e çdo sesioni NTLM si incident.

Ndryshimi i nisësit është një variabël, jo një rregullim

Nisja e SSMS nën një kredencial tjetër mund të shërojë një identitet dalës të padëshiruar, që është një klasë e vërtetë problemi. Nuk provon asgjë për emrin e synuar, regjistrimin ose rrugën e biletës, dhe nuk ndryshon atë që pranoi serveri.

Mbajeni krahasimin të kontrolluar: e njëjta pikë fundore, i njëjti ofrues, një kontekst ekzekutimi i njohur, pastaj një lidhje e re, skemën e së cilës e inspektoni. Konfirmoni veçmas hyrjen e pranuar dhe lejet e saj në bazën e të dhënave, sepse aksesi dhe vërtetimi dështojnë për arsye të ndryshme.

Kur Kerberos kërkohet, shënoni pse rruga e parë ra përsëri, zbatoni një korrigjim dhe ekzekutoni përsëri pyetjen nga i njëjti klient. Një pyetje e suksesshme pas ndryshimit të nisësit është provë aksesi, dhe ende nuk është provë që kërkesa e vërtetimit u plotësua.