Konsistente Authentifizierungsprobleme in SQL Server
Gilt für: SQL Server
Notiz
Die Befehle, die in diesem Artikel bereitgestellt werden, gelten nur für Windows-Systeme.
Konsistente Authentifizierungsprobleme, die in Microsoft SQL Server auftreten, beziehen sich in der Regel auf die Authentifizierung und Autorisierung von Benutzern oder Anwendungen, die versuchen, auf die SQL Server-Datenbank zuzugreifen. Bei diesen Problemen kann es sich um Authentifizierungsfehler, Zugriffsverweigerungsfehler oder andere sicherheitsbezogene Probleme handeln.
Der Schlüssel zur effektiven Lösung konsistenter Authentifizierungsprobleme besteht darin, die verschiedenen Fehlertypen und die Bedeutung der einzelnen Fehlermeldungen zu verstehen. Einige Fehler können in mehr als einem Authentifizierungsproblem auftreten. Sie können die Informationen zur Problembehandlung verwenden, die im Abschnitt "Fehlertypen " erwähnt werden, um den Fehler zu beheben.
Voraussetzungen
Bevor Sie mit der Problembehandlung beginnen, führen Sie die Prüfliste mit den Voraussetzungen durch, um die folgenden Informationen bereit zu haben:
Installieren Sie die Tools WireShark und Problem Steps Recorder (PSR.exe). Weitere Informationen finden Sie unter Methoden zum Sammeln von Daten zur Problembehandlung verschiedener Arten von Fehlern.
Sammeln Sie die SPN-Informationen (Service Provider Name), die auf den Dienstkonten basieren. Verwenden Sie dazu den
SETSPN -L
Befehl.
Fehlertypen
In diesem Abschnitt werden Fehlertypen und zugehörige Informationen beschrieben.
Verzeichnisdienstefehler: Wenn die SQL Server-Fehlerprotokolldatei eine oder beide der folgenden Meldungen enthält, bezieht sich dieser Fehler auf Active Directory-Domäne Services (AD DS). Dieser Fehler kann auch auftreten, wenn Windows auf dem SQL Server-basierten Computer keinen Kontakt mit dem Domänencontroller (DC) herstellen kann oder wenn der Subsystemdienst für lokale Sicherheitsstellen (Local Security Authority Subsystem Service, LSASS) ein Problem verursacht.
Error -2146893039 (0x80090311): No authority could be contacted for authentication. Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.
Fehler bei der Anmeldung: Wenn Sie den Fehler "Anmeldung fehlgeschlagen" beheben, bietet das SQL Server-Fehlerprotokoll zusätzliche Einblicke in den Fehlercode 18456, einschließlich eines bestimmten Zustandswerts, der mehr Kontext zum Fehler bietet. Weitere Informationen finden Sie in der SQL Server-Fehlerprotokolldatei im SQL-Statuswert. Sie können versuchen, das Problem gemäß der Beschreibung des Statuswerts zu beheben.
In der folgenden Tabelle sind einige spezifische Fehlermeldungen "Anmeldung fehlgeschlagen" und ihre möglichen Ursachen und Lösungen aufgeführt.
Fehlermeldung Weitere Informationen "Beim Senden der Anforderung an den Server ist ein Fehler auf Transportebene aufgetreten." Überprüfen Sie, ob die Zuordnung des verknüpften Serverkontos korrekt ist. Weitere Informationen finden Sie unter sp_addlinkedsrvlogin. "SSPI-Kontext kann nicht generiert werden" - Das explizite SPN-Konto ist möglicherweise falsch, fehlt oder falsch eingefügt.
- Überprüfen Sie, ob sich der SPN auf dem falschen Konto befindet.
"Datenbanktest <> kann nicht geöffnet werden, der von der Anmeldung angefordert wurde. Fehler bei der Anmeldung." Die Datenbank ist möglicherweise offline, oder die Berechtigungen reichen möglicherweise nicht aus. Weitere Informationen finden Sie unter "Offlinedatenbank" in MSSQLSERVER_18456.
Überprüfen Sie außerdem, ob der Datenbankname in der Verbindungszeichenfolge korrekt ist."Die Anmeldung für den Benutzernamen> des Benutzers <ist fehlgeschlagen." Dieser Fehler kann auftreten, wenn das Proxykonto nicht ordnungsgemäß authentifiziert ist. "Anmeldung für Benutzer fehlgeschlagen: 'NT AUTHORITY\ANONYMOUS LOGON'" Dieser Fehler kann auftreten, wenn der SPN fehlt, SPN dupliziert wird oder der SPN auf dem falschen Konto vorhanden ist. "Die Anmeldung für den Benutzernamen> des Benutzers <ist fehlgeschlagen."
"Anmeldefehler für Benutzer '<database\username>"Überprüfen Sie, ob ein Verbindungszeichenfolge einen falschen Servernamen enthält. Überprüfen Sie außerdem, ob der Benutzer zu einer lokalen Gruppe gehört, die verwendet wird, um Zugriff auf den Server zu gewähren. Weitere Ursachen finden Sie unter NT AUTHORITY\ANONYMOUS LOGON. "Die Anmeldung für den Benutzer "<Benutzername>" ist fehlgeschlagen. Grund: Das Kennwort stimmte für die bereitgestellte Anmeldung nicht überein." Dieser Fehler kann auftreten, wenn ein falsches Kennwort verwendet wird. Weitere Informationen finden Sie unter "Login failed for user '<username>' or login failed for user '<domain><username>'. "SQL Server ist nicht vorhanden oder zugriff verweigert." Named Pipes-Verbindungen schlagen fehl, da der Benutzer nicht über die Berechtigung zum Anmelden bei Windows verfügt. "Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit Windows-Authentifizierung verwendet werden." Dieser Fehler kann mit den Problemen des lokalen Sicherheitssubsystems zusammenhängen. "Das Benutzerkonto ist für den Netzwerkanmeldungstyp nicht zulässig." Möglicherweise können Sie sich nicht beim Netzwerk anmelden.
Arten konsistenter Authentifizierungsprobleme
In diesem Abschnitt werden typische Ursachen für einheitliche Authentifizierungsprobleme zusammen mit ihren jeweiligen Lösungen beschrieben. Wählen Sie den Problemtyp aus, um die relevanten Probleme, Ursachen und Lösungen anzuzeigen.
Verbindungszeichenfolge
In diesem Abschnitt werden die Probleme aufgelistet, die sich auf Konfigurationseinstellungen beziehen, die von Anwendungen zum Herstellen einer Verbindung mit einer Datenbank verwendet werden.
Expliziter SPN fehlt – Dieses Problem tritt auf, wenn der SPN nicht ordnungsgemäß konfiguriert oder registriert ist.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "SSPI-Kontext kann nicht generiert werden"- Fehler bei Verwendung von Windows-Authentifizierung zum Verbinden von SQL Server.
Explizit falsch eingefügter SPN – bezieht sich auf einen SPN, der mit einem bestimmten Dienst oder Konto falsch verknüpft war.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter Explizites falsch eingefügtes SPN.
Expliziter SPN ist dupliziert – Dieses Problem tritt auf, wenn ein SPN dupliziert wird, da es mehr als einmal registriert ist.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "SSPI-Kontext kann nicht generiert werden"- Fehler bei Verwendung von Windows-Authentifizierung zum Verbinden von SQL Server.
Falscher Servername in Verbindungszeichenfolge – Dieses Problem tritt auf, wenn der angegebene Servername falsch ist oder nicht gefunden werden kann.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
Falsche Datenbankname in Verbindungszeichenfolge – Dieses Problem tritt auf, wenn der datenbankname, der für die Authentifizierung bereitgestellt wird, falsch ist.
Lösung: Überprüfen Sie, ob der Name richtig geschrieben ist. Weitere Informationen finden Sie unter MSSQLSERVER_4064.
Falsches explizites SPN-Konto – Dieses Problem kann auftreten, wenn der SPN mit dem falschen Konto in AD DS verknüpft ist.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "SSPI-Kontextfehler kann nicht generiert werden".
Datenbank
In diesem Abschnitt werden die Probleme aufgeführt, die für verschiedene Aspekte von SQL Server spezifisch sind:
Datenbank ist offline – Bezieht sich auf ein Szenario, in dem eine SQL Server-Datenbank versucht, die Verbindung mit einer SQL Server-Instanz wiederherzustellen, die für den Windows-Authentifizierungsmodus konfiguriert ist.
Lösung: Weitere Informationen finden Sie unter MSSQLSERVER_18456.
Datenbankberechtigungen – bezieht sich auf das Aktivieren oder Einschränken des Zugriffs auf eine SQL Server-Datenbank.
Lösung: Weitere Informationen finden Sie unter MSSQLSERVER_18456.
Verbindungsfehler bei verknüpften Servern in SQL Server – Es tritt ein Authentifizierungsprozessproblem auf, das sich auf verknüpfte Server im Kontext von SQL Server auswirkt.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter Verbindungsfehler für verknüpfte Server in SQL Server.
Metadaten des verknüpften Servers sind inkonsistent – bezieht sich auf ein Problem, bei dem Metadaten des verknüpften Servers inkonsistent sind oder nicht mit den erwarteten Metadaten übereinstimmen.
Eine Ansicht oder gespeicherte Prozedur fragt die Tabellen oder Ansichten auf dem verknüpften Server ab, empfängt jedoch Anmeldefehler, obwohl eine verteilte
SELECT
Anweisung, die aus der Prozedur kopiert wird, nicht erfolgt.Dieses Problem kann auftreten, wenn die Ansicht erstellt und dann der verknüpfte Server neu erstellt wurde oder eine Remotetabelle geändert wurde, ohne die Ansicht neu zu erstellen.
Lösung: Aktualisieren Sie die Metadaten des verknüpften Servers, indem Sie die
sp_refreshview
gespeicherte Prozedur ausführen.Das Proxykonto verfügt nicht über Berechtigungen – Ein SQL Server Integration Service (SSIS)-Auftrag, der vom SQL-Agent ausgeführt wird, erfordert möglicherweise andere Berechtigungen als die, die das SQL Agent-Dienstkonto bereitstellen kann.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter SSIS-Paket, das beim Aufruf aus einem SQL Server-Agent Auftragsschritt nicht ausgeführt wird.
Die Anmeldung bei der SQL Server-Datenbank ist nicht möglich . Die Unfähigkeit zur Anmeldung kann zu Fehlern bei der Authentifizierung führen.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
Verzeichnisdienste
In diesem Abschnitt werden die Probleme aufgelistet, die sich auf Verzeichnisdienste und Server beziehen.
Ein Konto ist deaktiviert – Dieses Szenario kann auftreten, wenn das Benutzerkonto von einem Administrator oder von einem Benutzer deaktiviert wurde. In diesem Fall können Sie sich nicht mit diesem Konto anmelden, oder Sie können dieses Konto nicht verwenden, um einen Dienst zu starten. Dies kann zu konsistenten Authentifizierungsproblemen führen, da dadurch verhindert werden kann, dass Sie auf Ressourcen zugreifen oder Aktionen ausführen, die eine Authentifizierung erfordern.
Lösung: Ein Domänenadministrator kann dies beheben, indem es das Konto erneut aktiviert. Wenn ein Konto deaktiviert ist, liegt es in der Regel daran, dass ein Benutzer versucht hat, sich mit dem falschen Kennwort zu oft anzumelden, oder weil eine Anwendung oder ein Dienst versucht, ein altes Kennwort zu verwenden.
Ein Konto befindet sich nicht in der Gruppe . Dieses Problem kann auftreten, wenn ein Benutzer versucht, auf eine Ressource zuzugreifen, die auf eine bestimmte Gruppe beschränkt ist.
Lösung: Überprüfen Sie die SQL-Anmeldungen, um zulässige Gruppen aufzählen zu können, und stellen Sie sicher, dass der Benutzer zu einer der Gruppen gehört.
Fehler bei der Kontomigration: Wenn alte Benutzerkonten keine Verbindung mit dem Server herstellen können, aber neu erstellte Konten können, ist die Kontomigration möglicherweise nicht korrekt. Dieses Problem bezieht sich auf AD DS.
Lösung: Weitere Informationen finden Sie unter Übertragen von Anmeldeinformationen und Kennwörtern zwischen Instanzen von SQL Server.
Domänencontroller ist offline – Bezieht sich auf ein Problem, bei dem auf den Domänencontroller nicht zugegriffen werden kann.
Lösung: Verwenden Sie den
nltest
Befehl, um zu erzwingen, dass der Computer zu einem anderen Domänencontroller wechselt. Weitere Informationen finden Sie unter Active Directory-Replikationsereignis-ID 2087: DNS-Nachschlagefehler verursachte Replikationsfehler.Die Firewall blockiert den Domänencontroller – Möglicherweise treten Probleme auf, wenn Sie den Zugriff des Benutzers auf Ressourcen verwalten.
Lösung: Stellen Sie sicher, dass auf den Domänencontroller über den Client oder den Server zugegriffen werden kann. Verwenden Sie dazu den
nltest /SC_QUERY:CONTOSO
Befehl.Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne – Dieses Problem bezieht sich auf die Vertrauensstufe zwischen Domänen. Möglicherweise wird die folgende Fehlermeldung angezeigt: "Anmeldung fehlgeschlagen. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit Windows-Authentifizierung verwendet werden. (18452)."
Fehler 18452 gibt an, dass die Anmeldung windows-Authentifizierung verwendet, aber die Anmeldung ist ein unbekannter Windows-Prinzipal. Ein unbekannter Windows-Prinzipal gibt an, dass die Anmeldung nicht von Windows überprüft werden kann. Dies kann vorkommen, weil die Windows-Anmeldung von einer nicht vertrauenswürdigen Domäne stammt. Die Vertrauensstufe zwischen Domänen kann zu Fehlern bei der Kontoauthentifizierung oder zur Sichtbarkeit von Dienstanbieternamen (Service Provider Name, SPN)s führen.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18452.
Keine Berechtigungen für domänenübergreifende Gruppen – Benutzer aus der Remotedomäne sollten zu einer Gruppe in der SQL Server-Domäne gehören. Es kann ein Problem geben, wenn Sie versuchen, eine lokale Domänengruppe zum Herstellen einer Verbindung mit einer SQL Server-Instanz aus einer anderen Domäne zu verwenden.
Lösung: Wenn die Domänen nicht ordnungsgemäß vertrauenswürdig sind, kann das Hinzufügen der Benutzer in einer Gruppe in der Remotedomäne verhindern, dass der Server die Mitgliedschaft der Gruppe aufzählt.
Die selektive Authentifizierung ist deaktiviert . Bezieht sich auf ein Feature von Domänenvertrauensstellungen, mit dem der Domänenadministrator einschränken kann, welche Benutzer Zugriff auf Ressourcen in der Remotedomäne haben. Wenn die selektive Authentifizierung nicht aktiviert ist, können alle Benutzer in der vertrauenswürdigen Domäne Zugriff auf die Remotedomäne erhalten.
Lösung: Um dieses Problem zu beheben, aktivieren Sie die selektive Authentifizierung, um sicherzustellen, dass die Benutzer nicht in der Remotedomäne authentifiziert werden dürfen.
Kerberos-Authentifizierung
In diesem Abschnitt werden die Probleme aufgeführt, die mit der Kerberos-Authentifizierung zusammenhängen:
Ein falsches DNS-Suffix wird an den NetBIOS-Namen angefügt . Dieses Problem kann auftreten, wenn Sie nur den NetBIOS-Namen (z. B. SQLPROD01) anstelle des vollqualifizierten Domänennamens (Z. B. SQLPROD01.CONTOSO.COM) verwenden. Wenn dies geschieht, wird möglicherweise das falsche DNS-Suffix angefügt.
Lösung: Überprüfen Sie die Netzwerkeinstellungen für die Standardsuffixe, um sicherzustellen, dass sie korrekt sind, oder verwenden Sie den FQDN, um Probleme zu vermeiden.
Die Uhrneigung ist zu hoch – Dieses Problem kann auftreten, wenn mehrere Geräte in einem Netzwerk nicht synchronisiert werden. Damit die Kerberos-Authentifizierung funktioniert, können die Takte zwischen Geräten für mehr als fünf Minuten oder konsistente Authentifizierungsfehler nicht deaktiviert werden.
Lösung: Richten Sie die Computer so ein, dass ihre Uhren regelmäßig mit einem zentralen Zeitdienst synchronisiert werden.
Delegieren vertraulicher Konten an andere Dienste – Einige Konten werden möglicherweise als
Sensitive
AD DS markiert. Diese Konten können in einem Double-Hop-Szenario nicht an einen anderen Dienst delegiert werden. Vertrauliche Konten sind für die Bereitstellung von Sicherheit wichtig, können sich jedoch auf die Authentifizierung auswirken.Lösung: Informationen zum Beheben dieses Problems finden Sie unter "Login failed for user NT AUTHORITY\ANONYMOUS LOGON".
Delegieren an eine Dateifreigabe – bezieht sich auf eine Situation, in der ein Benutzer oder eine Anwendung seine Anmeldeinformationen delegiert, um auf eine Dateifreigabe zuzugreifen. Ohne geeignete Einschränkungen kann das Delegieren von Anmeldeinformationen an eine Dateifreigabe Sicherheitsrisiken darstellen.
Lösung: Um diese Art von Problem zu beheben, stellen Sie sicher, dass Sie die eingeschränkte Delegierung verwenden.
Nicht zusammenhängender DNS-Namespace – bezieht sich auf ein konsistentes Authentifizierungsproblem, das auftreten kann, wenn das DNS-Suffix nicht zwischen dem Domänenmitglied und dem DNS übereinstimmt. Möglicherweise treten Authentifizierungsprobleme auf, wenn Sie einen nicht zusammenhängenden Namespace verwenden. Wenn die Organisationshierarchie in AD DS und in DNS nicht übereinstimmen, wird möglicherweise der falsche SPN generiert, wenn Sie den NETBIOS-Namen in der Datenbankanwendung Verbindungszeichenfolge verwenden. In diesem Fall wird der SPN nicht gefunden, und die Anmeldeinformationen für den Neuen Technologie LAN Manager (NTLM) werden anstelle von Kerberos-Anmeldeinformationen verwendet.
Lösung: Verwenden Sie zum Beheben des Problems den FQDN des Servers, oder geben Sie den SPN-Namen im Verbindungszeichenfolge an. Informationen zum FQDN finden Sie unter Computerbenennung.
Duplikat SPN – Bezieht sich auf eine Situation, in der zwei oder mehr SPNs innerhalb einer Domäne identisch sind. SPNs werden verwendet, um Dienste eindeutig zu identifizieren, die auf Servern in einer Windows-Domäne ausgeführt werden. Doppelte SPNs können Authentifizierungsprobleme verursachen.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter Beheben des Fehlers mit Kerberos Configuration Manager (empfohlen).
Aktivieren von HTTP-Ports für SPNs – In der Regel verwenden HTTP-SPNs keine Portnummern (z. B
http/web01.contoso.com
. ).Lösung: Um dieses Problem zu beheben, können Sie dies mithilfe der Richtlinie auf den Clients aktivieren. Der SPN müsste dann im
http/web01.contoso.com:88
Format vorliegen, damit Kerberos ordnungsgemäß funktioniert. Andernfalls werden NTLM-Anmeldeinformationen verwendet.NTLM-Anmeldeinformationen werden nicht empfohlen, da sie es möglicherweise schwierig machen, das Problem zu diagnostizieren. Außerdem kann dies zu einem übermäßigen Verwaltungsaufwand führen.
Abgelaufene Tickets – Bezieht sich auf Kerberos-Tickets. Die Verwendung abgelaufener Kerberos-Tickets kann zu Authentifizierungsproblemen führen.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "Abgelaufene Tickets".
DIE HOSTS-Datei ist falsch - Die HOSTS-Datei kann DNS-Nachschlagevorgänge stören und möglicherweise einen unerwarteten SPN-Namen generieren. Diese Situation bewirkt, dass NTLM-Anmeldeinformationen verwendet werden. Wenn sich eine unerwartete IP-Adresse in der HOSTS-Datei befindet, stimmt der generierte SPN möglicherweise nicht mit dem Back-End-Server überein, auf den verwiesen wird.
Lösung: Überprüfen Sie die HOSTS-Datei, und entfernen Sie die Einträge für Ihren Server. HOSTS-Dateieinträge werden im SQLCHECK-Bericht angezeigt.
Problem mit Berechtigungen pro Dienstsicherheits-ID (SID) – Die SID pro Dienst ist ein Sicherheitsfeature von SQL Server, das lokale Verbindungen auf die Verwendung von NTLM und nicht kerberos als Authentifizierungsmethode beschränkt. Der Dienst kann einen einzelnen Hop zu einem anderen Server mithilfe von NTLM-Anmeldeinformationen machen, kann aber nicht weiter delegiert werden, ohne die eingeschränkte Delegierung zu verwenden. Weitere Informationen finden Sie unter "Login failed for user NT AUTHORITY\ANONYMOUS LOGON".
Lösung: Um dieses Problem zu beheben, muss der Domänenadministrator die eingeschränkte Delegierung einrichten.
Kernelmodusauthentifizierung – Der SPN für das App-Poolkonto ist in der Regel für Webserver erforderlich. Wenn jedoch die Kernelmodusauthentifizierung verwendet wird, wird der HOST-SPN des Computers für die Authentifizierung verwendet. Diese Aktion findet im Kernel statt. Diese Einstellung kann verwendet werden, wenn der Server viele verschiedene Websites hostt, die dieselbe Hostheader-URL, verschiedene App-Pool-Konten und die Windows-Authentifizierung verwenden.
Lösung: Entfernen Sie die HTTP-SPNs, wenn die Kernelmodusauthentifizierung aktiviert ist.
Beschränken Sie die Delegierungsrechte auf Access oder Excel – Die Anbieter joint Engine Technology (JET) und Access Connectivity Engine (ACCESS Connectivity Engine, ACE) ähneln einem der Dateisysteme. Sie müssen die eingeschränkte Delegierung verwenden, damit SQL Server Dateien lesen kann, die sich auf einem anderen Computer befinden. Im Allgemeinen sollte der ACE-Anbieter nicht in einem verknüpften Server verwendet werden, da dies explizit nicht unterstützt wird. Der JET-Anbieter ist veraltet und nur auf 32-Bit-Computern verfügbar.
Notiz
Wenn SQL Server 2014, die letzte Version zur Unterstützung von 32-Bit-Installationen, nicht mehr unterstützt wird, wird das JET-Szenario nicht mehr unterstützt.
Fehlender SPN – Dieses Problem kann auftreten, wenn ein SPN im Zusammenhang mit einer SQL Server-Instanz nicht vorhanden ist.
Lösung: Weitere Informationen finden Sie unter Beheben des Fehlers mit Kerberos Configuration Manager (empfohlen).
Kein eingeschränktes Ziel – Wenn die eingeschränkte Delegierung für ein bestimmtes Dienstkonto aktiviert ist, schlägt Kerberos fehl, wenn der SPN des Zielservers nicht in der Liste der Ziele der eingeschränkten Delegierung enthalten ist.
Lösung: Um dieses Problem zu beheben, muss ein Domänenadministrator den SPN des Zielservers zu den Ziel-SPNs des Mid-Tier-Dienstkontos hinzufügen.
NTLM und eingeschränkte Delegierung – Wenn es sich bei dem Ziel um eine Dateifreigabe handelt, muss der Delegierungstyp des Dienstkontos der mittleren Ebene eingeschränkt sein – "Any " und nicht "Eingeschränkt-Kerberos". Wenn der Delegierungstyp auf "Eingeschränkt-Kerberos" festgelegt ist, kann das Mid-Tier-Konto nur bestimmten Diensten zugeordnet werden, aber "Eingeschränkt-Any " ermöglicht es dem Dienstkonto, an einen beliebigen Dienst zu delegieren.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "Login failed for user NT AUTHORITY\ANONYMOUS LOGON".
Das Dienstkonto kann nicht für die Delegierung in AD vertrauenswürdig sein – In einem Doppelt hop-Szenario muss das Dienstkonto des Diensts auf mittlerer Ebene für die Delegierung in AD DS vertrauenswürdig sein. Wenn das Dienstkonto für die Delegierung nicht vertrauenswürdig ist, kann die Kerberos-Authentifizierung fehlschlagen.
Lösung: Wenn Sie ein Administrator sind, aktivieren Sie die Option "Vertrauenswürdig für Delegierung ".
Einige Legacyanbieter unterstützen Kerberos über Named Pipes nicht – Der ältere OLE DB-Anbieter (SQLOLEDB) und DER ODBC-Anbieter (SQL Server), der mit Windows gebündelt ist, bieten keine Unterstützung für die Kerberos-Authentifizierung über Named Pipes. Stattdessen unterstützen sie nur die NTLM-Authentifizierung.
Lösung: Verwenden Sie eine TCP-Verbindung, um die Kerberos-Authentifizierung zuzulassen. Sie können auch einen neueren Treiber verwenden, z. B. MSOLEDBSQL oder ODBC Driver 17. Tcp wird jedoch unabhängig von der Version des Treibers immer noch gegenüber Named Pipes bevorzugt.
SPN ist einem falschen Konto zugeordnet – Dieses Problem kann auftreten, wenn ein SPN mit dem falschen Konto in AD DS verknüpft ist. Weitere Informationen finden Sie unter Beheben des Fehlers mit Kerberos Configuration Manager (empfohlen).
Möglicherweise wird eine Fehlermeldung angezeigt, wenn Ihr SPN für das falsche Konto in AD DS konfiguriert ist.
Lösung: Führen Sie die folgenden Schritte aus, um den Fehler zu beheben:
- Wird
SETSPN -Q spnName
verwendet, um den SPN und sein aktuelles Konto zu finden. - Dient
SETSPN -D
zum Löschen der vorhandenen SPNs. - Verwenden Sie die
SETSPN -S
SPN zum richtigen Konto, um den SPN zu migrieren.
- Wird
DER SQL-Alias funktioniert möglicherweise nicht ordnungsgemäß . Ein SQL Server-Alias kann dazu führen, dass ein unerwarteter SPN generiert wird. Dies führt dazu, dass NTLM-Anmeldeinformationen fehlschlagen, wenn der SPN nicht gefunden wird, oder ein SSPI-Fehler, wenn er versehentlich mit dem SPN eines anderen Servers übereinstimmt.
Lösung: SQL-Aliase werden im SQLCHECK-Bericht angezeigt. Um das Problem zu beheben, identifizieren und korrigieren Sie alle falschen oder falsch konfigurierten SQL-Aliase, damit sie auf den richtigen SQL Server verweisen.
Der Benutzer gehört zu vielen Gruppen – Wenn ein Benutzer zu mehreren Gruppen gehört, können Authentifizierungsprobleme in Kerberos auftreten. Wenn Sie Kerberos über UDP verwenden, muss das gesamte Sicherheitstoken in ein einzelnes Paket passen. Benutzer, die zu vielen Gruppen gehören, verfügen über ein größeres Sicherheitstoken als Benutzer, die weniger Gruppen angehören.
Lösung: Wenn Sie Kerberos über TCP verwenden, können Sie die Einstellung [
MaxTokenSize
] erhöhen. Weitere Informationen finden Sie unter MaxTokenSize und Kerberos Token Bloat.Websitehostheader verwenden – Der HTTP-Hostheader spielt eine sehr wichtige Rolle im HTTP-Protokoll für den Zugriff auf Webseiten.
Lösung: Wenn die Website über einen Hostheadernamen verfügt, kann der HOSTS-SPN nicht verwendet werden. Ein expliziter HTTP-SPN muss verwendet werden. Wenn die Website keinen Hostheadernamen hat, wird NTLM verwendet. NTLM kann nicht an eine Back-End-SQL Server-Instanz oder einen anderen Dienst delegiert werden.
NT LAN-Manager (NTLM)
In diesem Abschnitt werden Probleme aufgeführt, die für NTLM (NT LAN-Manager) spezifisch sind:
Der Zugriff wird für NTLM-Peeranmeldungen verweigert – bezieht sich auf ein Problem, das mit NTLM-Peeranmeldungen verknüpft ist.
Lösung: Bei der Kommunikation zwischen Computern, die sich in Arbeitsstationen oder Domänen befinden, die einander nicht vertrauen, können Sie identische Konten auf beiden Computern einrichten und die NTLM-Peerauthentifizierung verwenden.
Anmeldungen funktionieren nur, wenn sowohl das Benutzerkonto als auch das Kennwort auf beiden Computern übereinstimmen. Die NTLM-Authentifizierung kann auf Client- oder Serverseite deaktiviert oder nicht unterstützt werden. Diese Situation kann zu Authentifizierungsfehlern führen. Weitere Informationen finden Sie unter MSSQLSERVER_18456.
Szenarien mit doppeltem Hop auf mehreren Computern – Ein Double-Hop-Prozess schlägt fehl, wenn NTLM-Anmeldeinformationen verwendet werden. Kerberos-Anmeldeinformationen sind erforderlich.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter "Login failed for user NT AUTHORITY\ANONYMOUS LOGON".
Loopbackschutz ist nicht richtig festgelegt – Loopbackschutz ist so konzipiert, dass Anwendungen daran gehindert werden, andere Dienste auf demselben Computer aufzurufen. Wenn der Loopbackschutz nicht ordnungsgemäß konfiguriert ist oder eine Fehlfunktion auftritt, kann dies indirekt zu Authentifizierungsproblemen führen.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
Der Loopbackschutz schlägt fehl, wenn Sie eine Verbindung mit dem Always-On-Listener herstellen . Dieses Problem bezieht sich auf den Loopbackschutz. Wenn Sie über den primären Knoten eine Verbindung mit dem Always-On-Listener herstellen, verwendet die Verbindung die NTLM-Authentifizierung.
Lösung: Weitere Informationen finden Sie unter MSSQLSERVER_18456.
Problem, das LANMAN-Kompatibilitätsstufe betrifft – Das LAN Manager (LANMAN)-Authentifizierungsproblem tritt in der Regel auf, wenn in den Authentifizierungsprotokollen, die von älteren (vor Windows Server 2008) und neueren Computern verwendet werden, ein Konflikt auftritt. Wenn Sie die Kompatibilitätsebene auf 5 festlegen, ist NTLMv2 nicht zulässig.
Lösung: Das Wechseln zu Kerberos vermeidet dieses Problem, da Kerberos sicherer ist. Weitere Informationen finden Sie unter "Login failed for user NT AUTHORITY\ANONYMOUS LOGON".
SQL-Anmeldung
In diesem Abschnitt werden Probleme aufgeführt, die sich auf Authentifizierungsanmeldeinformationen beziehen:
Ungültiges Kennwort – Bezieht sich auf ein anmeldebezogenes Problem.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
Ungültiger Benutzername – Bezieht sich auf ein Anmeldeproblem.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
SQL Server-Anmeldungen sind nicht aktiviert – Bezieht sich auf ein Szenario, in dem Sie versuchen, eine Verbindung mit einer Microsoft SQL Server-Instanz mithilfe der SQL Server-Authentifizierung herzustellen, aber die anmeldung, die dem Konto zugeordnet ist, ist deaktiviert.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter MSSQLSERVER_18456.
Named Pipes-Verbindungen schlagen fehl, da der Benutzer nicht über die Berechtigung zum Anmelden bei Windows verfügt – bezieht sich auf ein Berechtigungsproblem in Windows.
Lösung: Informationen zum Beheben dieses Problems finden Sie unter Named Pipes Connections Problem in SQL Server.
Windows-Berechtigungen
In diesem Abschnitt werden Probleme aufgeführt, die für Windows-Berechtigungen oder Richtlinieneinstellungen spezifisch sind:
Der Zugriff wird über lokale Gruppen gewährt– Wenn der Benutzer nicht zu einer lokalen Gruppe gehört, die zum Gewähren des Zugriffs auf den Server verwendet wird, zeigt der Anbieter die Fehlermeldung "Anmeldung fehlgeschlagen für Benutzer 'contoso/user1'" an.
Lösung: Der Datenbankadministrator kann diese Situation überprüfen, indem er den Ordner "Sicherheitsanmeldungen>" in SQL Server Management Studio (SSMS) untersucht. Wenn es sich bei der Datenbank um eine enthaltene Datenbank handelt, überprüfen Sie unter
databasename
. Weitere Informationen finden Sie unter "Login failed for user 'username' or login failed for user 'domain\username'.For more information, see Login failed for user '<username>' or login failed for user '<domain>\<username>'.Credential Guard ist aktiviert – Dieses Szenario gibt an, dass das Credential Guard-Feature auf einem Windows-System aktiviert ist und zum Erstellen einer sicheren Umgebung zum Speichern vertraulicher Informationen verwendet wird. In bestimmten Situationen kann dieses Feature jedoch Authentifizierungsprobleme verursachen.
Lösung: Bitten Sie einen Domänenadministrator, die eingeschränkte Delegierung einzurichten, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Überlegungen und bekannte Probleme bei der Verwendung von Credential Guard.
Fehler im lokalen Sicherheitssubsystem – Wenn lokale Sicherheitssubsystemfehler auftreten, insbesondere solche, die mit LSASS verbunden sind, die nicht mehr reagiert werden, kann es auf zugrunde liegende Probleme hinweisen, die sich auf die Authentifizierung auswirken.
Lösung: Informationen zum Beheben dieser Fehler finden Sie unter Lokalen Sicherheitssubsystemfehlern in SQL Server.
Netzwerkanmeldung nicht zulässig – Dieses Szenario tritt auf, wenn Sie versuchen, sich bei einem Netzwerk anzumelden, ihre Anmeldeanforderung wird jedoch aus bestimmten Gründen verweigert.
Lösung: Um dieses Problem zu beheben, lesen Sie, dass der Benutzer nicht über die Berechtigungen zum Anmelden beim Netzwerk verfügt.
Nur Administratoren können sich anmelden – Dieses Problem tritt auf, wenn das Sicherheitsprotokoll auf einem Computer voll ist und nicht über ausreichend Speicherplatz zum Ausfüllen von Ereignissen verfügt. Das Sicherheitsfeature CrashOnAuditFail wird von Systemadministratoren verwendet, um alle Sicherheitsereignisse zu überprüfen. Die gültigen Werte für
CrashOnAuditFail
0, 1 und 2. Wenn der Schlüssel aufCrashOnAuditFail
2 festgelegt ist, bedeutet dies, dass das Sicherheitsprotokoll voll ist und die Fehlermeldung "Nur Administratoren können sich anmelden" angezeigt wird.Lösung: Gehen Sie folgendermaßen vor, um das Problem zu beheben:
- Starten Sie den Registrierungs-Editor.
- Suchen Und überprüfen Sie den
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail
Unterschlüssel, um festzustellen, ob der Wert auf 2 festgelegt ist. Dieser Wert gibt an, dass für das Sicherheitsprotokoll manuelles Löschen erforderlich ist. - Legen Sie den Wert auf 0 fest, und starten Sie dann den Server neu. Möglicherweise möchten Sie auch das Sicherheitsprotokoll ändern, um ereignisse für das Rollover zu aktivieren. Weitere Informationen dazu, wie sich die Einstellung auf alle Dienste wie SQL, IIS, Dateifreigabe und Anmeldung auswirkt, finden Sie unter Benutzer können nicht auf Websites zugreifen, wenn das Sicherheitsereignisprotokoll voll ist.
Notiz
Dieses Problem betrifft nur integrierte Anmeldungen. Eine Named Pipes-Verbindung wird auch in einer SQL Server-Anmeldung betroffen sein, da Named Pipes sich zuerst bei Windows Admin Pipe anmeldet, bevor eine Verbindung mit SQL Server hergestellt wird.
Das Dienstkonto ist für die Delegierung nicht vertrauenswürdig . Diese Art von Problem tritt in der Regel auf, wenn ein Dienstkonto anderen Servern keine Anmeldeinformationen zuweisen darf. Dieses Problem kann sich auf Dienste auswirken, die eine Delegierung erfordern.
Lösung: Wenn ein Delegierungsszenario nicht aktiviert ist, überprüfen Sie den SQL Server secpol.msc , um zu ermitteln, ob das SQL Server-Dienstkonto unter der Lokalen Richtlinien-Benutzerrechtezuweisung > > nach den Authentifizierungssicherheitsrichtlinieneinstellungen aufgeführt ist. Weitere Informationen finden Sie unter Aktivieren der Vertrauenswürdigung von Computer- und Benutzerkonten für die Delegierung.
Windows-Benutzerprofil kann nicht in SQL Server geladen werden – Bezieht sich auf das Windows-Benutzerprofilproblem.
Lösung: Weitere Informationen zur Problembehandlung bei beschädigten Benutzerprofilen finden Sie unter Windows-Benutzerprofil kann in SQL Server nicht geladen werden.
Weitere Aspekte
In diesem Abschnitt werden Probleme aufgeführt, die mit der Authentifizierung und Der Zugriffssteuerung in einer Webumgebung zusammenhängen:
Integrierte Authentifizierung ist nicht aktiviert – Bezieht sich auf ein Konfigurationsproblem, bei dem die integrierte Windows-Authentifizierung (Integrated Windows Authentication, IWA) nicht ordnungsgemäß konfiguriert ist.
Lösung: Um dieses Problem zu beheben, stellen Sie sicher, dass die Option "Integrierte Windows-Authentifizierung" in den Internetoptioneneinstellungen aktiviert ist.
IIS-Authentifizierung ist nicht zulässig – Dieses Problem tritt aufgrund von Fehlkonfigurationen in IIS auf. Die Authentifizierungseinstellungen, die in der Web.config-Datei der Webanwendung definiert sind, können in Konflikt mit den Einstellungen stehen, die in IIS konfiguriert sind. Diese Situation kann zu Authentifizierungsproblemen führen.
Lösung: Um dieses Problem zu beheben, konfigurieren Sie die Website so, dass die Windows-Authentifizierung aktiviert wird, und legen Sie den
<identity impersonate="true"/>
Wert in der Datei "Web.config " fest.Falsche Internetzone – Dieses Problem kann auftreten, wenn Sie versuchen, auf eine Website zuzugreifen, die sich nicht in der richtigen Internetzone in Internet Explorer befindet. Die Anmeldeinformationen funktionieren nicht, wenn sich die Website in der lokalen Intranetzone befindet.
Lösung: Fügen Sie den Webserver zur lokalen Intranetzone von IE hinzu.
Informationen zum Haftungsausschluss von Drittanbietern
Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.
Weitere Informationen
Sammeln von Daten zur Problembehandlung von SQL Server-Konnektivitätsproblemen