Kial SQL Server tra VPN ankoraŭ falas reen al NTLM?

Via konekto funkcias, la ensaluto estas akceptata kaj SQL Server uzas NTLM dum ĉiuj atendis Kerberos. Tiu rezulto ne estas VPN-difekto, ĉar tunelo nur liveras vojon; la skemon difinis la nomo, kiun la kliento petis, la ĉefobjekto registrita en la dosierujo kaj la bileto, kiun la kliento fakte povis akiri. Tri kondiĉoj devas validi samtempe, kaj la seanco mem diras, kiu cedis. Legu tion antaŭ ol iu redaktos nomon de serva ĉefobjekto.

La seanco nomas la skemon, kiun vi fakte ricevis

La aŭtentiga skemo apartenas al konekto, ne al servilo aŭ tunelo, do la kontrolo devas kuri ene de la seanco, pri kiu vi zorgas. Rulu la suban informpeton el la sama kliento, ilo kaj konto, kiuj produktis la raporton, kaj notu la celan nomon kaj transporton apud la rezulto.

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

Vico el loka SSMS-fenestro sur la datumbaza gastiganto priskribas tute alian konekton, kaj tial la informpeto devas kuri de la klienta flanko. Konservu la eligon kun tempindiko, ĉar la sekva persono, kiu legos ĝin, demandos, kiam ĝi estis prenita. Kiam pluraj aplikaĵoj dividas unu finpunkton, prenu specimenon de ĉiu, ĉar datenfonta diferenco inter du aplikaĵoj ofte estas la tuta rakonto.

Unua kondiĉo: ĉu la nomo kongruas kun la SPN?

Kerberos aŭtentigas nomitan servon, do la kliento petas de la dosierujo bileton por unu specifa ĉefobjekto. Por la TCP-provizanto la dokumentita formo estas MSSQLSvc/ sekvata de la plene kvalifikita gastignoma nomo kaj, por defaŭlta instanco, la pordo. Nomita instanco registras MSSQLSvc/db01.corp.example:SQLPROD, kie la sufikso estas la instanca nomo anstataŭ numero. Atingi la aŭskultanton per aliaso, CNAME, kiu solviĝas aliloke, aŭ nuda IP-adreso ŝanĝas la petitan nomon, kaj peto sen kongrua ĉefobjekto havas neniun bileton por redoni.

Tial unu aplikaĵo funkcias en unu reto kaj falas reen en alia: DNS-respondo, aliasa rikordo aŭ hosts-enskribo ŝanĝis la nomon, kiun la kliento uzis. Komparu la petitan nomon kun tio, kion la dosierujo tenas, antaŭ ol tuŝi la registradon.

Dua kondiĉo: ĉu la SPN estas sur la ĝusta konto?

SPN devas aparteni al la konto, kiu rulas la SQL-servon, ne al la konto de la kliento kaj ne hazarde al komputila objekto. SQL Server povas registri siajn proprajn SPN-ojn ĉe lanĉo, kiam ĝia serva konto havas la permeson skribi ilin, kio estas oportuna kaj ankaŭ klarigas, kiel duplikato aperas post ŝanĝo de serva konto.

Demandu la dosierujon pri la nomo, kiun vi atendas, poste listigu, kion la konto fakte posedas. Kiu objekto tenas la enskribon gravas pli ol ĉu la nomo ekzistas ie en la arbaro. Miskongruo signifas, ke la ensaluto neniam estis la problemo, kaj la SPN-gvidilo de Microsoft dokumentas la formojn kaj la kazojn, en kiuj domajna administranto devas krei la enskribon.

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

Aldoni plian enskribon ne estas sekura eksperimento. Duplikato aŭ konflikta registrado povas rompi klientojn, kiuj funkciis, do kontrolu posedrajton antaŭ la ŝanĝo kaj revizuu ĝin poste.

Tria kondiĉo: ĉu la kliento entute povas akiri bileton?

Ĝusta SPN estas senutila, se la kliento ne povas atingi domajnan regilon aŭ ne havas uzeblan legitimilan kuntekston. La interŝanĝo bezonas la KDC kaj DNS tra la VPN, kaj tunelo, kiu enkursigas nur la SQL-pordon, malsukcesas ĝuste ĉe tiu ĉi paŝo. Atingebleco devas esti testata de la sama maŝino kaj la sama konto, ne de la fajroŝirmilo antaŭ ili.

Kontrolu la biletan kaŝmemoron sur la maŝino kaj sub la konto, kiu rulas la aplikaĵon. Maŝinampleksa listo el privilegiita fenestro diras nenion pri servo ruliĝanta kiel alia uzanto, kaj malplena kaŝmemoro por tiu uzanto estas konstato, ne ĝeno.

klist
klist -li 0x3e7

Poste decidu, kion reenfalo rajtas fari. Se politiko postulas Kerberos, NTLM devas esti eksplicite rifuzata, ĉar silenta reenfalo transformas agordan eraron en funkciantan konekton, kiu malobservas la postulon. Se NTLM restas akceptebla por iuj aplikaĵoj, nomu ilin kaj ĉesu trakti ĉiun NTLM-seancon kiel incidenton.

Ŝanĝi la lanĉilon estas unu variablo, ne riparo

Lanĉi SSMS sub alia legitimilo povas kuracigi neintencitan elirantan identecon, kio estas reala problemklaso. Ĝi pruvas nenion pri la cela nomo, la registrado aŭ la bileta vojo, kaj ĝi ne ŝanĝas tion, kion la servilo akceptis.

Tenu la komparon kontrolata: sama finpunkto, sama provizanto, konata plenumkunteksto, poste freŝa konekto, kies skemon vi kontrolas. Konfirmu la akceptitan ensaluton kaj ĝiajn datumbazajn permesojn aparte, ĉar aliro kaj aŭtentigo malsukcesas pro malsamaj kaŭzoj.

Kiam Kerberos estas postulata, notu, kial la unua vojo reenfalis, apliku unu korekton kaj rerulu la informpeton el la sama kliento. Sukcesa informpeto post ŝanĝo de la lanĉilo estas pruvo de aliro, kaj ĝi ankoraŭ ne estas pruvo, ke la aŭtentiga postulo estis plenumita.