Ich arbeite an einer .NET-Anwendung, in der ich versuche, die Datenbankscripts zu erstellen. Beim Erstellen des Projekts wird die Fehlermeldung "SSPI-Kontext kann nicht erstellt werden" angezeigt. Dieser Fehler wird im Ausgabefenster (im VS2008-Bildschirm) angezeigt und der Aufbauprozess ist fehlgeschlagen. Bitte helfen Sie dabei. SQL Server ist so konfiguriert, dass es mit der Windows-Authentifizierung funktioniert und als Netzwerkdienst ausgeführt wird (diese beiden Dinge sind für mein Projekt unbedingt erforderlich).
Bitte helfen Sie dabei. Dieser Fehler scheint nicht konsistent zu sein. In der Vergangenheit wurde das Problem behoben, indem der Computer neu gestartet und die Systemzeit an die Domänenzeit und einige Vorschläge im Netz angepasst wurde. Bitte helfen Sie dabei.
Es ist ein ziemlich häufiger Fehler mit einer Vielzahl von Ursachen: Beginnen Sie hier mit KB 811889
Es hört sich an, als hätte Ihr PC eine Weile keinen authentifizierenden Domänencontroller kontaktiert. (Früher habe ich das ein paar Mal auf meinem Laptop passiert.)
Es kann auch vorkommen, wenn Ihr Passwort abläuft.
Ich hatte das gleiche Problem, nachdem ich den Benutzer gewechselt hatte, der den MSSQLSERVER-Service ausführte
Um falsche SPNs mit SQL Server zu lösen, habe ich dieses Tool verwendet
http://www.Microsoft.com/en-us/download/details.aspx?id=39046 - Microsoft® Kerberos Configuration Manager für SQL Server
In meinem Fall hat es ziemlich gut funktioniert.
Dieser Fehler tritt normalerweise auf, wenn das Windows-Benutzerkonto abgelaufen ist und er bereits mit dem alten Kennwort angemeldet ist .. __ Bitten Sie den Benutzer, den Computer neu zu starten, und prüfen Sie, ob das Kennwort abgelaufen ist oder ob er das Kennwort geändert hat. Hoffe das hilft!!!!!
Als Erstes sollten Sie in die Protokolle (Management\SQL Server Logs
) gehen und nachsehen, ob SQL Server successfully registered the Service Principal Name (SPN)
. Wenn Sie eine Art Fehler (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service
) sehen, wissen Sie, wo Sie anfangen sollen.
Wir haben dies gesehen, als wir das Konto geändert haben, unter dem SQL Server ausgeführt wurde. Durch das Zurücksetzen auf das lokale Systemkonto wurde das Problem behoben. Microsoft verfügt auch über eine guide on-Konfiguration des SPN.
Ich habe meinen Cannot Generate SSPI Context
-Fehler mit dem SQL Server-Konfigurations-Manager behoben. Da auf meinem Computer der native SQL Server-Client 10.0 installiert ist, versucht die Verbindung zum Server, Named Pipes (oder Shared Memory?) Zu verwenden. Andere Maschinen könnten meine App ohne Probleme ausführen. Als ich den Konfigurationsmanager ansah, waren Named Pipes und Shared Memory beide aktiviert (gut). Unter Alias wurde der Name des Computers jedoch mit TCP erzwungen. Da ich nicht wusste, welche Auswirkungen eine Änderung hätte, habe ich die Verbindungszeichenfolge in meinem Programm geändert und stattdessen <Servername>. <Domänenname> verwendet. Fest.
Wenn Sie auf IIS hosten, müssen Sie stellen Sie sicher, dass sich das Kennwort für das AppPool-Konto nicht geändert hat.
Wenn ja, dann gehen Sie folgendermaßen vor:
Ich habe dieses Problem auch ausgegeben, und die Serveradministratoren haben es gelöst, indem sie dieselbe Lösung wie in http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx vorgeschlagen haben
Die von indu_teja vorgeschlagene Lösung lautet:
Wenn Sie diese "SSPI Context Error" erhalten. Die Probleme, mit denen wir konfrontiert sind, sind:
- Wir können keine Remote-Verbindung zu SQL Server herstellen.
- Wir können jedoch eine Verbindung zum Server mit lokalem Konto herstellen.
URSACHE: Das Problem ist möglicherweise darauf zurückzuführen, dass die SPNs in Active Directory nicht ordnungsgemäß synchronisiert wurden.
AUFLÖSUNG:
- Sie müssen SPN zurücksetzen. Verwenden Sie die Synytax "SET SPN". Sie können die Syntax in net einmal überprüfen.
- Ändern Sie Ihr SQL Server-Dienstkonto von Domänenkonto in Lokales Konto, recyceln Sie SQL und setzen Sie es dann mit Ihrem Domänenkonto zurück und recyceln Sie SQL Server.
Der Fehler "SSPI-Kontext kann nicht generiert werden" ist sehr generisch und kann aus einer Vielzahl von Gründen auftreten. Ist nur ein Abdeckungsfehler für einen zugrunde liegenden Kerberos/NTLM-Fehler. Der KB-Artikellink von Gbn ist ein sehr guter Ausgangspunkt und löst normalerweise die Probleme. Wenn Sie immer noch Probleme haben, empfiehlt es sich, die Schritte zur Fehlerbehebung in Fehlerbehebung bei Kerberos-Fehlern auszuführen.
Ich hatte gerade das gleiche Problem und alles, was ich tat, war, die Anmeldeinformationen des Benutzers im SQL-Server mit einer anderen Benutzer-ID zu löschen und wieder hinzuzufügen.
Wenn Sie in vb.net einen Verbindungsserver verwenden, überprüfen Sie Ihre Verbindungszeichenfolge. Integrierte Sicherheit = wahr; funktioniert nicht in allen SQL-Providern, sondern löst bei Verwendung mit dem OleDb-Provider eine Ausnahme aus. Also im Grunde integrierte Sicherheit = SSPI; wird bevorzugt, da es sowohl mit SQLClient als auch mit OleDB funktioniert. Wenn Sie immer noch mit Fehler treffen, entfernen Sie die Syntax vollständig.
Hatte ein wirklich merkwürdiges Beispiel davon; Alle Webprodukte, die Verbindungszeichenfolgen enthielten, die den Windows-Computernamen des SQL-Servers enthielten, funktionierten einwandfrei. Die Produkte mit einem vollqualifizierten Domänennamen (FQDN) mit angehängter interner Domäne ergaben jedoch einen SSPI-Fehler . __. COMPUTERNAME.DOMAIN (Ping funktionierte immer wie erwartet)
Dies führte NUR zu Problemen, wenn ein neuer SQL-Server verwendet wurde, und hostete Dateien, auf die sowohl der Computername als auch der Computername als FQDN für die Verbindungszeichenfolgen verwiesen wurden.
Die Lösung bestand in diesem Fall darin, alle Verbindungszeichenfolgen nur auf den Computernamen festzulegen und die Domänenverweise zu entfernen.
SQL: 2008R2 SQL2012
IIS: 2008R2
Ich kann dieses Problem beheben, indem ich die Domäne (Server-Computer, der zwar der Domänen-Server ist, aber nicht mit SQL Server verbunden ist, außer der Domänenverwaltung) zurückstellt, gefolgt von den Client-Computern.
Vielen Dank für Ihre sofortige Unterstützung!
Hier ist mein Fall. Ich hatte einen Remote-Computer, auf dem SQL Server gehostet wurde. Von meinem lokalen Computer aus habe ich versucht, über C # -Code auf die SQL-Instanz zuzugreifen, und ich habe diesen Fehler erhalten. Mein Passwort für das Benutzerkonto auf meinem Computer/meiner Domäne war abgelaufen . Ich habe es mit folgendem behoben:
windows
+ L
, damit ich mich nicht vollständig abmelden musste), damit ich zur Anmeldeseite zurückkehren konnteAlles hat dann gut funktioniert.
In meinem Fall war es ein fehlender SPN, der diese beiden Befehle ausführen musste:
setspn -a MSSQLSvc: SERVERNAME SERVERNAME setspn -a MSSQLSvc: SERVERNAME: 1433 SERVERNAME
Mit anderen Worten, in meinem Fall hatte ich den FQDN bereits korrekt, aber nicht nur den NETBIOS-Namen. Nachdem er diese hinzugefügt hatte, funktionierte er einwandfrei. Nun, anfangs nicht, aber nach einer Wartezeit von 2 Minuten.
Möglicherweise haben Sie Integrated Security = SSPI in Verbindungszeichenfolge verwendet. SSPI wird für vertrauenswürdige Verbindungen mit Windows-Authentifizierung verwendet. Damit Windows-Authentifizierung ordnungsgemäß funktioniert, sollten sich Ihr System- und Datenbankserver in derselben Domäne befinden und dieselbe DNS-Serveradresse verwenden oder in einer vertrauenswürdigen Domäne sein.
wenn sich Ihr System und der Datenbankserver in derselben Domäne befinden, überprüfen Sie die DNS-Serveradresse der IPV4-Eigenschaften in der Netzwerkverbindung Ihres Systems und stellen Sie denselben DNS-Server bereit, der vom Datenbankserver verwendet wird.
Ich hatte diesen Fehler. Dies geschah, weil mein Passwort abgelaufen war und ich es ändern musste. Ich habe es nicht gemerkt, weil ich mich in einigen Programmen immer noch einloggen konnte und alles normal funktionieren würde (einschließlich Windows), aber ich konnte mich nicht bei SQL-Servern anmelden.
Wenn Sie einen Code ausführen, der nicht auf Ihrem Computer geschrieben ist, sondern auf einem Computer, der von Ihrem Arbeits-Peer verwendet wird, überprüfen Sie die Datei web.config. Möglicherweise gibt es den Namen Ihres Kollegen als userPrincipalName an einer Stelle, die leer sein sollte. Dies geschieht automatisch, wenn wir in VS eine Servicereferenz zum Projekt erstellen.
Dieses Problem trat in Fällen auf, in denen der Dienstbenutzer von Domain1\ServiceUser in Domain2\ServiceUser geändert wurde. Die SPNs blieben unter Domain1\ServiceUser registriert und wurden nie unter Domain2\ServiceUser registriert. Wir haben die SPNs unter Domain2\ServiceUser registriert, aber das Problem blieb bestehen. Wir haben dann die SPNs unter Domain1\ServiceUser entfernt und das Problem wurde behoben.