Waarom valt SQL Server via een VPN toch terug op NTLM?

Uw verbinding werkt, de aanmelding wordt geaccepteerd, en SQL Server gebruikt NTLM terwijl iedereen Kerberos verwachtte. Dat resultaat is geen VPN-defect, omdat een tunnel alleen een pad levert; het schema werd bepaald door de naam die de client opvroeg, de principal die in de map is geregistreerd en het ticket dat de client werkelijk kon krijgen. Drie voorwaarden moeten tegelijk gelden, en de sessie zelf zegt welke heeft toegegeven. Lees dat voordat iemand een service-principalnaam bewerkt.

De sessie noemt het schema dat u werkelijk hebt gekregen

Het verificatieschema hoort bij een verbinding en niet bij een server of tunnel, dus de controle moet binnen de sessie lopen die u aangaat. Voer de query hieronder uit vanaf dezelfde client, hetzelfde hulpprogramma en hetzelfde account die het rapport hebben gemaakt, en noteer de doelnaam en het transport naast het resultaat.

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

Een rij uit een lokaal SSMS-venster op de databasehost beschrijft een heel andere verbinding, daarom moet de query vanaf de clientzijde lopen. Bewaar de uitvoer met een tijdstempel, omdat de volgende persoon die het leest zal vragen wanneer het is opgenomen. Wanneer meerdere toepassingen één eindpunt delen, neem van elk een steekproef, omdat een verschil in gegevensbron tussen twee toepassingen vaak het hele verhaal is.

Voorwaarde één: past de naam bij de SPN?

Kerberos verifieert een benoemde service, dus de client vraagt de map om een ticket voor één specifieke principal. Voor de TCP-provider is de gedocumenteerde vorm MSSQLSvc/ gevolgd door de volledig gekwalificeerde hostnaam en, voor een standaardexemplaar, de poort. Een benoemd exemplaar registreert MSSQLSvc/db01.corp.example:SQLPROD, waarbij het achtervoegsel de naam van het exemplaar is in plaats van een nummer. De listener bereiken via een alias, een CNAME die elders wordt opgelost of een kaal IP-adres verandert de gevraagde naam, en een verzoek zonder passende principal heeft geen ticket om terug te geven.

Daarom werkt een toepassing op het ene netwerk en valt hij op het andere terug: een DNS-antwoord, een aliasrecord of een hosts-item veranderde de naam die de client gebruikte. Vergelijk de gevraagde naam met wat de map bevat voordat u de registratie aanraakt.

Voorwaarde twee: staat de SPN op het juiste account?

Een SPN moet toebehoren aan het account dat de SQL-service uitvoert, niet aan het account van de client en niet per ongeluk aan een computerobject. SQL Server kan zijn eigen SPN's bij het opstarten registreren wanneer het serviceaccount de machtiging heeft ze te schrijven, wat handig is en ook verklaart hoe een duplicaat ontstaat na een wijziging van het serviceaccount.

Vraag de map om de naam die u verwacht en som vervolgens op wat het account werkelijk bezit. Welk object het item bevat is belangrijker dan of de naam ergens in het forest bestaat. Een afwijking betekent dat de aanmelding nooit het probleem was, en de SPN-gids van Microsoft documenteert de indelingen en de gevallen waarin een domeinbeheerder het item moet aanmaken.

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

Nog een item toevoegen is geen veilig experiment. Een duplicaat of conflicterende registratie kan werkende clients breken, dus inspecteer het eigendom vóór de wijziging en controleer het daarna opnieuw.

Voorwaarde drie: kan de client überhaupt een ticket krijgen?

Een correcte SPN is nutteloos als de client geen domeincontroller kan bereiken of geen bruikbare referentiecontext heeft. De uitwisseling heeft de KDC en DNS via de VPN nodig, en een tunnel die alleen de SQL-poort routeert faalt precies bij deze stap. Bereikbaarheid moet worden getest vanaf dezelfde machine en hetzelfde account, niet vanaf de firewall ervoor.

Inspecteer de ticketcache op de machine en onder het account dat de toepassing uitvoert. Een machinabrede lijst uit een verhoogd venster zegt niets over een service die als een andere gebruiker draait, en een lege cache voor die gebruiker is een bevinding en geen ongemak.

klist
klist -li 0x3e7

Beslis daarna wat een terugval mag doen. Als beleid Kerberos vereist, moet NTLM uitdrukkelijk worden geweigerd, omdat een stille terugval een configuratiefout omzet in een werkende verbinding die de eis schendt. Als NTLM voor sommige toepassingen aanvaardbaar blijft, noem ze en stop met het behandelen van elke NTLM-sessie als incident.

De starter wijzigen is één variabele, geen oplossing

SSMS onder andere referenties starten kan een onbedoelde uitgaande identiteit genezen, wat een echte probleemklasse is. Het bewijst niets over de doelnaam, de registratie of het ticketpad, en het verandert niet wat de server heeft geaccepteerd.

Houd de vergelijking gecontroleerd: hetzelfde eindpunt, dezelfde provider, een bekende uitvoeringscontext, dan een nieuwe verbinding waarvan u het schema inspecteert. Bevestig de geaccepteerde aanmelding en de databasemachtigingen afzonderlijk, omdat toegang en verificatie om verschillende redenen falen.

Wanneer Kerberos vereist is, noteer waarom het eerste pad terugviel, pas één correctie toe en voer de query opnieuw uit vanaf dezelfde client. Een geslaagde query na een wijziging van de starter is bewijs van toegang, en het is nog geen bewijs dat aan de verificatie-eis is voldaan.