VPN konektiĝas, sed SQL Server malakceptas Windows-aŭtentikigon

Tuneloj leviĝas, serviloj respondas al ping, kaj la datumbaza ensaluto ankoraŭ fiaskas per aŭtentikiga eraro. Tiu kombinaĵo oftas ĉe VPN-ligoj kaj malofte signifas, ke la reto rompiĝis, ĉar atingebla aŭskultanto kaj akceptita ensaluto estas du malsamaj rezultoj. La identeco, kiu kontentigis la pordegon, ne nepre estas la identeco, kiun proponas la datumbaza kliento. Eltrovi, kiu konto alvenis, estas la tuta tasko.

La simptomo: atingebla servilo, malakceptita ensaluto

Tempolimo diras al vi, ke la paketo neniam atingis aŭskultanton. Aŭtentikiga eraro diras, ke la aŭskultanto respondis kaj malakceptis la legitimilon. Tiuj du mesaĝoj sendas vin al malsamaj teamoj, kaj miksi ilin malŝparas tagon por fajroŝirmilaj reguloj, kiuj neniam estis la problemo.

Kiam la eraro estas malsukcesa ensaluto, ĉesu rigardi la pordojn. La restanta demando estas, kiun Windows-identecon la kliento prezentis, ĉu la servilo akceptis tiun identecon, kaj ĉu ĝi solviĝis al datumbaza uzanto kun permeso.

Du identecoj, unu tunelo

La VPN-konto aŭtentikiĝas ĉe la pordego kaj, en plej multaj enkondukoj, finiĝas tie. La datumbaza kliento aparte prezentas Windows-ĵetonon, prenitan el la procezo, kiu ĝin ruligas, aŭ SQL-ensaluton se la konekta ĉeno petas unu. Pordeg-loka VPN-uzanto havas neniun rilaton al la domajno, kiu gastigas SQL Server, kaj la tunelo ne kreas unu.

Konekti personan maŝinon al VPN ankaŭ ne aliĝas ĝin al la domajno. Renomi lokan konton kaj kongruigi ĝian pasvorton al domajna uzanto ne estas aliĝprocedo, kaj ĝi produktas ĵetonon, kiun la domajna regilo ne akceptos kiel tiun uzanton.

Iuj denaskaj Windows-komputiloj por fora aliro povas reuzi la VPN-legitimilon por retaj rimedoj, kiam ilia profilo estas tiel agordita. Tiu konduto apartenas al specifa kliento kaj profilo, ne al VPN-ligoj ĝenerale, do kontrolu ĝin por la uzata kliento anstataŭ supozi ĝin.

Legu la reĝimon, kiun la kliento petis

La konekta ĉeno decidas, kiun aŭtentikigan vojon la kliento sekvas. Integrita sekureco uzas la Windows-ĵetonon; paro de uzanto kaj pasvorto elektas SQL-ensaluton. Tiuj estas apartaj reĝimoj en la servila agordo, kaj nur unu el ili povas esti ŝaltita por donita konekta provo.

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

Ŝalti al SQL-ensaluto ĉar la Windows-ensaluto fiaskis estas provizora solvo, kiu kaŝas la identecan demandon, kaj ĝi kutime tamen postulas krei novan ensaluton kaj pasvorton. Se la enkonduko postulas Windows-aŭtentikigon, konservu la reĝimon kaj riparu la identecan vojon. SQL-ensaluto ankaŭ bezonas siajn proprajn permesojn, do la provizora solvo aĉetas duan konton por prizorgi.

Ankaŭ konfirmu, kiu aplikaĵo konektiĝas. Servo ruliĝanta kiel sistema konto, planita tasko kaj interaga konsulta fenestro povas prezenti tri malsamajn ĵetonojn sur la sama maŝino, kaj nur la lasta kongruas kun tio, kion la uzanto vidas kiam ĝi rulas whoami.

Demandu la servilon, kion ĝi fakte vidis

La servilo povas diri al vi, kiun ensaluton ĝi solvis kaj kiel la konekto aŭtentikiĝis. Rulu la konsulton ene de la esplorata sesio, ĉar aparta sukcesa konekto de administranto pruvas nenion pri la fiaskanta kliento.

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;

La unua vico distingas la ensaluton, kiu malfermis la sesion, de la sekureca kunteksto nun valida, kaj ili diferencas sub identeca ŝajnigo. La dua nomas la aŭtentikigan skemon, do KERBEROS, NTLM kaj SQL fariĝas videblaj faktoj anstataŭ konjektoj. Konekto, kiu raportas NTLM kie vi atendis Kerberos, estas problemo pri nom-solvado aŭ SPN, ne pri pasvorto.

La erarnumero pli mallarĝigas ĝin. Stato 5 kutime signifas, ke la ensaluta nomo tute ne solviĝis, stato 8 kutime signifas, ke la pasvorto ne kongruis, kaj stato 11 signifas, ke la legitimilo akceptiĝis sed la aliro al la servilo fiaskis. Petu de la administranto la staton anstataŭ la tutan mesaĝon, ĉar la mesaĝo sola estas intence malklara.

Kiam la identeco alvenas kaj Kerberos ankoraŭ fiaskas

Se la servilo vidas la celatan Windows-identecon kaj integrita aŭtentikigo ankoraŭ fiaskas, la interŝanĝo mem estas la problemo. Kerberos bezonas la servan ĉefnomon (SPN) registritan por la SQL-serva konto kaj klienton, kiu petas la servon per nomo kongrua al ĝi. Konekti per IP-adreso ne povas kongrui al nom-bazita SPN, kaj alinomo povas kongrui nur se ĝi ankaŭ estas registrita. Kontrolu unue la nomon, kiun la kliento tajpis, ĉar konekto, kiu funkcias per gastiga nomo kaj fiaskas per IP, priskribas ĝuste tiun ĉi problemon.

Petu la administranton revizii la registritan identecon kaj la servan konton anstataŭ krei duplikatajn SPN-ojn per provo kaj eraro. Duplikataj registraĵoj produktas intermitajn fiaskojn, kiujn pli malfacilas diagnozi ol la origina problemo.

Post kiam aŭtentikigo funkcias, la ensaluto ankoraŭ bezonas datumbazan uzanton kaj permesojn. Sukcesa VPN-ensaluto, sukcesa Windows-ensaluto kaj permeso legi apartan tabelon estas tri apartaj rezultoj, kaj ĉiu meritas sian propran kontrolon antaŭ ol fermi la bileton.