Fehler „SSPI-Kontext kann nicht generiert werden“ bei Verwendung der Windows-Authentifizierung zum Verbinden mit SQL Server
Gilt für: SQL Server
Ursprüngliche KB-Nummer: 811889
Hinweis
Bevor Sie mit der Problembehandlung beginnen, sollten Sie die Voraussetzungen überprüfen und die Checkliste durchgehen.
Wenn Sie die Windows-Authentifizierung verwenden, um eine SQL Server-Instanz remote zu verbinden, wird die folgende Fehlermeldung angezeigt:
„Der Zielprinzipalname ist falsch.“ „Der SSPI-Kontext kann nicht generiert werden“
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 Names, SPN) ist ein eindeutiger Bezeichner einer Dienstinstanz. SPNs werden von der Kerberos-Authentifizierung verwendet, 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 eine lokale Verbindung auf demselben Computer herstellt, auf dem sich SQL Server befindet, wird immer NTLM verwendet.
Warum wird die Verbindung nicht auf NTLM umgestellt, wenn es Probleme mit Kerberos gibt?
Der SQL Server-Treibercode auf dem Client verwendet die WinSock-Netzwerk-API, um das vollqualifizierte DNS des Servers aufzulösen, wenn der Treiber die Windows-Authentifizierung verwendet, um eine Verbindung mit SQL Server herzustellen. Für diesen Vorgang ruft der Treibercode die WinSock-APIs gethostbyname und gethostbyaddr auf. Wenn die integrierte Sicherheit verwendet wird, versucht der Treiber, das vollqualifizierte DNS des Servers aufzulösen, auch wenn als Name des Servers eine IP-Adresse oder ein Hostname übergeben wird.
Wenn der SQL Server-Treiber auf dem Client den vollqualifizierten DNS-Namen des Servers auflöst, wird der entsprechende DNS-Name dazu verwendet, den SPN für diesen Computer zu bilden. Daher können Probleme, die bei der Auflösung der IP-Adresse oder des Hostnamens durch WinSock zu einem vollqualifizierten DNS-Namen entstehen, zur Folge haben, dass der SQL Server-Treiber einen ungültigen SPN für den Server erstellt.
Beispielsweise kann der clientseitige SQL Server-Treiber als vollqualifiziertes DNS verwendet werden, 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. An diesem Punkt wechselt die SSPI-Ebene in einen NTLM-Authentifizierungsmodus, und für die Anmeldung wird die NTLM-Authentifizierung verwendet, welche in der Regel erfolgreich ist. 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 der 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 Ermitteln, ob ich mit SQL Server mithilfe der Kerberos-Authentifizierung verbunden bin.
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 müssen Sie Ihre*n Active Directory-Admin bitten, den richtigen SPN manuell zu registrieren, indem Sie den Microsoft Kerberos Manager für SQL Server oder das integrierte Tool Setspn verwenden. Weitere Informationen zum Verwalten von SPNs für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.
Beheben des Fehlers mit dem Kerberos-Konfigurations-Manager (empfohlen)
Hinweis
Dieses Verfahren gilt nur für Situationen, in denen Sie diese Fehlermeldungen ständig und nicht nur zeitweise erhalten.
Es gibt verschiedene Gründe, warum Kerberos-Verbindungen fehlschlagen, z. B. falsch konfigurierte SPNs, Probleme bei der Namensauflösung oder unzureichende Rechte für SQL Server-Dienststartkonten. Der Microsoft Kerberos-Konfigurations-Manager (KCM) ist ein Tool, mit dem die Fehlerursachen überprüft werden können. Der KCM bietet auch Optionen, um alle identifizierten Probleme im Prozess zu beheben.
Gehen Sie folgendermaßen vor, um den Fehler mit KCM zu beheben.
Laden Sie auf dem Computer, auf dem die Verbindungsprobleme auftreten, den Kerberos-Konfigurations-Manager herunter und installieren Sie ihn.
Starten Sie KerberosConfigMgr.exe aus dem Ordner %SystemDrive%:\Programme\Microsoft\Kerberos Configuration Manager. 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 auszufü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. Deaktivieren Sie alles außer SQL Server, um diesen Fehler zu beheben.
Überprüfen Sie die Diagnose des Tools mithilfe der Spalte Status, und führen Sie die entsprechenden 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 Dieser Status wird gemeldet, wenn der in der Spalte Erforderlicher SPN identifizierte SPN für das SQL Server-Startkonto im 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-Admin hilft, die fehlenden SPNs hinzuzufügen.
5. Nachdem die SPNs hinzugefügt wurden, führen Sie den Kerberos-Konfigurations-Manager erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.
6. Darüber hinaus können Sie die folgenden Befehle verwenden:
– Verwenden SieSETSPN -Q spnName, um den SPN und die zugehörigen aktuellen Konten zu suchen.
– Verwenden SieSETSPN -D, 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 die Protokolle für <Instanzname< aus.
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 Bereich Details mit der rechten Maustaste auf „SQL Server“ (<Instanzname>), und wählen Sie dann Neu starten 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). In Umgebungen, in denen Sie Kerberos zum Herstellen einer Verbindung mit SQL Server verwenden müssen, sollten Sie ihre benannte Instanz auf einen statischen Port festlegen und diesen Port beim Registrieren von SPN verwenden. Gehen Sie folgendermaßen vor, um Ihre SQL Server-Instanz für die Verwendung eines statischen Ports zu konfigurieren:
1. Erweitern Sie im SQL Server-Konfigurations-Manager im Konsolenbereich den Abschnitt SQL Server Netzwerkkonfiguration, erweitern Sie die Protokolle für <Instanzname>, und doppelklicken Sie dann auf TCP/IP.
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.SPN duplizieren Es kann vorkommen, dass 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.Hinweis
Wenn das Domänenkonto, das den KCM startet, nicht berechtigt ist, SPNs in Active Directory zu bearbeiten, können Sie die entsprechende Schaltfläche Generieren oder Alle generieren unter der Spalte SPN-Skript verwenden, um die erforderlichen Befehle zu generieren und mit Ihrem*r Active Directory-Admin zusammenzuarbeiten, um die vom KCM identifizierten Probleme zu beheben.
Nachdem Sie alle im KCM identifizierten Probleme behoben haben, führen Sie das Tool erneut aus. Stellen Sie sicher, dass keine weiteren Probleme gemeldet werden, und versuchen Sie dann erneut 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:
Schritt 1: Überprüfen der Namensauflösung mit dem Ping-Befehl
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 zu erhalten, auf dem SQL Server ausgeführt wird (dabei lautet der Name des Computers 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>
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 powerShell-Version zu testen, die auf dem Computer installiert ist. Weitere Informationen zum PowerShell-Cmdlet finden Sie in der Cmdlet-Übersicht.
Hinweis
Methoden für die Namensauflösung können DNS, WINS, HOSTS-Dateien und LMHOSTS-Dateien sein. Weitere Informationen zu Problemen bei der Namensauflösung und zur Problembehandlung finden Sie unter den folgenden Links:
Überprüfen Sie im SQL Server-Konfigurations-Manager und im SQL Server-Clientnetzwerkdienstprogramm, ob Aliase für das Ziel SQL Server 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. Dies führt zu NTLM-Anmeldeinformationen, wenn der SPN nicht gefunden wird, oder zu einem SSPI-Fehler, wenn er versehentlich mit dem SPN eines anderen Servers übereinstimmt.
Schritt 2: Ü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. Auch muss in der Domäne eine korrekte Namensauflösung stattfinden.
Stellen Sie sicher, dass Sie sich bei Windows anmelden können, indem Sie dasselbe Domänenkonto und Kennwort wie das SQL Server-Dienststartkonto verwenden. Der SSPI-Fehler kann beispielsweise in den folgenden Situationen auftreten:
- Das Domänenkonto ist gesperrt.
- Sie haben den SQL Server-Dienst nach dem Ändern des Kennworts des Kontos jedoch 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.
Schritt 3: Überprüfen SQL Server SPNs mithilfe der Tools SQLCHECK und Setspn
Wenn Sie sich lokal am SQL Server Computer anmelden können 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 zu den gesammelten Informationen finden Sie auf der Startseite des Tools. Sie können auch die Seite mit den empfohlenen Voraussetzungen und Prüflisten konsultieren. 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.
Beispiel für die Ausgabe:
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 die obige Ausgabe, um die nächsten Schritte zu ermitteln (siehe Beispiele unten), und verwenden Sie das Setspn-Tool, um die erforderlichen Abhilfemaßnahmen zur Behebung von SPN-Problemen zu ergreifen.
| Szenario | Vorgeschlagene Aktion |
|---|---|
| SPN ist nicht vorhanden | Fügen Sie den/die erforderlichen SPN(s) 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. |
Hinweis
Im Abschnitt SQL Server Informationen der Ausgabedatei des SQLCHECK-Tools finden Sie das Dienstkonto Ihrer SQL Server instance.
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 gemäß Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen konfiguriert sind. Weitere Informationen finden Sie unter Setspn-Tool und Beispiele zu dessen Verwendung.
Weitere Informationen dazu, in welchen Szenarien SQL Server SPNs automatisch registriert und wann eine manuelle SPN-Registrierung erforderlich ist, finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.
Schritt 4: Überprüfen der Kontoberechtigung für das SQL Server-Startkonto auf einem verknüpften Server
Wenn Sie Identität wechseln als Authentifizierungsoption auf der Seite Sicherheit Ihres verknüpften Servers verwenden, ist es erforderlich, dass SQL Server eingehende Anmeldeinformationen an die Remoteinstanz von SQL Server übergibt. Dem SQL Server-Startkonto, in dem der verknüpfte Server definiert ist, sollte das Recht Konto wird für Delegierungszwecke vertraut in Active Directory zugewiesen sein. Weitere Informationen finden Sie unter Aktivieren der Vertrauenswürdigung von Computer- und Benutzerkonten für die Delegierung.
Hinweis
Dieser Schritt ist nur erforderlich, wenn Sie Probleme im Zusammenhang mit Abfragen von verknüpften Servern behandeln.
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für