VPN verbindet, aber SQL Server lehnt Windows-Authentifizierung ab

Tunnel kommen hoch, Server antworten auf Ping, und der Datenbank-Login scheitert weiterhin mit einem Authentifizierungsfehler. Diese Kombination ist auf VPN-Verbindungen häufig und bedeutet selten, dass das Netzwerk defekt ist, denn ein erreichbarer Listener und ein akzeptierter Login sind zwei verschiedene Ergebnisse. Die Identität, die das Gateway zufriedengestellt hat, ist nicht zwangsläufig die Identität, die der Datenbankclient anbietet. Herauszufinden, welches Konto angekommen ist, ist die ganze Aufgabe.

Das Symptom: erreichbarer Server, abgelehnter Login

Ein Timeout sagt Ihnen, dass das Paket nie einen Listener erreicht hat. Ein Authentifizierungsfehler sagt Ihnen, dass der Listener geantwortet und die Anmeldeinformationen abgelehnt hat. Diese beiden Meldungen schicken Sie an verschiedene Teams, und sie zu verwechseln kostet einen Tag für Firewall-Regeln, die nie das Problem waren.

Wenn der Fehler ein fehlgeschlagener Login ist, hören Sie auf, auf Ports zu schauen. Die verbleibende Frage ist, welche Windows-Identität der Client vorgelegt hat, ob der Server diese Identität akzeptiert hat und ob sie zu einem Datenbankbenutzer mit Berechtigung aufgelöst wurde.

Zwei Identitäten, ein Tunnel

Das VPN-Konto authentifiziert sich am Gateway und endet in den meisten Umgebungen dort. Der Datenbankclient legt getrennt ein Windows-Token vor, das dem Prozess entnommen wird, der ihn ausführt, oder einen SQL-Login, wenn die Verbindungszeichenfolge einen verlangt. Ein gateway-lokaler VPN-Benutzer hat keine Beziehung zu der Domäne, die SQL Server hostet, und der Tunnel stellt keine her.

Einen privaten Rechner mit einem VPN zu verbinden, gliedert ihn auch nicht in die Domäne ein. Ein lokales Konto umzubenennen und sein Passwort an einen Domänenbenutzer anzupassen, ist kein Aufnahmeverfahren, und es erzeugt ein Token, das der Domänencontroller nicht als diesen Benutzer akzeptiert.

Einige native Windows-Remotezugriffsclients können die VPN-Anmeldeinformationen für Netzwerkressourcen wiederverwenden, wenn ihr Profil so konfiguriert ist. Dieses Verhalten gehört zu einem bestimmten Client und Profil, nicht zu VPN-Verbindungen im Allgemeinen, prüfen Sie es also für den verwendeten Client, statt es anzunehmen.

Lesen Sie den Modus, den der Client verlangt hat

Die Verbindungszeichenfolge entscheidet, welchen Authentifizierungspfad der Client nimmt. Integrierte Sicherheit verwendet das Windows-Token; ein Paar aus Benutzer und Passwort wählt einen SQL-Login. Das sind getrennte Modi in der Serverkonfiguration, und für einen bestimmten Verbindungsversuch kann nur einer davon aktiviert sein.

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

Der Wechsel zu einem SQL-Login, weil der Windows-Login fehlgeschlagen ist, ist ein Workaround, der die Identitätsfrage verdeckt, und er erfordert ohnehin meist das Anlegen eines neuen Logins und Passworts. Wenn die Umgebung Windows-Authentifizierung verlangt, behalten Sie den Modus und reparieren Sie den Identitätspfad. Ein SQL-Login braucht außerdem eigene Berechtigungen, der Workaround erkauft also ein zweites Konto zur Pflege.

Prüfen Sie außerdem, welche Anwendung sich verbindet. Ein Dienst, der unter einem Systemkonto läuft, eine geplante Aufgabe und ein interaktives Abfragefenster können auf demselben Rechner drei verschiedene Token vorlegen, und nur das letzte entspricht dem, was der Benutzer sieht, wenn er whoami ausführt.

Fragen Sie den Server, was er tatsächlich gesehen hat

Der Server kann Ihnen sagen, welchen Login er aufgelöst hat und wie sich die Verbindung authentifiziert hat. Führen Sie die Abfrage innerhalb der untersuchten Sitzung aus, denn eine separate erfolgreiche Verbindung eines Administrators beweist nichts über den scheiternden Client.

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;

Die erste Zeile unterscheidet den Login, der die Sitzung geöffnet hat, von dem Sicherheitskontext, der gerade gilt, und diese unterscheiden sich unter Identitätswechsel. Die zweite nennt das Authentifizierungsschema, sodass KERBEROS, NTLM und SQL zu sichtbaren Fakten statt zu Vermutungen werden. Eine Verbindung, die NTLM meldet, wo Sie Kerberos erwartet haben, ist ein Namensauflösungs- oder SPN-Problem, kein Passwortproblem.

Die Fehlernummer grenzt es weiter ein. Status 5 bedeutet meist, dass der Login-Name überhaupt nicht aufgelöst wurde, Status 8 bedeutet meist, dass das Passwort nicht passte, und Status 11 bedeutet, dass die Anmeldeinformationen akzeptiert wurden, der Zugriff auf den Server aber scheiterte. Fragen Sie den Administrator nach dem Status statt nach der ganzen Meldung, denn die Meldung allein ist bewusst vage.

Wenn die Identität ankommt und Kerberos trotzdem scheitert

Wenn der Server die beabsichtigte Windows-Identität sieht und die integrierte Authentifizierung weiterhin scheitert, ist der Austausch selbst das Problem. Kerberos benötigt den für das SQL-Dienstkonto registrierten Dienstprinzipalnamen und einen Client, der den Dienst unter einem dazu passenden Namen anfordert. Eine Verbindung über die IP-Adresse kann keinen namensbasierten SPN treffen, und ein Alias kann nur passen, wenn er ebenfalls registriert ist. Prüfen Sie zuerst den Namen, den der Client eingegeben hat, denn eine Verbindung, die per Hostname funktioniert und per IP scheitert, beschreibt genau dieses Problem.

Bitten Sie den Administrator, die registrierte Identität und das Dienstkonto zu prüfen, statt durch Ausprobieren doppelte SPNs anzulegen. Doppelte Registrierungen erzeugen zeitweise Ausfälle, die schwerer zu diagnostizieren sind als das ursprüngliche Problem.

Nachdem die Authentifizierung funktioniert, braucht der Login weiterhin einen Datenbankbenutzer und Berechtigungen. Ein erfolgreicher VPN-Login, ein erfolgreicher Windows-Login und die Berechtigung, eine bestimmte Tabelle zu lesen, sind drei getrennte Ergebnisse, und jedes verdient seine eigene Prüfung, bevor das Ticket geschlossen wird.