Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: SQL Server
Ursprüngliche KB-Nummer: 811889
Zusammenfassung
Dieser Artikel hilft Ihnen bei der Problembehandlung und Behebung des Fehlers "SSPI-Kontext kann nicht generiert werden", der auftritt, wenn Sie versuchen, eine Verbindung mit SQL Server mithilfe der Windows-Authentifizierung herzustellen. Dieser Fehler weist in der Regel darauf hin, dass die SSPI (Security Support Provider Interface) die Kerberos-Authentifizierung nicht verwenden kann, um Clientanmeldeinformationen über TCP/IP oder Named Pipes an SQL Server zu delegieren.
In diesem Artikel erfahren Sie mehr über häufige Ursachen von SSPI-Kontextfehlern, Dienstprinzipalnamen (Service Principal Names, SPNs) und deren Rolle bei der Authentifizierung sowie über die Diagnose und Behebung des Fehlers.
Bevor Sie mit der Problembehandlung beginnen, überprüfen Sie die Voraussetzungen und prüfliste für die Problembehandlung bei SQL Server-Konnektivitätsproblemen.
Symptome
Wenn Sie die Windows-Authentifizierung verwenden, um eine Remoteverbindung mit einer SQL Server-Instanz herzustellen, wird die folgende Fehlermeldung angezeigt:
Der Zielprinzipalname ist falsch. Der SSPI-Kontext kann nicht erstellt werden.
Ursache
Dieser Fehler tritt in der Regel auf, wenn die Windows-Authentifizierung nicht das Kerberos-Protokoll zum Delegieren von Clientanmeldeinformationen verwendet und nicht erfolgreich auf die NTLM-Authentifizierung zurückgreift. In den meisten Fällen wird dieser Fehler durch einen falsch konfigurierten Dienstprinzipalnamen (Service Principal Name, SPN) verursacht.
Weitere Informationen zu SSPI, Kerberos und SPNs finden Sie unter Häufig gestellte Fragen.
Beheben des Fehlers mit Kerberos Configuration Manager
Notiz
Dieser Ansatz behebt den Fehler, wenn Sie diese Fehlermeldungen konsistent erhalten, nicht zeitweise.
Kerberos-Verbindungen schlagen aus verschiedenen Gründen fehl, z. B. falsch konfigurierte SPNs, Namensauflösungsprobleme oder unzureichende Rechte für SQL Server-Dienststartkonten. Microsoft Kerberos Configuration Manager (KCM) ist ein Tool, mit dem Sie die Ursachen des Fehlers überprüfen und Optionen zum Beheben identifizierter Probleme bieten.
Führen Sie die folgenden Schritte aus, um den Fehler mithilfe von KCM zu beheben.
Laden Sie auf dem Computer, auf dem die Verbindungsprobleme auftreten, Kerberos Configuration Manager herunter, und installieren Sie sie.
Starten Sie
KerberosConfigMgr.exeaus dem%SystemDrive%:\Program Files\Microsoft\Kerberos Configuration ManagerOrdner. Verwenden Sie dann ein Domänenkonto, das über Berechtigungen zum Herstellen einer Verbindung mit dem SQL Server-Computer verfügt, mit dem Sie keine Verbindung herstellen können.Wählen Sie Verbinden aus, und lassen Sie den Servernamen und andere Details für Ihr Szenario leer, wenn Sie KCM auf dem SQL Server-Computer ausführen. Wählen Sie Verbinden aus, um die Analyse durchzuführen. Nachdem KCM die erforderlichen Informationen abgerufen hat, wechselt es automatisch zur Registerkarte SPN und zeigt standardmäßig Informationen für SQL Server, SQL Server Reporting Services, Analysis Services und AG Listener an. Um diesen Fehler zu beheben, löschen Sie alle Optionen außer SQL Server.
Überprüfen Sie die Diagnose des Tools mithilfe der Spalte "Status ", und führen Sie die relevanten Schritte aus, um das Problem zu beheben:
Status Weitere Informationen Aktion Gut Das überprüfte Element ist ordnungsgemäß konfiguriert. Sie können mit dem nächsten Element in der Ausgabe fortfahren. Keine Aktion erforderlich. Erforderlicher SPN fehlt KCM meldet diesen Status, wenn der in der Spalte "Erforderlicher SPN " identifizierte SPN für das SQL Server-Startkonto in Active Directory fehlt. 1. Wählen Sie Beheben aus, um die Informationen im Dialogfeld Warnung zu überprüfen.
2. Wählen Sie Ja aus, um den fehlenden SPN zu Active Directory hinzuzufügen.
3. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der erforderliche SPN zu Active Directory hinzugefügt.
4. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie Generieren oder Alle generieren, um das Skript zu generieren, das dem Active Directory-Administrator hilft, die fehlenden SPNs hinzuzufügen.
5. Führen Sie nach dem Hinzufügen der SPNs den Kerberos Configuration Manager erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.
6. Darüber hinaus können Sie die folgenden Befehle verwenden:
– WirdSETSPN -Q spnNameverwendet, um den SPN und seine aktuellen Konten zu finden.
– WirdSETSPN -Dverwendet, um den SPN aus dem falschen Konto zu entfernen.TCP muss für die Verwendung der Kerberos-Konfiguration aktiviert sein Dies tritt auf, wenn TCP auf dem Clientcomputer nicht aktiviert ist. Führen Sie die folgenden Schritte aus, um das TCP/IP-Protokoll für die SQL Server-Instanz zu aktivieren:
1. Erweitern Sie im SQL Server-Konfigurations-Manager im Konsolenbereich den Teil SQL Server-Netzwerkkonfiguration.
2. Wählen Sie im Konsolenbereich "Protokolle" den Namen "Protokolle<
3. Klicken Sie im Detailbereich mit der rechten Maustaste auf TCP/IP, und klicken Sie anschließend auf Aktivieren.
4. Klicken Sie im Konsolenbereich auf SQL Server-Dienste.
5. Klicken Sie im Detailbereich mit der rechten Maustaste auf SQL Server (Instanzname<), und wählen Sie >" aus, um den SQL Server-Dienst zu beenden und neu zu starten.
Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren eines Servernetzwerkprotokolls.Dynamischer Port Diese Meldung wird für benannte Instanzen angezeigt, die dynamische Ports verwenden (Standardkonfiguration). Legen Sie in Umgebungen, in denen Sie Kerberos zum Herstellen einer Verbindung mit SQL Server verwenden müssen, die benannte Instanz auf einen statischen Port fest und verwenden Sie diesen Port beim Registrieren von SPN. Gehen Sie folgendermaßen vor, um Ihre SQL Server-Instanz für die Verwendung eines statischen Ports zu konfigurieren:
1. Erweitern Sie in SQL Server-Konfigurations-Manager im Konsolenbereich DIE SQL Server-Netzwerkkonfiguration, erweitern Sie z. B. den Namen< der Protokolle, und doppelklicken Sie dann auf >.
2. Überprüfen Sie im Dialogfeld TCP/IP-Eigenschaften die Einstellung Allen lauschen auf der Registerkarte Protokoll.
3. Wenn die Einstellung Allen lauschen auf Ja gesetzt ist, wechseln Sie zur Registerkarte IP-Adressen und blättern Sie zum unteren Rand des Fensters, um die Einstellung IPAll zu finden. Löschen Sie den aktuellen Wert, der in den dynamischen TCP-Ports enthalten ist, und legen Sie den gewünschten Wert im Feld TCP-Port fest. Klicken Sie auf OK, und starten Sie die SQL Server-Instanz neu, damit die Einstellungen wirksam werden.
4. Wenn die Einstellung Allen lauschen auf Nein gesetzt ist, wechseln Sie zur Registerkarte IP-Adressen, und überprüfen Sie jede der IP-Adressen, die in den Feldern IP1, IP2 erscheinen. Entfernen Sie für aktivierte IP-Adressen den aktuellen Wert aus dem Feld Dynamische TCP-Ports und setzen Sie den gewünschten Wert in das Feld TCP-Port. Klicken Sie auf OK, und starten Sie die SQL Server-Instanz neu, damit die Einstellungen wirksam werden.
Weitere Informationen finden Sie unter Konfigurieren eines Servers zum Überwachen eines bestimmten TCP-Ports.Doppelter SPN Diese Situation tritt auf, wenn derselbe SPN unter verschiedenen Konten in Active Directory registriert ist. 1. Wählen Sie die Schaltfläche Beheben, sehen Sie sich die Informationen im Dialogfeld Warnung an, und klicken Sie auf Ja, wenn Sie den fehlenden SPN zu Active Directory hinzufügen können.
2. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der falsche SPN gelöscht.
3. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie die Schaltfläche Generieren oder Alle generieren, um das erforderliche Skript zu generieren, das Sie an Ihre*n Active Directory-Admin übergeben können, um die doppelten SPNs zu entfernen. Nachdem die SPNs entfernt wurden, führen Sie den KCM erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.Notiz
Wenn das Domänenkonto, das KCM startet, keine Berechtigungen zum Bearbeiten von SPNs in Active Directory hat, verwenden Sie die entsprechende Schaltfläche Generieren oder Alle generieren in der SPN-Skript-Spalte, um die erforderlichen Befehle zu generieren. Arbeiten Sie mit Ihrem Active Directory-Administrator zusammen, um die von KCM identifizierten Probleme zu beheben.
Führen Sie nach dem Beheben aller Probleme, die KCM identifiziert, das Tool erneut aus. Stellen Sie sicher, dass keine anderen Probleme gemeldet werden, und wiederholen Sie dann die Verbindung. Wenn das Tool weiterhin Probleme meldet, wiederholen Sie das vorherige Verfahren.
Beheben des Fehlers ohne den Kerberos-Konfigurations-Manager
Wenn Sie den KCM nicht verwenden können, führen Sie die folgenden Schritte aus:
Überprüfen der Namensauflösung mithilfe des Ping-Befehls
Der Schlüsselfaktor für eine erfolgreiche Kerberos-Authentifizierung ist die DNS-Funktionalität im Netzwerk. Sie können diese Funktionalität auf dem Client und auf dem Server mit dem Befehlszeilenprogramm Ping prüfen. Führen Sie auf dem Clientcomputer den folgenden Befehl aus, um die IP-Adresse des Servers abzurufen, auf dem SQL Server ausgeführt wird (wobei der Name des Computers lautet SQLServer1):
ping sqlserver1
Führen Sie den folgenden Befehl aus, um herauszufinden, ob das Hilfsprogramm „Ping“ den vollqualifizierten DNS-Namen von SQLServer1 auflöst:
ping -a <IPAddress>
Zum Beispiel:
C:\>ping SQLSERVER1
Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping -a 123.123.123.123
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>
Wenn der Befehl ping -a <IPAddress> zum korrekten voll qualifizierten DNS-Namen des Computers, auf dem SQL Server ausgeführt wird, aufgelöst wird, ist die clientseitige Auflösung ebenfalls erfolgreich.
Verwenden Sie für detaillierte Diagnosen entweder das Cmdlet "Test-NetConnection " oder "Test-Connection", um die TCP-Konnektivität gemäß der auf dem Computer installierten PowerShell-Version zu testen. Weitere Informationen zu PowerShell-Cmdlets finden Sie unter Cmdlet Overview.
Notiz
Namensauflösungsmethoden können DNS-, WINS-, Hosts- und Lmhosts-Dateien enthalten. Weitere Informationen zu Problemen bei der Namensauflösung und zur Problembehandlung finden Sie in den folgenden Artikeln:
Überprüfen Sie, ob aliase für das Ziel SQL Server im SQL Server Configuration Manager und im SQL Server Client Network-Hilfsprogramm vorhanden sind. Wenn ein solcher Alias vorhanden ist, stellen Sie sicher, dass er ordnungsgemäß konfiguriert ist, indem Sie Servernamen, Netzwerkprotokoll, Portnummer usw. überprüfen. Ein SQL Server-Alias kann dazu führen, dass ein unerwarteter SPN generiert wird. Dieses Problem führt zu NTLM-Anmeldeinformationen, wenn der SPN nicht gefunden wird oder ein SSPI-Fehler auftritt, wenn er versehentlich mit dem SPN eines anderen Servers übereinstimmt.
Überprüfen der Kommunikation zwischen Domänen
Vergewissern Sie sich, dass die Domäne, bei der Sie sich anmelden, mit der Domäne des Servers kommunizieren kann, auf dem SQL Server ausgeführt wird. Die Domäne muss auch die richtige Namensauflösung haben.
Stellen Sie sicher, dass Sie sich bei Windows anmelden können, indem Sie dasselbe Domänenkonto und Kennwort wie das SQL Server-Dienststartkonto verwenden. Beispielsweise kann der SSPI-Fehler in einer der folgenden Situationen auftreten:
- Das Domänenkonto ist gesperrt.
- Sie haben den SQL Server-Dienst nach der Kennwortänderung nicht neu gestartet.
Wenn sich Ihre Anmeldedomäne von der Domäne des Servers unterscheidet, auf dem SQL Server ausgeführt wird, überprüfen Sie die Vertrauensstellung zwischen den Domänen.
Überprüfen Sie, ob die Domäne, zu der der Server gehört, und das Domänenkonto, mit dem Sie die Verbindung herstellen, in derselben Gesamtstruktur liegen. Dieser Schritt ist eine Voraussetzung dafür, dass SSPI funktioniert.
Überprüfen von SQL Server SPNs mithilfe von SQLCHECK- und Setspn-Tools
Wenn Sie sich lokal beim SQL Server-Computer anmelden und Administratorzugriff haben, verwenden Sie SQLCHECK. SQLCheck enthält die meisten Informationen, die für die Problembehandlung erforderlich sind, in einer einzigen Datei. Weitere Informationen zur Verwendung des Tools und der gesammelten Informationen finden Sie auf der Startseite des Tools. Sie können auch die empfohlene Seite mit den Voraussetzungen und der Checkliste überprüfen. Nachdem Sie die Ausgabedatei generiert haben, überprüfen Sie die SPN-Konfiguration für Ihre SQL Server-Instanz im Abschnitt SQL Server-Informationen der Ausgabedatei.
Beispielausgabe:
Suggested SPN Exists Status
---------------------------------------------------------- ------ -------------------
MSSQLSvc/testsqlsvr.corp.com:2000 True Okay
MSSQLSvc/testsqlsvr.corp.com True Okay
MSSQLSvc/testsqlsvr:2000 False SPN does not exist.
MSSQLSvc/testsqlsvr False SPN does not exist.
Verwenden Sie diese Ausgabe, um die nächsten Schritte zu ermitteln (siehe die folgenden Beispiele), und verwenden Sie das Setspn-Tool , um erforderliche Abhilfemaßnahmen zum Beheben von SPN-Problemen zu ergreifen.
| Szenario | Vorgeschlagene Maßnahme |
|---|---|
| SPN ist nicht vorhanden | Fügen Sie die erforderlichen SPNs für Ihr SQL Server-Dienstkonto hinzu. |
| Doppelte SPNs | Löschen Sie den SPN, der für Ihren SQL-Dienst unter dem falschen Konto registriert ist. |
| SPN unter falschem Konto | Löschen Sie den registrierten SPN für Ihren SQL-Dienst unter dem falschen Konto, und registrieren Sie dann den SPN unter dem richtigen Dienstkonto. |
| Falscher SPN ist registriert. | Löschen Sie den falschen SPN, und registrieren Sie den richtigen SPN. |
Notiz
Sie können den Abschnitt "SQL Server Information " der Ausgabedatei des SQLCHECK-Tools überprüfen, um das Dienstkonto Ihrer SQL Server-Instanz zu finden.
Setspn ist ein integriertes Tool in neueren Versionen von Windows, mit dem Sie SPNs in Active Directory lesen, hinzufügen, ändern oder löschen können. Mit diesem Tool können Sie überprüfen, ob SQL Server-SPNs entsprechend dem Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen konfiguriert sind. Weitere Informationen finden Sie unter Setspn-Tool und Beispiele für die Verwendung.
Weitere Informationen zu Szenarien, in denen SQL Server SPNs automatisch registriert und die manuelle SPN-Registrierung erforderlich ist, finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.
Überprüfen der Kontoberechtigung für das SQL Server-Startkonto auf dem verknüpften Server
Wenn Sie Identitätswechsel als Authentifizierungsoption auf der Seite Sicherheit Ihres verknüpften Servers verwenden, muss SQL Server eingehende Anmeldeinformationen an den Remote-SQL-Server übergeben. Das SQL Server-Startkonto, mit dem Sie den verknüpften Server definieren, muss über das Recht Konto ist für Delegierung vertrauenswürdig in Active Directory verfügen. Weitere Informationen finden Sie unter Aktivieren der Vertrauenswürdigung von Computer- und Benutzerkonten für die Delegierung.
Notiz
Sie benötigen diesen Schritt nur, wenn Sie Probleme im Zusammenhang mit verknüpften Serverabfragen beheben.
Häufig gestellte Fragen
Was ist SSPI?
Bei der Security Support Provider-Schnittstelle (Security Support Provider Interface, SSPI) handelt es sich um eine Gruppe von Windows-APIs, die die Delegierung und gegenseitige Authentifizierung über generische Datentransportschichten wie beispielsweise TCP/IP-Sockets ermöglicht. Mindestens ein Softwaremodul stellt die tatsächlichen Authentifizierungsfunktionen bereit. Jedes Modul wird als Security Support Provider (SSP) bezeichnet und als Dynamic Link Library (DLL) implementiert.
Was ist Kerberos?
Das Kerberos v5-Protokoll ist ein Sicherheitspaket nach Branchenstandard und eines der drei Sicherheitspakete in Windows-Betriebssystemen. Weitere Informationen finden Sie unter Sicherheitsunterstützungsanbieter (SSPs)
Was bedeutet die Fehlermeldung „Der SSPI Kontext kann nicht erstellt werden“?
Dieser Fehler bedeutet, dass SSPI versucht, aber nicht in der Lage ist, die Kerberos-Authentifizierung zu verwenden, um Client-Anmeldeinformationen über TCP/IP oder Named Pipes an SQL Server zu delegieren. In den meisten Fällen wird dieser Fehler durch einen falsch konfigurierten Dienstprinzipalnamen (Service Principal Name, SPN) verursacht.
Was ist SPN?
Ein Dienstprinzipalname (Service Principal Name, SPN) ist ein eindeutiger Bezeichner für eine Dienstinstanz. Die Kerberos-Authentifizierung verwendet SPNs, um eine Dienstinstanz einem Dienstanmeldungskonto zuzuordnen. Dieser Zuordnungsprozess ermöglicht es einer Clientanwendung, den Dienst anzufordern, um ein Konto zu authentifizieren, auch wenn der Client keinen Kontonamen hat.
Ein typischer SPN für einen Server, auf dem eine Instanz von SQL Server ausgeführt wird, lautet beispielsweise wie folgt:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Das Format eines SPN für eine Standardinstanz ist dasselbe wie das eines SPN für eine benannte Instanz. Die Portnummer bindet den SPN an eine bestimmte Instanz. Weitere Informationen zum Registrieren von Dienst-SPNs für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.
Warum verwendet SSPI die NTLM- oder Kerberos-Authentifizierung?
Die Windows-Authentifizierung ist die bevorzugte Methode für Benutzende, sich bei SQL Server zu authentifizieren. Clients, die die Windows-Authentifizierung verwenden, werden mit NTLM oder Kerberos authentifiziert.
Wenn ein SQL Server-Client die integrierte Sicherheit über TCP/IP-Sockets zu einem Remote-Server verwendet, auf dem SQL Server ausgeführt wird, verwendet die Netzwerkbibliothek des SQL Server-Clients die SSPI-API, um die Sicherheitsdelegierung durchzuführen. Der SQL Server-Netzwerkclient ruft die Funktion AcquireCredentialsHandle auf und übergibt „negotiate“ für den Parameter pszPackage. Dieser Prozess benachrichtigt den zugrunde liegenden Sicherheitsanbieter, um die Delegierung auszuhandeln. In diesem Zusammenhang bedeutet „negotiate“ (aushandeln), dass die Kerberos- oder NTLM-Authentifizierung auf Windows-basierten Computern versucht wird. Anders ausgedrückt: Windows verwendet die Kerberos-Delegierung, wenn der Zielcomputer, auf dem SQL Server läuft, einen zugehörigen, richtig konfigurierten SPN hat. Andernfalls verwendet Windows die NTLM-Delegierung. Wenn der SQL Server-Client lokal eine Verbindung auf demselben Computer herstellt, auf dem SICH SQL Server befindet, verwendet er immer NTLM.
Warum wechselt die Verbindung nicht zu NTLM, nachdem Probleme mit Kerberos aufgetreten sind?
Wenn der Treiber die Windows-Authentifizierung zum Herstellen einer Verbindung mit SQL Server verwendet, verwendet der SQL Server-Treibercode auf dem Client die WinSock-Netzwerk-API, um das vollqualifizierte DNS des Servers aufzulösen. Für diesen Vorgang ruft der Treibercode die WinSock-APIs gethostbyname und gethostbyaddr auf. Wenn Sie integrierte Sicherheit verwenden, versucht der Treiber, das vollqualifizierte DNS des Servers aufzulösen, auch wenn Sie eine IP-Adresse oder einen Hostnamen als Namen des Servers übergeben.
Wenn der SQL Server-Treiber auf dem Client das vollqualifizierte DNS des Servers auflöst, verwendet er dieses, um den SPN des Servers zu erstellen. Wenn WinSock die IP-Adresse oder den Hostnamen nicht in ein vollqualifiziertes DNS auflösen kann, erstellt der SQL Server-Treiber möglicherweise einen ungültigen SPN für den Server.
Beispielsweise kann der clientseitige SQL Server-Treiber ein vollqualifiziertes DNS verwenden, um ungültige SPNs wie folgt aufzulösen:
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Wenn der SQL Server-Treiber einen ungültigen SPN erstellt, funktioniert die Authentifizierung trotzdem, da die SSPI-Schnittstelle versucht, den SPN im Active Directory-Dienst nachzuschlagen. Wenn die SSPI-Schnittstelle den SPN nicht findet, wird keine Kerberos-Authentifizierung durchgeführt. Zu diesem Zeitpunkt wechselt die SSPI-Ebene in den NTLM-Authentifizierungsmodus, und die Anmeldung verwendet die NTLM-Authentifizierung und ist in der Regel erfolgreich. Wenn der SQL Server-Treiber einen gültigen SPN bildet, der dem entsprechenden Container nicht zugewiesen ist, versucht der Treiber den SPN, kann ihn aber nicht verwenden. In diesem Fall kann ein Fehler "SSPI-Kontext kann nicht generiert werden" auftreten. Wenn es sich beim SQL Server-Startkonto um ein lokales Systemkonto handelt, ist der Computername der richtige Container. Für jedes andere Konto ist das SQL Server-Startkonto der richtige Container. Die Authentifizierung verwendet den ersten gefundenen SPN. Stellen Sie daher sicher, dass keine SPNs falschen Containern zugewiesen sind. Anders ausgedrückt: Jeder SPN darf nur einem einzigen Container zugeordnet sein.
Wie kann ich die Authentifizierungsmethode der Verbindung überprüfen?
Führen Sie die folgende Abfrage aus, um die Authentifizierungsmethode einer Verbindung zu ermitteln:
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Weitere Informationen finden Sie unter How to determine if the authentication type is Kerberos.
Wie erstelle ich SPNs für SQL Server?
Wenn eine Instanz des SQL Server-Datenbankmoduls gestartet wird, versucht SQL Server, den SPN für den SQL Server-Dienst automatisch mithilfe der DsWriteAccountSpn-API zu registrieren. Dieser Aufruf ist erfolgreich, wenn das SQL Server-Dienstkonto über Lese- servicePrincipalName und Schreibrechte servicePrincipalName in Active Directory verfügt. Andernfalls muss Ihr Active Directory-Administrator den richtigen SPN manuell mithilfe von Microsoft Kerberos Manager für SQL Server oder dem integrierten Setspn-Tool registrieren. Weitere Informationen zum Verwalten von SPNs für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.