Der Name des Zielprinzips ist falsch. SSPI-Kontext kann nicht generiert werden

Ich habe Probleme, eine SQL Server-Verbindung von Computer A zu Computer B herzustellen, auf dem der SQL Server ausgeführt wird.

Ich habe ausgiebig gegoogelt und all die Dinge, die ich gefunden habe, haben nicht funktioniert. Sie führen Sie auch nicht Schritt für Schritt durch den Lösungsprozess.

Wir verwenden kein Kerberos, aber NTLM wurde konfiguriert.

Die beteiligten Maschinen sind (xx wird verwendet, um einen Teil des Maschinennamens aus Sicherheitsgründen zu verschleiern):

• xxPRODSVR001 - Windows Server 2012-Domänencontroller
• xxDEVSVR003 - Windows Server 2012 (Dieser Computer generiert den Fehler)
• xxDEVSVR002 - Windows Server 2012 (Auf diesem Computer wird SQL Server 2012 ausgeführt.)

Die folgenden SPNs sind auf dem DC registriert (xxPRODSVR001). Ich habe die Domain aus Sicherheitsgründen mit yyy verdeckt:

Registrierte ServicePrincipalNames für CN = xxDEVSVR002, CN = Computer, DC = JJJ, DC = lokal:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

Registrierte ServicePrincipalNames für CN = xxDEVSVR003, CN = Computer, DC = JJJ, DC = lokal:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Wenn nur die SQL Server-Fehlermeldung aussagekräftiger wäre und mir sagen würde, mit welchem ​​Hauptnamen eine Verbindung hergestellt werden soll, kann ich dies möglicherweise diagnostizieren.

Kann mich jemand durch die Lösung dieses Problems führen oder können Sie etwas in dem, was ich bereitgestellt habe, sehen, das falsch ist?

Gerne generiere ich weitere Debug-Informationen. Sagen Sie mir einfach, was Sie brauchen.

Ich hatte dieses Problem mit einer ASP.NET MVC-App, an der ich arbeitete.

Mir wurde klar, dass ich kürzlich mein Passwort geändert hatte, und ich konnte es beheben, indem ich mich ab- und wieder anmeldete.

Ich habe diesen Fehler beim Herstellen einer Verbindung über SQL Server Management Studio mithilfe der Windows-Authentifizierung erhalten. Mein Passwort war abgelaufen, aber ich hatte es noch nicht geändert. Nach dem Ändern musste ich mich abmelden und wieder anmelden, damit der Computer mit meinen neuen Anmeldeinformationen funktionierte.

Versuchen Sie Integrated Security=true, diesen Parameter aus der Verbindungszeichenfolge zu entfernen.

WICHTIG: Als Benutzer @Auspex kommentierte,

Durch das Entfernen der integrierten Sicherheit wird dieser Fehler verhindert, da der Fehler auftritt, wenn Sie versuchen, sich mit Ihren Windows-Anmeldeinformationen anzumelden. Leider möchten Sie sich die meiste Zeit mit Ihren Windows-Anmeldeinformationen anmelden können

Beim Versuch der Windows-Authentifizierung wurde der gleiche Fehler angezeigt. Klingt lächerlich, aber nur für den Fall, dass es jemand anderem hilft: Es lag daran, dass mein Domain-Konto irgendwie gesperrt wurde, während ich noch angemeldet war (!). Durch das Entsperren des Kontos wurde das Problem behoben.

Ich habe mich mit einer PIN anstelle eines Kennworts bei Windows 10 angemeldet. Ich habe mich stattdessen mit meinem Kennwort abgemeldet und wieder angemeldet und konnte über Management Studio auf SQL Server zugreifen.

Der SSPI-Kontextfehler zeigt definitiv an, dass eine Authentifizierung mit Kerberos versucht wird .

Da die Kerberos-Authentifizierung die Windows-Authentifizierung von SQL Server auf Active Directory basiert, für das eine Push-Beziehung zwischen Ihrem Computer und Ihrem Netzwerkdomänencontroller erforderlich ist, sollten Sie zunächst diese Beziehung überprüfen.

Sie können diese Beziehung mithilfe des folgenden Powershell-Befehls Test-ComputerSecureChannel schnell überprüfen .

Test-ComputerSecureChannel -verbose

Wenn False zurückgegeben wird , müssen Sie den sicheren Active Directory-Kanal Ihres Computers reparieren, da ohne diesen Fehler keine Überprüfung der Domänenanmeldeinformationen außerhalb Ihres Computers möglich ist.

Sie können Ihren Computer Secure Channel mit dem folgenden Powershell- Befehl reparieren :

Test-ComputerSecureChannel -Repair

Überprüfen Sie die Sicherheitsereignisprotokolle. Wenn Sie Kerberos verwenden, sollten Anmeldeversuche mit dem Authentifizierungspaket Kerberos angezeigt werden.

Die NTLM-Authentifizierung schlägt möglicherweise fehl, und daher wird ein Kerberos-Authentifizierungsversuch durchgeführt. Möglicherweise wird in Ihrem Sicherheitsereignisprotokoll auch ein NTLM-Anmeldeversuch fehlgeschlagen.

Sie können die Kerberos-Ereignisprotokollierung in dev aktivieren, um zu debuggen, warum das Kerberos fehlschlägt, obwohl es sehr ausführlich ist.

Mit dem Kerberos Configuration Manager für SQL Server von Microsoft können Sie dieses Problem möglicherweise schnell diagnostizieren und beheben.

Hier ist eine gute Geschichte zu lesen: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Nur um eine weitere mögliche Lösung für diesen mehrdeutigen Fehler hinzuzufügen The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Stellen Sie sicher, dass die IP-Adresse, die beim Pingen des SQL Servers aufgelöst wird, mit der im Configuration Manager übereinstimmt. Öffnen Sie zur Überprüfung SQL Server Configuration Manager und gehen Sie dann zu SQL Server-Netzwerkkonfiguration> Protokolle für MSSQLServer> TCP / IP.

Stellen Sie sicher, dass TCP / IP aktiviert ist, und stellen Sie auf der Registerkarte IP-Adressen sicher, dass die IP, in die der Server beim Ping aufgelöst wird, dieselbe ist. Das hat diesen Fehler für mich behoben.

Das Problem scheint ein Problem mit Windows-Anmeldeinformationen zu sein. Ich habe den gleichen Fehler auf meinem Arbeitslaptop mit einem VPN erhalten. Ich bin angeblich als meine Domain / mein Benutzername angemeldet, was ich erfolgreich verwende, wenn ich eine direkte Verbindung herstelle, aber sobald ich zu einem VPN mit einer anderen Verbindung wechsle, erhalte ich diesen Fehler. Ich dachte, es sei ein DNS-Problem, da ich den Server anpingen könnte, aber es stellte sich heraus, dass ich SMSS explizit als mein Benutzer an der Eingabeaufforderung ausführen musste.

zB runas / netonly / user: YourDoman \ YourUsername "C: \ Programme (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

Melden Sie sich sowohl bei Ihrer SQL Box als auch bei Ihrem Client an und geben Sie Folgendes ein:

ipconfig /flushdns
nbtstat -R

Wenn das nicht funktioniert, erneuern Sie Ihr DHCP auf Ihrem Client-Computer ... Dies funktioniert für 2 PCs in unserem Büro.

Ich bin gerade darauf gestoßen und habe es durch zwei Dinge behoben:

1. Erteilen von Lese- / Schreibberechtigungen für servicePrincipalName für das Dienstkonto mithilfe von ADSI Edit, wie unter https://support.microsoft.com/en-us/kb/811889 beschrieben

2. Entfernen der SPNs, die zuvor auf dem SQL Server- Computerkonto (im Gegensatz zum Dienstkonto) vorhanden waren, mithilfe von

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
   

   Dabei war 1234 die von der Instanz verwendete Portnummer (meine war keine Standardinstanz).

In meinem Fall wurde das Problem durch einen Neustart von SQL Server 2014 (auf meinem Entwicklungsserver) behoben.

Ich habe IPv6 auf einem PC-Cluster in einem isolierten Netzwerk getestet und bin auf dieses Problem gestoßen, als ich IPv4 zurückgesetzt habe. Ich habe im Active Directory, DNS und DHCP gespielt, habe also keine Ahnung, was ich veranlasst habe, das Kerberos-Setup zu brechen.

Ich habe die Verbindung außerhalb meiner Software mit diesem nützlichen Tipp erneut getestet, um die gefundene Remoteverbindung herzustellen.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

Nach einer kurzen Suche wurde dies auf der Microsoft-Website https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message gefunden .

Führen Sie das Tool auf dem SQL Server aus, um festzustellen, ob ein Problem vorliegt, wenn der Status "Fehler" lautet, und klicken Sie dann auf die angezeigte Schaltfläche "Beheben".

Dies löste das Problem für mich.

Dies ist normalerweise auf fehlende, falsche oder doppelte Service Principle Names (SPNs) zurückzuführen.

Zu lösende Schritte:

1. Bestätigen Sie, welches AD-Konto SQL Server verwendet
2. Führen Sie den folgenden Befehl in Powershell oder CMD im Administratormodus aus (das Dienstkonto sollte die Domäne nicht enthalten).

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Stellen Sie sicher, dass die zurückgegebene Ausgabe einen SPN enthält, der vollständig qualifiziert ist, nicht vollständig qualifiziert, mit einem Port und ohne Port.

   Erwartete Ausgabe:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Wenn Sie nicht alle oben genannten Informationen sehen, führen Sie den folgenden Befehl in PowerShell oder CMD im Administratormodus aus (stellen Sie sicher, dass Sie den Port ändern, wenn Sie nicht die Standardeinstellung 1433 verwenden).

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Sobald dies abgeschlossen ist, dauert die DNS-Weitergabe normalerweise einige Minuten

Wenn Sie eine Meldung über gefundene doppelte SPNs erhalten, möchten Sie diese möglicherweise löschen und neu erstellen

Ich hatte dieses Problem beim Zugriff auf die Webanwendung. Es könnte daran liegen, dass ich kürzlich ein Windows-Passwort geändert habe.

Dieses Problem wurde behoben, als ich das Kennwort für den App-Pool aktualisiert habe, in dem ich die Webanwendung gehostet habe.

Überprüfen Sie, ob Ihre Uhr zwischen Client und Server übereinstimmt.

Wenn ich diesen Fehler zeitweise hatte, funktionierte keine der oben genannten Antworten. Dann stellten wir fest, dass die Zeit auf einigen unserer Server abgelaufen war. Sobald sie erneut synchronisiert wurden, verschwand der Fehler. Suchen Sie nach w32tm oder NTP, um zu sehen, wie die Uhrzeit unter Windows automatisch synchronisiert wird.

Da ich hier gelandet bin, um nach einer Lösung für mein eigenes Problem zu suchen, werde ich meine Lösung hier teilen, falls auch andere hier landen.

Ich stellte eine gute Verbindung zu SQL Server her, bis mein Computer in ein anderes Büro in einer anderen Domäne verschoben wurde . Dann, nach dem Wechsel, bekam ich diesen Fehler bezüglich des Zielprinzipalnamens. Was behoben wurde, war die Verbindung unter Verwendung eines vollständig qualifizierten Namens wie: server.domain.com . Sobald ich mich auf diese Weise mit dem ersten Server verbunden habe, kann ich nur mit dem Servernamen (ohne die vollständige Qualifikation) eine Verbindung zu anderen Servern herstellen, aber Ihr Kilometerstand kann variieren.

Ich bin heute darauf gestoßen und wollte mein Update teilen, da dieses einfach übersehen wird und leicht zu beheben ist.

Wir verwalten unser eigenes rDNS und haben kürzlich unser Servernamensschema überarbeitet. Als Teil davon hätten wir unser rDNS aktualisieren und vergessen sollen, dies zu tun.

Ein Ping ergab den richtigen Hostnamen, ein Ping -a gab jedoch den falschen Hostnamen zurück.

Einfache Lösung: Ändern Sie den rDNS, führen Sie eine ipconfig / flushdns durch, warten Sie 30 Sekunden (nur etwas, was ich tue), führen Sie einen weiteren Ping -a durch, sehen Sie, wie der richtige Hostname aufgelöst wird, verbinden Sie ... profit.

Ich bin auf eine neue gestoßen: SQL 2012, die auf Server 2012 gehostet wird. Wurde beauftragt, einen Cluster für SQL AlwaysOn zu erstellen.
Cluster wurde erstellt, jeder erhielt die SSPI-Nachricht.

Um die Probleme zu beheben, wurde folgender Befehl ausgeführt:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== das Domänenkonto, das ich für SQL festgelegt habe Ich brauchte einen Domänenadministrator, um den Befehl auszuführen. Nur ein Server im Cluster hatte Probleme.

Dann SQL neu gestartet. Zu meiner Überraschung konnte ich mich verbinden.

Ich habe versucht, von meinem Laptop in einer Visual Studio 2015-Konsolen-App aus eine Verbindung zu einer VM herzustellen, auf der SQL Server 2015 ausgeführt wird. Ich starte meine App am Abend zuvor und es ist in Ordnung. Am Morgen versuche ich, die App zu debuggen und erhalte diesen Fehler. Ich habe versucht ipconfig/flushund release+ renewund eine Menge anderen Müll, aber am Ende ...

Starten Sie Ihre VM neu und starten Sie den Client neu. Das hat es für mich behoben. Ich hätte es wissen müssen, jedes Mal neu starten.

Ich hatte dieses Problem auf meinem SQL Server. Ich habe setspn -D mssqlsvc \ Hostname.domainname Hostname dann gestoppt und meinen SQL Server-Dienst gestartet.

Ich denke, dass das Stoppen und Starten meines SQL-Dienstes dies getan hätte.

Ich hatte das gleiche Problem, aber das Sperren und Entsperren der Maschine funktionierte für mich. Manchmal führen Firewall-Probleme zu Fehlern.

Ich bin mir nicht sicher, ob es für Sie funktionieren wird oder nicht, ich teile nur meine Erfahrungen.

Ich habe alle Lösungen hier ausprobiert und keine davon hat bisher funktioniert. Eine Problemumgehung besteht darin, auf Verbinden zu klicken , den Servernamen einzugeben und Optionen, Registerkarte Verbindungseigenschaften auszuwählen. Stellen Sie das "Netzwerkprotokoll" auf "Named Pipes". Auf diese Weise können Benutzer mithilfe ihrer Netzwerkanmeldeinformationen eine Remoteverbindung herstellen. Ich werde ein Update veröffentlichen, wenn ich einen Fix bekomme.

In meinem Fall bestand das Problem darin, DNS über das WLAN einzurichten. Ich entfernte die Einstellungen, ließ sie leer und arbeitete.

Stellen Sie sicher, dass "Named Pipes" in "SQL Server Configuration Manager" aktiviert sind. Das hat bei mir funktioniert.

1. Öffnen Sie "SQL Server Configuration Manager".
2. Erweitern Sie "SQL Server-Netzwerkkonfiguration" in der Liste links.
3. Wählen Sie "Protokolle für [Ihren Instanznamen]".
4. Klicken Sie in der Liste rechts mit der rechten Maustaste auf "Named Pipes".
5. Wählen Sie "Aktivieren"
6. Starten Sie Ihren Instanzdienst neu.

Dieses Microsoft Tool ist wie Magic. Führen Sie es aus, verbinden Sie es mit dem SQL Server und klicken Sie auf Fix

Die hier verlinkte alte Version funktionierte auf SQL Server 2017.

Kerberos Configuration Manager für SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

In meiner Situation habe ich versucht, mithilfe der integrierten Sicherheit eine Verbindung von einem PC zu SQL Server auf einem anderen PC in einem Netzwerk ohne Domäne herzustellen. Auf beiden PCs habe ich mich mit demselben Microsoft-Konto bei Windows angemeldet . Ich habe auf beiden PCs zu einem lokalen Konto gewechselt, und SQL Server stellt jetzt eine erfolgreiche Verbindung her.

In meinem Fall hatte jemand den Domänencontroller heruntergefahren, da ich in meiner Entwicklungsumgebung arbeitete, und Windows-Anmeldeinformationen konnten nicht authentifiziert werden. Nach dem Einschalten des Domänencontrollers verschwand der Fehler und alles funktionierte einwandfrei.

Eine weitere Nische zu diesem Problem, die durch Netzwerkverbindungen verursacht wird. Ich verbinde mich über einen Windows VPN-Client und dieses Problem trat auf, als ich von Wifi zu einer Kabelverbindung wechselte. Die Lösung für meine Situation bestand darin, die Adaptermetrik manuell anzupassen.

Verwenden Sie in Powershell Get-NetIPInterface, um alle Metrikwerte anzuzeigen. Die niedrigeren Zahlen sind kostengünstiger und werden daher von Fenstern bevorzugt. Ich habe das Ethernet und das VPN gewechselt und die Anmeldeinformationen wurden dort angezeigt, wo sie sein mussten, damit SSMS zufrieden war.

So konfigurieren Sie die automatische Metrikfunktion: Doppelklicken Sie in der Systemsteuerung auf Netzwerkverbindungen. Klicken Sie mit der rechten Maustaste auf eine Netzwerkschnittstelle, und wählen Sie dann Eigenschaften aus. Klicken Sie auf Internetprotokoll (TCP / IP) und wählen Sie dann Eigenschaften. Wählen Sie auf der Registerkarte Allgemein die Option Erweitert aus. Um eine Metrik anzugeben, deaktivieren Sie auf der Registerkarte IP-Einstellungen das Kontrollkästchen Automatische Metrik und geben Sie die gewünschte Metrik in das Feld Schnittstellenmetrik ein.

Quelle: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

Ich bin auf eine Variante dieser Ausgabe gestoßen, hier sind die Merkmale:

• Der Benutzer konnte erfolgreich eine Verbindung zu einer benannten Instanz herstellen, z. B. waren Verbindungen zu Server\Instanceerfolgreich
• Der Benutzer konnte keine Verbindung zur Standardinstanz herstellen, z. B. Verbindungen, Serverdie mit dem Screenshot des OP zu SSPI fehlgeschlagen sind
• Der Benutzer konnte keine Standardinstanz mit einem vollständig qualifizierten Namen verbinden, z. B. Verbindungen zu Server.domain.comfehlgeschlagen (Zeitüberschreitung).
• Der Benutzer konnte keine IP-Adresse ohne benannte Instanz verbinden, z. B. 192.168.1.134fehlgeschlagene Verbindungen
• Andere Benutzer, die sich nicht in der Domäne befinden (z. B. Benutzer, die eine VPN-Verbindung zum Netzwerk herstellen), aber Domänenanmeldeinformationen verwenden, konnten erfolgreich eine Verbindung zur Standardinstanz und IP-Adresse herstellen

Nach vielen Kopfschmerzen beim Versuch herauszufinden, warum dieser einzelne Benutzer keine Verbindung herstellen konnte, haben wir folgende Schritte unternommen, um die Situation zu beheben:

1. Sehen Sie sich den Server in der SPN-Liste mit
   setspn -l Server
   a an. In unserem Fall hieß esServer.domain.com
2. Fügen Sie der Hosts-Datei in einen Eintrag hinzu C:\Windows\System32\drivers\etc\hosts(führen Sie Notepad als Administrator aus, um diese Datei zu ändern). Der Eintrag, den wir hinzugefügt haben, war
   Server.domain.com Server

Danach konnten wir erfolgreich eine Verbindung über SSMS zur Standardinstanz herstellen.

Auch ich hatte dieses Problem unter SQL Server 2014 während der Protokollierung mit Windows-Authentifizierung. Um das Problem zu beheben, habe ich meinen Server einmal neu gestartet und dann versucht, mich anzumelden. Es hat bei mir funktioniert.