Kann SSPI-Kontext nicht erstellen

Question

Ich arbeite an einer .NET-Anwendung, wo ich den Datenbank-Skripte zu bauen versuchen. Während das Projekt Bau, erhalte ich eine Fehlermeldung „Kann SSPI-Kontext nicht schaffen.“. Dieser Fehler wird im Ausgabefenster (innen VS2008-Bildschirm) und der Bauprozess fehlgeschlagen gezeigt. Bitte helfen Sie zu diesem Thema. SQL Server konfiguriert ist, auf dem Windows-Authentifizierung und läuft als Netzdienst (diese beiden Dinge sind, müssen für mein Projekt) zu arbeiten.

Bitte helfen Sie zu diesem Thema. Dieser Fehler wird scheint nicht im Einklang zu sein. Es wurde durch einen Neustart der Maschine in der Vergangenheit festgelegt, die Änderung der Systemzeit die Domäne Zeit und einige Vorschläge im Netz anzupassen. Bitte helfen Sie zu diesem Thema.

Answer 1

Es ist ein sehr häufiger Fehler bei einer Vielzahl von Ursachen: beginnen hier mit KB 811889

• Welche Version von SQL Server?
• und Windows auf Client und Server?
• Lokal oder Netzwerk-SQL-Instanz?
• Domain oder Arbeitsgruppe? Provider?
• Passwort ändern
• Lokale Fenster log Fehler?
• Jede andere Anwendungen betroffen?

Answer 2

Es klingt wie Ihr PC über einen authentifizierenden Domänencontroller für eine kleine Weile nicht in Berührung gekommen ist. (Ich habe diese auf meinem Laptop ein paar Mal passieren haben.)

Es kann auch passieren, wenn Ihr Passwort abgelaufen ist.

Answer 3

Ich hatte das gleiche Problem nach dem Wechsel des Benutzers, die den MSSQLSERVER-Dienst ausgeführt wurde

Um eine falsche SPN mit SQL Server zu lösen benutzte ich dieses Tool

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

In meinem Fall ist es ziemlich gut.

Answer 4

Dieser Fehler kommt in der Regel, wenn das Windows-Benutzerkonto abgelaufen ist und er angemeldet ist bereits mit dem alten Passwort. Fragen Sie einfach den Benutzer seinen Computer neu zu starten und prüfen, ob das Kennwort abgelaufen ist, oder er hat das Passwort geändert.  Hoffe, das hilft !!!!!

Answer 5

Das erste, was Sie tun sollten, ist in den Protokollen gehen (Management\SQL Server Logs) und sehen, ob SQL Server successfully registered the Service Principal Name (SPN). Wenn Sie irgendeine Art von Fehler (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service) sehen, dann wissen Sie, wo Sie anfangen.

Wir sahen dies geschehen, wenn wir das Konto SQL Server ausgeführt wurde unter geändert. Zurücksetzen es auf Lokales Systemkonto das Problem gelöst. Microsoft hat auch eine führen manuell den SPN konfigurieren.

Answer 6

beschloß ich meine Cannot Generate SSPI Context Fehler durch den SQL Server Configuration Manager. Da ich SQL Server Native Client 10.0 auf meinem Rechner hat, wird die Verbindung mit dem Server versucht, Named Pipes zu verwenden (oder Shared Memory?). Andere Maschinen können meinen App ohne Probleme laufen. Als ich im Konfigurationsmanager sah, Named Pipes und Shared Memory waren beide aktiviert (gut). Allerdings unter Pseudonym gab es den Namen des Computers mit TCP gezwungen. Da ich nicht wusste, was diesen Effekt zu ändern würde, änderte ich die Verbindungszeichenfolge in meinem Programm verwenden . statt. Festgelegt.

Answer 7

Wenn Sie auf IIS hosten, stellen Sie sicher, das Kennwort für das Konto AppPool hat sich nicht geändert .

Wenn ja, dann gehen Sie folgendermaßen vor:

• Gehen Sie auf IIS
• Klicken Sie auf Anwendungspools
• Wählen Sie die AppPool Ihrer Anwendung
• Rechtsklick auf Ihrer AppPool
• Erweiterte Einstellungen
• Identität
• aktualisieren Passwort
• Restart AppPool

Answer 8

Die „Can not generieren SSPI Kontext“ Fehler ist sehr allgemein und kann für eine Vielzahl von Gründen geschehen. Ist nur ein Abdeckungsfehler für alle zugrunde liegenden Kerberos / NTLM Fehler. Gbn der KB Artikel-Link ist ein sehr guter Ausgangspunkt und löst usualy die Probleme. Wenn Sie immer noch Probleme haben, empfehle ich folgende Schritte zur Fehlerbehebung in Fehlerbehebung Kerberos Fehler .

Answer 9

Ich gebe auch dieses Problem und der Server-Admins es gelöst, indem Sie die gleiche Lösung wie indu_teja vorgeschlagen in http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx

Die Lösung von indu_teja vorgeschlagen sagt:

  

Wenn Sie erhalten diesen "SSPI Kontext Error". Die Themen, die wir konfrontiert sind:

     

  
1. Wir werden nicht aus der Ferne zu SQL Server verbinden können.
  
2. Jedoch werden wir in der Lage sein, auf dem Server mit lokalem Konto zu verbinden.
  

     

Ursache: Das Problem könnte becasue ohne richtige Synchronisierung happenign fro die sein   SPN in Active Directory.

     

AUFLÖSUNG:

     

  
1. Sie müssen SPN zurücksetzen. Verwenden Sie die synytax "SET SPN". Sie können einmal die Syntax im Netz überprüfen.
  
2. ändern Sie Ihr SQL Server-Dienstkonto von Domänenkonto Lokales Konto, recycle sql, und dann mit Ihrem Domänenkonto wieder zurückgesetzt und SQL Server recyceln.
  

Answer 10

Ich hatte gerade das gleiche Problem und alles, was ich tat, war der Benutzer die Anmeldeinformationen in SQL Server löschen unter Verwendung eines anderen Benutzer-ID und das Hinzufügen von ihnen zurück.

Answer 11

Hier ist mein Fall. Ich hatte einen Remote-Computer, auf dem SQL Server gehostet. Aus meiner lokalen Maschine, habe ich versucht, die SQL-Instanz über einige C # -Code für den Zugriff auf und ich war diesen Fehler. Mein Passwort für das Benutzerkonto auf meinem Rechner / Domain hatte abgelaufen . Ich reparierte es mit dem folgenden:

1. den Remote-Computer geöffnet, was für eine Änderung des Kennworts aufgefordert, mich
2. Ich änderte mein Passwort innerhalb dieser Aufforderung und protokolliert in den Remote-Computer
3. I „gesperrt“ mein lokaler Rechner (mit windows + L Schlüsseln, damit ich nicht völlig unterschreiben müssen), so dass ich auf die Anmeldeseite zurück könnte
4. Ich habe ich wieder auf meinem lokalen Rechner mit dem neuen Passwort

Alles dann hat gut funktioniert.

Answer 12

In meinem Fall war es ein fehlendes SPN, hatte diese beiden Befehle auszuführen:

  

setspn -a MSSQLSvc: Server SERVER   setspn -a MSSQLSvc: Servername: 1433 SERVER

Mit anderen Worten: in meinem Fall habe ich dort den FQDN hatte in bereits korrekt aber nicht nur den NetBIOS-Namen, nachdem dieser Zugabe es funktionierte gut. Nun zunächst tat es nicht, aber nach einer Wartezeit 2 Minuten tat es.

Answer 13

Ich hatte das fehler- es geschah, weil mein Passwort abgelaufen, und ich hatte es zu ändern. Ich habe es nicht bemerkt, weil in einigen Programmen konnte ich noch einloggen und alles funktionieren würde normalerweise (einschließlich Windows), aber ich konnte nicht an SQL-Server anmelden.

Answer 14

Vielleicht haben Sie Integrated Security = SSPI in Verbindungszeichenfolge verwendet. SSPI wird für vertrauenswürdige Verbindungen verwendet Windows-Authentication.hence verwenden, richtig Authentifizierung in Windows zu arbeiten, entweder Ihr System und Datenbankserver in derselben Domäne sein sollen und gleichen DNS-Server-Adresse, oder sollten in vertrauenswürdiger Domäne sein.

Wenn Sie Ihr System und Datenbank-Server in derselben Domäne ist, überprüft DNS-Serveradresse von IPV4 Eigenschaften in Ihrem System der Netzwerkverbindung und bietet gleiche DNS-Server-Datenbankserver verwendet wird.

Answer 15

In vb.net, wenn Sie einen Verbindungsserver verwenden als Verbindungszeichenfolge überprüfen. Integrated Security = true; nicht in allen SQL-Provider arbeitet, wirft es eine Ausnahme, wenn sie mit dem OLE DB-Provider verwendet. Also im Grunde Integrated Security = SSPI; bevorzugt, da funktioniert sowohl mit SQLClient & OleDB bieten. Wenn Sie noch mit dem Fehler betroffen, entfernen Sie die Syntax vollständig.

Answer 16

Ich kann die Lage, dies durch die Domain Zurücksetzen entschlossen zu erhalten (Server-Maschine, die der Domain-Server, aber nicht auf SQL Server außer Domäne Verwaltung verwandt) durch die Client-Rechner gefolgt.

Vielen Dank für Ihre sofortige Unterstützung!

Answer 17

ein wirklich seltsam Beispiel dafür ist; Alle Web-Produkte, die Verbindungszeichenfolgen hatte den Windows-Computernamen des SQL-Servers enthält, hat gut funktioniert, aber die Produkte, die einen FQDN mit der internen Domäne hatte angebracht gab einen SSPI Fehler. d.h. COMPUTERNAME vs computername.domain (Ping arbeitete immer wie erwartet)

Diese ONLY Probleme gab, wenn ein neuen SQL Server verwendet wurde und Host-Dateien zeigten sowohl die Computernamen und die Computernamen als FQDN für die Verbindungszeichenfolgen.

Lösung war in diesem Fall nur alle Verbindungszeichenfolgen auf die Computernamen zu setzen, um die Domain Referenzen zu entfernen.

SQL: 2008R2 SQL2012

IIS: 2008R2

Answer 18

Wir hatten dieses Problem auf Fälle, in denen wir den Service-Benutzer von Domain1 \ ServiceUser zu Domain2 \ ServiceUser geändert. Die SPN blieb unter Domain1 \ ServiceUser registriert, und nie unter Domain2 \ ServiceUser registriert. Ich registrierte die SPNs unter Domain2 \ ServiceUser, aber das Problem blieb. Ich entfernte dann die SPNs unter Domain1 \ ServiceUser, und das Problem behoben wurde.