Wêrom falt SQL Server oer in VPN noch altyd werom op NTLM?

Jo ferbining wurket, de oanmelding wurdt akseptearre en SQL Server brûkt NTLM wylst elkenien Kerberos ferwachte. Dat resultaat is gjin VPN-defekt, want in tunnel leveret allinnich in paad; it skema waard bepaald troch de namme dy’t de klant oanfrege, de principal dy’t yn it katalogus registrearre is en it ticket dat de klant echt krije koe. Trije betingsten moatte tagelyk jilde, en de sesje sels seit hokker ien tajoech. Lês dat foardat immen in tsjinstprinsipalnamme bewurket.

De sesje neamt it skema dat jo echt krigen hawwe

It autentikaasjeskema heart by in ferbining en net by in tsjinner of in tunnel, dus de kontrôle moat binnen de sesje rinne dy’t jo oanbelanget. Fier de query hjirûnder út fan deselde klant, ark en akkount dy’t it rapport makken, en skriuw de doelnamme en it ferfier njonken it resultaat.

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

In rige út in lokaal SSMS-finster op de databasehost beskreaut in hiel oare ferbining, en dêrom moat de query fan de klantzijde rinne. Bewarje de útfier mei in tiidstimpel, want de folgjende persoan dy’t it lêst sil freegje wannear’t it nomd is. As ferskate applikaasjes ien einpunt diele, nim dan in stekproef fan elk, want in ferskil yn databoarne tusken twa applikaasjes is faak it hiele ferhaal.

Betingst ien: past de namme by it SPN?

Kerberos autentisearret in neamde tsjinst, dus de klant freget it katalogus om in ticket foar ien spesifike principal. Foar de TCP-provider is de dokumintearre foarm MSSQLSvc/ folge troch de folslein kwalifisearre hostnamme en, foar in standert eksimplaar, de poarte. In neamd eksimplaar registrearret MSSQLSvc/db01.corp.example:SQLPROD, wêrby’t it efterheaksel de namme fan it eksimplaar is ynstee fan in nûmer. It berikken fan de listener fia in alias, in CNAME dy’t earne oars oplost of in neaken IP-adres feroaret de oanfrege namme, en in fersyk sûnder passende principal hat gjin ticket om werom te jaan.

Dêrom wurket ien applikaasje op ien netwurk en falt er op in oar werom: in DNS-antwurd, in aliasrekord of in hosts-ynfier feroare de namme dy’t de klant brûkte. Fergelykje de oanfrege namme mei wat it katalogus hat foardat jo de registraasje oanreitsje.

Betingst twa: is it SPN op it krekte akkount?

In SPN moat ta it akkount hearre dat de SQL-tsjinst rint, net ta it akkount fan de klant en net by ûngelok ta in kompjûterobjekt. SQL Server kin by it opstarten syn eigen SPN’s registrearje as syn tsjinstakkount de tastimming hat se te skriuwen, wat handich is en ek ferklearret hoe’t in duplikaat ûntstiet nei in feroaring fan tsjinstakkount.

Freegje it katalogus om de namme dy’t jo ferwachtsje, en lis dan op wat it akkount echt besit. Hokker objekt de ynfier hâldt, is wichtiger as oft de namme earne yn it wâld bestiet. In ôfwiking betsjut dat de oanmelding nea it probleem wie, en de SPN-gids fan Microsoft dokumintearret de foarmen en de gefallen wêryn’t in domeinbehearder de ynfier oanmeitsje moat.

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

In oare ynfier tafoegje is gjin feilich eksperimint. In duplikaat of konfliktregistraasje kin klanten brekke dy’t wurken, dus ûndersykje it eigendom foar de feroaring en kontrolearje it dêrnei wer.

Betingst trije: kin de klant hielendal in ticket krije?

In korrekt SPN is nutteleas as de klant gjin domeincontroller berikke kin of gjin brûkber leauwenkontekst hat. De útwikseling hat de KDC en DNS fia de VPN nedich, en in tunnel dy’t allinnich de SQL-poarte rûtelet mislearret krekt by dizze stap. Berikberens moat fan deselde masine en itselde akkount test wurde, net fan de firewall foar harren.

Undersykje de ticketcache op de masine en ûnder it akkount dat de applikaasje rint. In list foar de hiele masine út in ferhege finster seit neat oer in tsjinst dy’t as in oare brûker rint, en in lege cache foar dy brûker is in befining en gjin ûngemak.

klist
klist -li 0x3e7

Beslis dan wat in weromfal dwaan mei. As belied Kerberos easket, moat NTLM eksplisyt wegere wurde, want in stil weromfal feroaret in konfiguraasjeflater yn in wurkjende ferbining dy’t de eask oertrêdet. As NTLM foar guon applikaasjes akseptabel bliuwt, neam se en hâld op mei elke NTLM-sesje as ynsidint te behanneljen.

It feroarjen fan de starter is ien fariabele, gjin oplossing

SSMS ûnder oare leauwen starte kin in ûnbedoelde útgeande identiteit genêze, wat in echte klasse fan problemen is. It bewiist neat oer de doelnamme, de registraasje of it ticketpaad, en it feroaret net wat de tsjinner akseptearre.

Hâld de fergeliking kontrolearre: itselde einpunt, deselde provider, in bekende útfieringskontekst, dan in nije ferbining waans skema jo ûndersykje. Befêstigje de akseptearre oanmelding en syn databasetastimmingen apart, want tagong en autentikaasje mislearje om ferskillende redenen.

As Kerberos ferplicht is, skriuw dan op wêrom’t it earste paad weromfoel, pas ien korreksje ta en fier de query opnij út fan deselde klant. In suksesfolle query nei in feroaring fan de starter is bewiis fan tagong, en it is noch gjin bewiis dat de autentikaasjebetingst foldien is.