Heute musste ich mit einem mir bisher unbekannten „Login nicht möglich“-Problem kämpfen: Error: 17832, Severity: 20, State: 8 auf einem SQL Server 2008 R2. Auch die Fehlermeldung im SQL Server Log hatte ich so noch nicht gesehen, geschweige denn davon gehört.

The login packet used to open the connection is structurally invalid; the connection has been closed.
Erklärung
Der SQL Server-Computer konnte das Clientanmeldepaket nicht verarbeiten. Das liegt möglicherweise daran, dass das Paket nicht ordnungsgemäß erstellt wurde oder dass das Paket während der Übertragung beschädigt wurde. Es kann auch durch die Konfiguration des SQL Server-Computers verursacht werden. Die aufgeführte IP-Adresse ist die Adresse des Clientcomputers.

Login nicht möglich mit sehr vielen Ursachen

Aber fangen wir vorne an… Kunde meldet, er könne sich nicht an seinem SQL Server anmelden, auf der Testumgebung ginge das, aber auf der Produktionsumgebung nicht. Ein Blick ins SQL Server Log ergab, dass der benutzte User nicht passt.

Kurz überprüft, welche Möglichkeiten es für diesen User gibt bzw wie der User auf dem SQL Server eingerichtet ist, um ggfs zu verstehen warum denn ein Login nicht möglich ist. Den Kunden angerufen und mir noch einmal direkt erklären lassen, was er wie macht und wobei sein Problem genau auftritt.

Da der Kunde mehrere User zur Auswahl hatte und es anscheinend nur bei seinem User ein Login Problem gab… habe ich den SQL Server nochmal etwas genauer unter die Lupe genommen. Das erste was mir gravierend auffiel, war die SQL Server Version 10.50.2500 also nur Service Pack 1 (auch die Edition – aber manche Kunden wünschen sich das so): „Das liegt bestimmt an dem uralten Release-Stand“, also den Server auf einen wesentlich aktuelleren Stand gebracht (10.50.6529 – MS15-058 -Security Update for SQL Server 2008 R2), den Kunden informiert, er möge doch bitte testen.

Nach einigen Test erhielt ich die Rückmeldung: „Nein, es funktioniert immer noch nicht. Aber er hätte jetzt auch mal eine andere Fehlermeldung erhalten…“ Also schnell nochmal ins Log geschaut und festgestellt, dass tatsächlich immer noch der Login nicht möglich ist, aber eine neue Fehlermeldung hinzugekommen ist.

Error: 17832, Severity: 20, State: 8 – The login packet used to open the connection is structurally invalid

Nun gut, schnell Tante Google gefragt und siehe da… der Fehler ist lange bekannt (mir zum Glück noch nicht untergekommen) und entsprechend dokumentiert. Auf den Microsoft Seiten findet man folgenden Text:

Weitere Informationen
Bei der Verwendung der Windows-Authentifizierung in einer Kerberos-Umgebung empfängt der Client ein Kerberos-Ticket, das ein Zertifikat mit Berechtigungsattributen (Privilege Attribute Certificate, PAC) enthält. Das PAC enthält verschiedene Typen von Autorisierungsdaten einschließlich Gruppen, in denen der Benutzer Mitglied ist, Rechte, über die der Benutzer verfügt, und welche Richtlinien für den Benutzer gelten. Wenn der Client das Kerberos-Ticket empfängt, werden die in dem PAC enthaltenen Informationen verwendet, um das Zugriffstoken des Benutzers zu generieren. Der Client stellt das Token für den SQL Server-Computer als Teil des Anmeldungspakets bereit.
Wenn das Token nicht ordnungsgemäß erstellt wurde oder während der Übertragung beschädigt wurde, kann SQL Server keine weiteren Informationen über das Problem anbieten.

Wenn der Benutzer Mitglied zahlreicher Gruppen ist oder über zahlreiche Richtlinien verfügt, kann das Token bei ihrer Auflistung größer als üblich werden. Wenn das Token größer als der MaxTokenSize-Wert des Servercomputers wird, schlägt die Herstellung einer Verbindung durch den Client mit einem allgemeinen Netzwerkfehler (General Network Error, GNE) fehl, und es kann ein Fehler 17832 auftreten. Dieses Problem beeinflusst möglicherweise nur einige Benutzer: Benutzer mit vielen Gruppen oder Richtlinien. Wenn das Problem in dem MaxTokenSize-Wert des Servercomputers besteht, wird der Fehler 17832 im SQL Server-Fehlerprotokoll von einem Fehler mit dem Status 9 begleitet. Weitere Einzelheiten zu Kerberos und MaxTokenSize finden Sie unter KB327825.

Und nicht nur eine Erläuterung habe ich dort gefunden, sondern natürlich auch eine Lösung! 😉

So ändern Sie die MaxTokenSize auf dem Servercomputer

1. Klicken Sie im Menü Start auf den Befehl Ausführen.
2. Geben Sie regedit ein, und klicken Sie auf OK. (Wenn das Dialogfeld Benutzerkontensteuerung angezeigt wird, klicken Sie auf Weiter.)
3. Navigieren Sie zu HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
4. Wenn der MaxTokenSize-Parameter nicht vorhanden ist, klicken Sie mit der rechten Maustaste auf Parameter, zeigen Sie auf Neu, und klicken Sie dann auf DWORD (32-Bit)-Wert. Geben Sie dem Registrierungseintrag die Bezeichnung MaxTokenSize.
5. Klicken Sie mit der rechten Maustaste auf MaxTokenSize, und klicken Sie dann auf Ändern.
6. Geben Sie im Feld Wertdaten den gewünschten MaxTokenSize-Wert an. (Maximaler Wert ist ffff  => 65535)
7. Klicken Sie auf **OK**.
8. Schließen Sie den Registrierungs-Editor.
9. Starten Sie den Computer neu.

Nun konnte mein Kunde erneut testen… Er konnte leider immer noch keine Erfolgsmeldung übermitteln, diesmal aber nicht weil der Login am SQL Server gescheitert war, sondern weil sein SQL-Statement innerhalb der Appliaktion einen Syntax-Fehler aufwies. Chackaa … also Fehler gefunden, SQL Server erfolgreich gepatcht, fehlten SQL Server Login behoben (neue Situation/Meldung kennengelernt), Kunden glücklich gemacht. 😉

Der Kunde bzw sein User scheint also in zahlreichen Domänen-Gruppen und Gruppenrichtlinien verschachtelt zu sein, so dass der Kerberos-Token zu viele Informationen aufnehmen müsste, dies aber nicht kann, da der Wert für MaxTokenSize nicht definiert oder zu klein bemessen wurde. Hier hilft nur die Beschränkungen auf dem Ziel-Server zu erweitern oder ganz zu definieren. Ich habe es gleich auf das Maximum getrieben und den Wert auf „ffff“ gesetzt.