Login fehlgeschlagen — Error 18456 und Verwandte

Der Klassiker mit den State-Codes: Was bedeutet State 2 vs. 38 vs. 58 — und wann steckt Kerberos dahinter?

Es ist Montagmorgen, 08:14 Uhr. Bei der Trendforge Digital GmbH läuft der Kaffee, aber sonst läuft nichts: Das ERP meldet beim Start lapidar Login failed for user 'erp_service', die Hotline des Fachbereichs glüht, und der Kollege vom First-Level hat schon dreimal das Passwort des Anwenders zurückgesetzt — obwohl der Anwender mit dem Problem exakt gar nichts zu tun hat. Am Wochenende wurde ein Datenbankserver umgezogen, und jetzt verweigert der SQL Server reihenweise Anmeldungen. Die Fehlermeldung beim Client ist immer dieselbe, herrlich nichtssagend: Error 18456, State 1.

Willkommen beim Klassiker unter den SQL-Server-Fehlern. Error 18456 ist die häufigste Fehlernummer überhaupt — und gleichzeitig die am häufigsten falsch behandelte, weil fast jeder am falschen Ende anfängt: beim Client. Dabei steht die Wahrheit auf dem Server, genauer gesagt im ERRORLOG, codiert in einem unscheinbaren State-Code. Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht findest du unter /sql-server-notarztwagen/) bringt dir bei, den State-Code zu lesen, die häufigsten Ursachen in Minuten einzukreisen — und die Kerberos-Verwandtschaft rund um Error 18452 gleich mit zu entzaubern.

Was bedeutet Error 18456 technisch?

Error 18456 ist die generische Antwort des SQL Servers auf eine abgelehnte Anmeldung. Generisch ist hier Programm: Der Server sagt dem Client absichtlich nicht, warum die Anmeldung gescheitert ist. Aus Sicherheitssicht ist das vernünftig — ein Angreifer soll nicht erfahren, ob er gerade einen existierenden Login-Namen mit falschem Passwort erwischt hat oder einen Login, den es gar nicht gibt. Deswegen bekommt der Client immer State 1 angezeigt, völlig egal, was wirklich los ist.

Die ehrliche Auskunft schreibt der Server stattdessen in sein ERRORLOG: dieselbe Fehlernummer, aber mit dem echten State-Code und meist einem Klartext-Grund dahinter, etwa Reason: Password did not match that for the login provided oder Reason: Failed to open the explicitly specified database. Der State-Code ist also dein Diagnose-Schlüssel — wer ihn nicht liest, stochert im Nebel und setzt im Zweifel das dritte Anwender-Passwort des Tages zurück, ohne dem Problem auch nur einen Millimeter näher zu kommen.

Wichtig ist die Abgrenzung zu zwei verwandten Situationen. Erstens: Wenn der Client gar nicht erst bis zum SQL Server durchkommt — Netzwerkfehler, falscher Port, Firewall, Instanz nicht erreichbar —, gibt es keinen Error 18456, sondern Verbindungsfehler wie Error 26 (Instanz nicht gefunden) oder Error 10060/10061 (TCP-Verbindung verweigert). Error 18456 heißt im Umkehrschluss immer: Der Server wurde erreicht, er hat die Anmeldung geprüft und bewusst abgelehnt. Das ist diagnostisch Gold wert, weil du Netzwerk und Namensauflösung sofort von der Verdächtigenliste streichen kannst. Zweitens: Error 18452 — der Kerberos-Verwandte, dazu später mehr.

Der Diagnose-Pfad: die State-Codes

Die folgende Tabelle ist das Herzstück der Diagnose. Merke dir den Workflow: Anmeldefehler beim Client gesehen, ab ins ERRORLOG, State-Code nachschlagen, Ursache eingrenzen. Nicht andersherum.

Erste Diagnose: konkrete Skripte

Schritt eins ist immer derselbe: ERRORLOG lesen. Das geht per T-SQL bequem mit xp_readerrorlog — gefiltert auf die Fehlermeldung, damit du nicht durch hunderte Zeilen Backup-Meldungen scrollen musst. Das folgende Skript durchsucht das aktuelle Log nach fehlgeschlagenen Anmeldungen:

In der Ausgabe interessiert dich die Zeile mit Error: 18456, Severity: 14, State: NN — und direkt darunter (oder in derselben Meldung) der Klartext-Grund samt Client-IP in eckigen Klammern. Damit hast du in den meisten Fällen schon drei Viertel der Diagnose erledigt: Du weißt, welches Login betroffen ist, von welcher Maschine der Versuch kommt und welcher State vorliegt. Verdächtig ist alles, was in regelmäßigen Intervallen wiederkehrt — das riecht nach einem Dienst oder geplanten Task mit veralteten Anmeldedaten, nicht nach einem Menschen.

Wenn das ERRORLOG vor lauter Wiederholungen unübersichtlich wird oder du gezielt Applikationsnamen und Hostnamen brauchst, nimm eine Extended-Events-Session. Die folgende Session fängt jeden 18456 mit allen relevanten Begleitdaten ein:

Dritter Baustein, speziell für Windows-Authentifizierung: Prüfe, wie sich die Verbindungen eigentlich authentifizieren. Wenn du Kerberos erwartest und NTLM bekommst, hast du fast sicher ein SPN-Problem — und das ist die Vorstufe zu den 18452-Fehlern, die wir gleich behandeln:

Das Ergebnis liest sich so: SQL bedeutet SQL-Authentifizierung, KERBEROS ist der Soll-Zustand für Domänen-Logins, und NTLM ist im Einzelfall okay (lokale Anmeldung direkt auf dem Server läuft immer über NTLM), aber flächendeckend ein Warnsignal. Notiere dir das Bild — du brauchst es gleich bei Ursache vier.

Die häufigsten Ursachen — und was du dagegen tust

1. Falsches Passwort oder deaktiviertes Login (State 7 und 8)

Der Dauerbrenner — aber selten so banal, wie er klingt. Wenn ein Mensch sich vertippt, ist das kein Notfall. Spannend wird State 8, wenn er im Minutentakt auftaucht: Dann hat irgendwo ein Dienst, ein geplanter Task, ein Monitoring-Agent oder eine vergessene Anwendung noch das alte Passwort im Connection-String. Die Client-IP aus dem ERRORLOG führt dich zur Maschine, der program_name aus der XE-Session zur Anwendung. State 7 ist die Kombination aus deaktiviertem Login und falschem Passwort — prüfe mit SELECT name, is_disabled FROM sys.sql_logins und reaktiviere bei Bedarf mit ALTER LOGIN [name] ENABLE. Aber frag vorher, warum das Login deaktiviert wurde. Manchmal hatte der Kollege einen Grund.

2. Zieldatenbank nicht erreichbar (State 38 und 40)

Login und Passwort stimmen, aber die Datenbank, die die Verbindung öffnen will, existiert nicht, ist offline oder hängt im Recovery. Zwei Varianten: Entweder verlangt der Connection-String explizit eine Datenbank (Initial Catalog), die es nicht mehr gibt — typisch nach Umbenennungen oder Migrationen —, oder die Default-Datenbank des Logins wurde gelöscht. Letzteres ist der heimtückische Klassiker nach dem Aufräumen alter Datenbanken: Drei Wochen später meldet sich ein Login nicht mehr an, und keiner stellt den Zusammenhang her. Die Lösung ist ein Einzeiler:

Ob master als Default elegant ist, darüber lässt sich streiten — aber es ist die einzige Datenbank, die garantiert immer da ist. Hängt die Zieldatenbank dagegen im Status Recovery Pending fest, ist State 38 nur das Symptom eines ganz anderen Notfalls — dann ab zum entsprechenden Beitrag im Notarztwagen.

3. Falscher Authentifizierungsmodus (State 58)

Eine Anwendung versucht SQL-Authentifizierung, aber der Server steht auf Windows Authentication only. Das passiert gern nach Neuinstallationen, bei denen der Mixed Mode im Setup übersprungen wurde, oder wenn eine Anwendung von einem Server auf einen anderen umzieht. Umstellen geht über die Server-Eigenschaften in SSMS (Seite Security) oder per Registry — in beiden Fällen ist ein Neustart des SQL-Dienstes fällig. Plane den ein, statt ihn um 11 Uhr vormittags spontan durchzuziehen. Und nutze die Gelegenheit für eine ehrliche Frage: Muss die Anwendung wirklich SQL-Auth fahren, oder wäre ein Domänen-Service-Account die sauberere Lösung? Band 2 der Buchreihe hat dazu eine klare Meinung.

4. Kerberos, SPNs und der Error 18452 (ANONYMOUS LOGON)

Jetzt zum Verwandten aus dem Untertitel. Wenn im ERRORLOG Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' oder Error 18452 mit untrusted domain auftaucht, ist nicht das Login kaputt, sondern die Windows-Authentifizierung selbst. In neun von zehn Fällen heißt das: Kerberos kommt nicht zustande. Entweder fehlt der SPN (Service Principal Name) für den SQL-Dienst, oder er existiert doppelt, oder er hängt am falschen Konto — etwa noch am Computerkonto, obwohl der Dienst längst unter einem Domänen-Service-Account läuft. Diagnose von der Kommandozeile:

Die zweite Kerberos-Baustelle ist der Double-Hop: Ein Anwender meldet sich an einem Webserver oder Report-Server an, und der greift im Namen des Anwenders auf den SQL Server zu. Ohne konfigurierte Delegation darf der Mittelserver das Anwender-Ticket nicht weiterreichen — die Verbindung kommt beim SQL Server als ANONYMOUS LOGON an und wird abgelehnt. Die Lösung ist Constrained Delegation im Active Directory am Konto des Mittelservers, beschränkt auf den MSSQLSvc-SPN des Ziels. Voraussetzung dafür: Die SPNs stimmen auf beiden Hops. Erst SPNs reparieren, dann Delegation konfigurieren — andersherum wird das nichts.

5. Gültiges Login, aber kein Server-Zugriff (State 11 und 12)

Die Anmeldedaten sind korrekt, aber dem Login fehlt das Recht, sich mit dem Server zu verbinden. Klingt paradox, ist aber Alltag: Da wurde ein Login per DENY CONNECT SQL ausgesperrt, oder ein Windows-Anwender war bisher über eine AD-Gruppe berechtigt, und genau diese Gruppe wurde aufgeräumt. Besonders fies sind verschachtelte Gruppen: Der Anwender ist Mitglied in Gruppe A, Gruppe A war Mitglied in Gruppe B, Gruppe B hatte das SQL-Login — und irgendwer hat die Verschachtelung gelöst. Prüfe Server-Berechtigungen mit sys.server_permissions und lass dir vom AD-Team die effektiven Gruppenmitgliedschaften des Anwenders geben, bevor du am SQL Server schraubst.

Was du auf keinen Fall tun solltest

Nachsorge: Damit es nicht wiederkommt

Wenn der akute Fehler behoben ist, lohnt sich eine halbe Stunde Postmortem. Drei strukturelle Maßnahmen haben sich bewährt: Erstens, ein Login-Inventar pflegen — welcher Dienst nutzt welches Login von welcher Maschine? Beim nächsten Passwortwechsel weißt du dann sofort, welche Connection-Strings anzufassen sind. Zweitens, eine dauerhafte XE-Session auf 18456 mit kleinem Ringpuffer laufen lassen — kostet praktisch nichts und liefert beim nächsten Vorfall die Diagnose frei Haus. Drittens, einen SPN-Check in den regelmäßigen Health Check aufnehmen: setspn -X einmal pro Quartal findet Duplikate, bevor sie zum Montagmorgen-Drama werden. Apropos Health Check: Wie der komplett aussieht, steht im entsprechenden Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Dieser Beitrag kratzt bewusst nur an der Oberfläche der Authentifizierungs-Architektur. Wer tiefer einsteigen will, wird in der Buchreihe „SQL Server in der Praxis“ fündig — die Übersicht aller Bände gibt es auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Login-Fehler treten selten allein auf. Diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege, wenn der Login-Fehler jetzt gerade nervt

Festpreis-Analyse

Der Fehler kommt und geht, keiner findet das Muster, und langsam zweifelt das Team an der eigenen Umgebung? Genau dafür gibt es die Festpreis-Analyse: Ich schaue mir ERRORLOG, Authentifizierungs-Architektur, SPNs und Login-Landschaft strukturiert an und liefere einen Bericht mit konkreten Maßnahmen — zum vorher vereinbarten Festpreis, ohne Stundenzähler-Nervosität.

Akut-Hotline

Wenn gerade die Produktion steht, weil sich ein zentraler Dienst nicht mehr anmeldet: anrufen. Halte das ERRORLOG (oder Remote-Zugriff darauf) und die Information bereit, was sich zuletzt geändert hat — Umzug, Patch, AD-Aufräumaktion. Mit State-Code und Klartext-Reason sind die meisten Login-Notfälle in unter einer Stunde eingekreist.

Selbst-Diagnose-Kit

Du willst es selbst durchziehen? Gute Einstellung. Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — ERRORLOG-Auswertung, XE-Session, auth_scheme-Check, SPN-Prüfliste — als ausführbares Paket mit Auswertungshilfe. Einmal durchlaufen lassen, Ergebnis lesen, Ursache kennen.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was bedeutet SQL Server Error 18456?

Error 18456 ist die generische Meldung „Login failed for user“ — der SQL Server verweigert die Anmeldung, verrät dem Client aber absichtlich nicht, warum. Der eigentliche Grund steckt im State-Code, und den findest du nur im ERRORLOG des Servers, nicht in der Client-Fehlermeldung. State 8 heißt falsches Passwort, State 38 fehlende Zieldatenbank, State 58 falscher Authentifizierungsmodus. Die vollständige Aufschlüsselung der wichtigsten States findest du in der Tabelle im Abschnitt „Der Diagnose-Pfad“ dieses Beitrags.

Was bedeutet State 2 in der Login-Fehlermeldung?

State 2 bedeutet: Das angegebene Login existiert auf diesem Server schlicht nicht. Häufigste Ursachen sind ein Tippfehler im Login-Namen, eine Verbindung zur falschen Instanz (Produktiv statt Test, Default-Instanz statt benannter Instanz) oder ein Login, das auf dem alten Server existierte und beim Umzug nicht mitgenommen wurde. Prüfe mit SELECT name FROM sys.server_principals, ob das Login wirklich da ist — und kontrolliere den Servernamen im Connection-String, bevor du irgendetwas anlegst.

Was bedeutet State 38?

State 38 heißt: Login und Passwort sind in Ordnung, aber die Datenbank, mit der sich die Verbindung öffnen will, ist nicht erreichbar — gelöscht, offline, im Recovery oder umbenannt. Oft steckt eine Default-Datenbank dahinter, die es nicht mehr gibt, oder ein Initial Catalog im Connection-String, der auf eine alte Datenbank zeigt. Lösung: Default-Datenbank mit ALTER LOGIN auf eine existierende Datenbank umbiegen oder den Connection-String korrigieren. Details und das passende Skript stehen im Abschnitt zu den häufigsten Ursachen.

Wie registriere ich einen SPN für SQL Server?

Mit setspn auf einer Domänen-Maschine: setspn -S MSSQLSvc/servername.domain.de:1433 DOMAIN\SqlServiceAccount — einmal mit FQDN und Port, idealerweise zusätzlich mit dem kurzen Hostnamen. Wichtig: Der SPN gehört an den Account, unter dem der SQL-Dienst tatsächlich läuft, nicht an das Computerkonto (außer der Dienst läuft als LocalSystem oder NT Service). Das -S prüft dabei gleich auf Duplikate — ein doppelter SPN ist genauso tödlich wie ein fehlender. Vorher mit setspn -L den Ist-Zustand ansehen.

Was tun, wenn Kerberos-Authentifizierung scheitert?

Zuerst Fakten sammeln statt raten: SELECT auth_scheme FROM sys.dm_exec_connections zeigt dir, ob Verbindungen per KERBEROS oder NTLM laufen. Steht da NTLM, obwohl du Kerberos erwartest, fehlt meist der SPN oder er hängt am falschen Account. Dann setspn -L auf den Service-Account, Duplikate suchen, fehlende SPNs registrieren. Bei Double-Hop-Szenarien (Webserver greift im Namen des Anwenders auf SQL zu) kommt Delegation ins Spiel. Der komplette Diagnose-Pfad steht im Kerberos-Abschnitt dieses Beitrags.

Wie konfiguriere ich Kerberos Delegation für SQL Server?

Delegation brauchst du beim Double-Hop: Ein Mittelserver (Webserver, Reporting, Linked Server) soll mit der Identität des Anwenders auf den SQL Server zugreifen. Konfiguriert wird das im Active Directory am Konto des Mittelservers bzw. dessen Service-Accounts — heute bitte als Constrained Delegation, beschränkt auf den MSSQLSvc-SPN des Ziel-SQL-Servers. Voraussetzung: Die SPNs auf beiden Seiten stimmen, sonst fällt die Kette auf NTLM zurück und du siehst ANONYMOUS LOGON. Die unbeschränkte Delegation aus alten Anleitungen ist ein Sicherheitsrisiko — Finger weg.

Wie aktiviere ich erweitertes Login-Logging?

Standardmäßig protokolliert SQL Server nur fehlgeschlagene Logins. In den Server-Eigenschaften unter Security kannst du auf „Failed and successful logins“ umstellen (Neustart nötig) — sinnvoll, wenn du herausfinden willst, von wo ein bestimmtes Login überhaupt kommt. Für Detektivarbeit ohne ERRORLOG-Geflute ist eine Extended-Events-Session auf error_reported mit Filter auf Error 18456 die elegantere Lösung: Du bekommst Hostname, Applikationsname und Client-IP frei Haus. Das Skript dazu findest du im Diagnose-Abschnitt.