Freigeben über

Zeitweilige oder regelmäßige Authentifizierungsprobleme in SQL Server

  • Artikel

Notiz

Bevor Sie mit der Problembehandlung beginnen, sollten Sie die Voraussetzungen überprüfen und die Checkliste durchgehen. Weitere Informationen finden Sie in den Self-Help-Artikeln.

In diesem Artikel werden häufige Ursachen für zeitweilige Authentifizierungsprobleme in der SQL Server-Konnektivität beschrieben und Lösungen bereitgestellt.

Problembeschreibung

Zeitweilige oder regelmäßige Authentifizierungsprobleme in der SQL Server-Konnektivität treten auf, wenn Benutzer oder Anwendungen sporadische Schwierigkeiten bei der Authentifizierung mit der SQL Server-Datenbank haben. Dies führt zu Unterbrechungen des Datenzugriffs und der Anwendungsfunktionalität.

Die häufigsten Fehlermeldungen

  • Der SSPI-Kontext kann nicht erstellt werden

  • Anmelden für Benutzer fehlgeschlagen

    • Anmelden für Benutzer '' fehlgeschlagen
    • Fehler bei der Anmeldung für den Benutzer 'NT AUTHORITY\ANONYMOUS LOGON'
    • Fehler bei der Anmeldung für den Benutzer "<UserName>"
    • Fehler bei der Anmeldung für den Benutzer "<Domäne>\<Benutzername>"
    • Fehler bei der Anmeldung. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit Windows-Authentifizierung verwendet werden.

Ursache

Die häufigsten Probleme werden durch die SQL Server-Leistung oder langsame Domänencontrollerantwort verursacht. Bei Verwendung von NT LAN Manager (NTLM) weist der Subsystemdienst für lokale Sicherheitsstellen (Local Security Authority Subsystem Service, LSASS) einen Engpass auf und begrenzt, wie viele neue Verbindungen gleichzeitig verarbeitet werden können. Andere Anforderungen werden gesichert und können zeitüberschreitungen. Einige Ursachen, z. B. Antivirus, können schwierig zu beweisen sein, sind aber immer noch üblich und sollten auch ohne harte Beweise untersucht werden, wenn andere Möglichkeiten der Untersuchung unwirksam sind.

Problembehandlungsprozess

Da das Problem zeitweise aufgetreten ist, ist die Konfiguration, z. B. Kerberos-Dienstprinzipalnamen (SPNs), wahrscheinlich richtig. Um dieses Problem zu beheben, probieren Sie die folgenden Schritte zur Problembehandlung aus:

Unterschied bei der Latenz zwischen mehreren Domänen oder Rechenzentren

Wenn mehrere Domänen oder Rechenzentren beteiligt sind, überprüfen Sie, ob die Benutzer in der lokalen Domäne oder im Rechenzentrum das Problem während der Benutzer in anderen Domänen oder Rechenzentren nicht auftreten. Wenn ja, kann dies auf eine Kommunikationslatenz zwischen Rechenzentren oder Domänencontrollern hinweisen. Verwenden Sie die folgenden Befehle, um das Problem zu untersuchen:

  • Verwenden Sie Ping, um die Netzwerklatenz zu überprüfen. Zum Beispiel:

    1. Führen Sie den Befehl ping <DatabaseServer> aus.

    2. Sehen Sie sich die Zeitspalte an, und vergleichen Sie diese Zeit mit dieser in der anderen Domäne oder im Rechenzentrum:

      Pinging <DatabaseServer> [10.10.10.3] with 32 bytes of data:
Reply from 10.10.10.3: bytes=32 time=68ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116

  • Verwenden Sie Runas mit verschiedenen Benutzern, um Probleme mit der Überprüfung der Anmeldeinformationen zu testen. Zum Beispiel:

    1. Führen Sie runas /user:<DomainName>\<UserAccountName> cmd.exe aus.
    2. Geben Sie das Kennwort des Benutzers ein, nachdem eine Eingabeaufforderung angezeigt wird.

Wenn das Problem auch nach dem Testen mit diesen Befehlen weiterhin besteht, liegt das Problem nicht bei SQL Server, sondern bei der Netzwerkinfrastruktur oder Domänencontrollerleistung.

Suchen nach Leistungsproblem im SQL Server-Fehlerprotokoll

Das SQL Server-Fehlerprotokoll kann Leistungsprobleme in SQL Server erkennen, z. B. Einträge, die angeben, dass E/A länger als 15 Sekunden dauert. Das SQL Performance-Team hat PSSDIAG zum Ausführen und Analysieren. Möglicherweise müssen Sie dies tun, wenn eine Netzwerkablaufverfolgung Verzögerungen in SQL Server-Antworten aufgibt.

Das Fehlerprotokoll kann auch andere domänenbezogene Fehler enthalten, z. B. das folgende Fehlerprotokoll, das auf einige Active Directory-Leistungsprobleme hinweist:

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed.

Die folgenden Betriebssystemfehlercodes geben die Ursache des Fehlers an:

  • Fehler -2146893039 (0x80090311): Es konnte keine Autorität zur Authentifizierung kontaktiert werden.

  • Fehler -2146893052 (0x80090304): Die lokale Sicherheitsbehörde kann nicht kontaktiert werden.

Überprüfen von Ereignisprotokollen im Clientsystem auf Netzwerkfehler

Das Systemereignisprotokoll weist verschiedene Ereignisse auf, z. B. Kerberos, Lokale Sicherheitsautorität (Local Security Authority, LSA) und Netlogon-Ereignisse. Diese Ereignisse deuten darauf hin, dass der Computer einige Zeit keine Verbindung mit dem Domänencontroller herstellen kann. Damit sie einfacher zu finden sind, filtern Sie nur Fehler-, Warnungs- und Kritische Ereignisse. Die Ereigniszeit muss um die Zeit des Ausfalls herum sein. Wenn eine Übereinstimmung vorliegt, liegt möglicherweise ein Active Directory-Problem vor.

In einigen Fällen kann dieses Problem auf SQL Server auftreten. Überprüfen Sie auch die Protokolle auf diesem Computer.

Source: NETLOGON
Date: <DateTime>
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLPROD01
Description:
This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following: The remote procedure call was cancelled. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

Filtern Sie im Sicherheitsereignisprotokoll die Ereignis-ID 4625. Dieses Ereignis zeigt detaillierte Informationen zum Anmeldefehler.

Sammeln und Überprüfen des SQL-Verbindungsringpuffers

Der Ringpuffer ist ein historisches Protokoll von Verbindungsereignissen auf SQL Server, was bedeutet, dass er nach einem Ausfall übernommen werden kann. Zu vielen Ereignissen gehören Anmeldezeitgeber, die Ihnen mitteilen, wo Zeit aufgewendet wird:

  • Die für das Netzwerk aufgewendete Zeit gibt eine mögliche Netzwerk- oder Clientlatenz an.
  • Die für SECURE Sockets Layer (SSL) oder SSPI-APIs (Security Support Provider Interface) aufgewendete Zeit gibt potenzielle Probleme mit dem Windows-Sicherheitssubsystem an.
  • Enqueued time indicates a SQL Server performance issue.

Weitere Informationen finden Sie unter Sammeln des Verbindungsringpuffers.

Verbindungspooling

Das Fehlen von Verbindungspooling kann zu zeitweiligen Anmeldefehlern führen.

Notiz

Der Mangel an Verbindungspooling zeigt eine große Anzahl von TIME_WAIT Statuscodes in der NETSTAT Ausgabe im Vergleich zu etablierten Verbindungen an.

Wenn die Verbindungspooling nicht aktiviert ist, kann der Client ausgehende Ports auslaufen und den Server auch überladen. Diese Überladung kann dazu führen, dass der Server eingehende Verbindungsanforderungen ablehnt oder einen schlecht funktionierenden Domänencontroller überflutet.

Das Beste ist, dass der Anwendungsentwickler Verbindungspooling in ihren Anwendungen verwendet. Das Verbindungspooling ist in .NET- und Internetinformationsdienste -Anwendungen (IIS) standardmäßig aktiviert, wurde jedoch möglicherweise aus irgendeinem Grund deaktiviert.

Es wird dringend davon abgeraten, dass Anwendungen benutzerdefinierten Poolingcode verwenden. Fast alle benutzerdefinierten Poolimplementierungen, die aufgetreten sind, hatten Probleme. Es ist besser, den integrierten Verbindungspoolingmechanismus zu verwenden.

Das Auslaufen von kurzlebigen Ports ist eine relativ häufige Ursache für intermittierende Verbindungstimeouts.

Problem: Niedriger Kernelspeicher auf dem SQL Server-Computer.

Lösung: Passen Sie den maximalen Serverspeicher (MB) im Eigenschaftenbereich in SQL Server Management Studio an. Es ist am besten, den maximalen Serverspeicher (MB) auf ca. 4 GB auf 8 GB niedriger als der physische Arbeitsspeicher auf dem Computer festzulegen. Dieser Wert sollte kleiner sein, wenn mehrere Instanzen, IIS oder andere Anwendungsserver auf dem Computer ausgeführt werden. Empfehlungen zur Einstellung für den maximalen Serverspeicher (MB) finden Sie unter Serverspeicherkonfigurationsoptionen.

Notiz

Der Standardwert ist 2147483647 MB, was bedeutet, dass der Server das Betriebssystem (Betriebssystem) nicht mehr genügend Arbeitsspeicher hat.