Warum fällt SQL Server über ein VPN weiterhin auf NTLM zurück?

Ihre Verbindung funktioniert, die Anmeldung wird akzeptiert, und SQL Server verwendet NTLM, während alle Kerberos erwartet haben. Dieses Ergebnis ist kein VPN-Fehler, denn ein Tunnel liefert nur einen Pfad; das Schema bestimmten der Name, den der Client angefragt hat, der im Verzeichnis registrierte Prinzipal und das Ticket, das der Client tatsächlich erhalten konnte. Drei Bedingungen müssen gleichzeitig gelten, und die Sitzung selbst sagt, welche nachgegeben hat. Lesen Sie das, bevor jemand einen Dienstprinzipalnamen bearbeitet.

Die Sitzung nennt das Schema, das Sie tatsächlich bekommen haben

Das Authentifizierungsschema gehört zu einer Verbindung und nicht zu einem Server oder Tunnel, deshalb muss die Prüfung in der Sitzung laufen, die Sie interessiert. Führen Sie die Abfrage unten mit demselben Client, Werkzeug und Konto aus, die den Bericht erzeugt haben, und notieren Sie Zielname und Transport neben dem Ergebnis.

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

Eine Zeile aus einem lokalen SSMS-Fenster auf dem Datenbankhost beschreibt eine völlig andere Verbindung, weshalb die Abfrage von der Clientseite laufen muss. Speichern Sie die Ausgabe mit Zeitstempel, denn die nächste Person, die sie liest, wird fragen, wann sie erfasst wurde. Wenn mehrere Anwendungen einen Endpunkt teilen, beproben Sie jede, denn ein Unterschied in der Datenquelle zwischen zwei Anwendungen ist oft die ganze Geschichte.

Bedingung eins: Passt der Name zum SPN?

Kerberos authentifiziert einen benannten Dienst, deshalb fragt der Client das Verzeichnis nach einem Ticket für einen bestimmten Prinzipal. Für den TCP-Anbieter ist die dokumentierte Form MSSQLSvc/ gefolgt vom vollqualifizierten Hostnamen und bei einer Standardinstanz vom Port. Eine benannte Instanz registriert MSSQLSvc/db01.corp.example:SQLPROD, wobei das Suffix der Instanzname statt einer Nummer ist. Wird der Listener über einen Alias, einen CNAME, der anderswo aufgelöst wird, oder eine bloße IP-Adresse erreicht, ändert sich der angefragte Name, und eine Anfrage ohne passenden Prinzipal hat kein Ticket zurückzugeben.

Deshalb funktioniert eine Anwendung in einem Netz und fällt in einem anderen zurück: Eine DNS-Antwort, ein Aliasdatensatz oder ein hosts-Eintrag haben den Namen geändert, den der Client verwendet hat. Vergleichen Sie den angefragten Namen mit dem, was das Verzeichnis enthält, bevor Sie die Registrierung anfassen.

Bedingung zwei: Steht der SPN auf dem richtigen Konto?

Ein SPN muss zu dem Konto gehören, das den SQL-Dienst ausführt, nicht zum Konto des Clients und nicht versehentlich zu einem Computerobjekt. SQL Server kann seine eigenen SPNs beim Start registrieren, wenn sein Dienstkonto die Berechtigung hat, sie zu schreiben, was praktisch ist und auch erklärt, wie nach einem Wechsel des Dienstkontos ein Duplikat entsteht.

Fragen Sie das Verzeichnis nach dem erwarteten Namen und listen Sie dann auf, was das Konto tatsächlich besitzt. Welches Objekt den Eintrag hält, ist wichtiger als die Frage, ob der Name irgendwo im Wald existiert. Eine Abweichung bedeutet, dass die Anmeldung nie das Problem war, und Microsofts SPN-Leitfaden dokumentiert die Formate und die Fälle, in denen ein Domänenadministrator den Eintrag anlegen muss.

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

Einen weiteren Eintrag hinzuzufügen ist kein sicheres Experiment. Ein Duplikat oder eine widersprüchliche Registrierung kann funktionierende Clients brechen, prüfen Sie daher das Eigentum vor der Änderung und danach erneut.

Bedingung drei: Kann der Client überhaupt ein Ticket bekommen?

Ein korrekter SPN ist nutzlos, wenn der Client keinen Domänencontroller erreicht oder keinen brauchbaren Anmeldeinformationskontext hat. Der Austausch braucht den KDC und DNS über das VPN, und ein Tunnel, der nur den SQL-Port routet, scheitert genau an diesem Schritt. Erreichbarkeit muss von derselben Maschine und demselben Konto getestet werden, nicht von der Firewall davor.

Prüfen Sie den Ticket-Cache auf der Maschine und unter dem Konto, das die Anwendung ausführt. Eine maschinenweite Liste aus einem erhöhten Fenster sagt nichts über einen Dienst, der als anderer Benutzer läuft, und ein leerer Cache für diesen Benutzer ist ein Befund und keine Unannehmlichkeit.

klist
klist -li 0x3e7

Entscheiden Sie dann, was ein Rückfall tun darf. Wenn die Richtlinie Kerberos verlangt, muss NTLM ausdrücklich abgelehnt werden, denn ein stiller Rückfall verwandelt einen Konfigurationsfehler in eine funktionierende Verbindung, die die Anforderung verletzt. Bleibt NTLM für einige Anwendungen akzeptabel, benennen Sie sie und hören Sie auf, jede NTLM-Sitzung als Vorfall zu behandeln.

Den Starter zu ändern ist eine Variable, keine Lösung

SSMS unter anderen Anmeldeinformationen zu starten kann eine unbeabsichtigte ausgehende Identität heilen, was eine echte Problemklasse ist. Es beweist nichts über den Zielnamen, die Registrierung oder den Ticketpfad und ändert nicht, was der Server akzeptiert hat.

Halten Sie den Vergleich kontrolliert: derselbe Endpunkt, derselbe Anbieter, ein bekannter Ausführungskontext, dann eine frische Verbindung, deren Schema Sie prüfen. Bestätigen Sie die akzeptierte Anmeldung und ihre Datenbankberechtigungen getrennt, denn Zugriff und Authentifizierung scheitern aus unterschiedlichen Gründen.

Wenn Kerberos erforderlich ist, halten Sie fest, warum der erste Weg zurückfiel, wenden Sie eine Korrektur an und führen Sie die Abfrage erneut vom selben Client aus. Eine erfolgreiche Abfrage nach einer Änderung des Starters ist ein Beleg für Zugriff und noch kein Beleg dafür, dass die Authentifizierungsanforderung erfüllt wurde.