Impossibile creare il contesto SSPI

Question

Sto lavorando su un'applicazione .NET in cui sto cercando di creare gli script del database.Durante la creazione del progetto, ricevo l'errore "Impossibile creare il contesto SSPI.".Questo errore viene visualizzato nella finestra di output (all'interno della schermata VS2008) e il processo di creazione non è riuscito.Per favore aiutatemi.SQL Server è configurato per funzionare con l'autenticazione di Windows e funzionare come servizio di rete (queste due cose sono indispensabili per il mio progetto).

Per favore aiutatemi.Questo errore non sembra essere coerente.In passato il problema veniva risolto riavviando la macchina, modificando l'ora del sistema in modo che corrispondesse all'ora del dominio e alcuni suggerimenti in rete.Per favore aiutatemi.

Answer 1

È un errore abbastanza comune con una varietà di cause: inizia qui con KB 811889

• Quale versione di SQL Server?
• E Windows su client e server?
• Istanza SQL locale o di rete?
• Dominio o gruppo di lavoro? Provider?
• Modifica password
• Errori del registro locale di Windows?
• Altre app interessate?

Answer 2

Sembra che il tuo PC non abbia contattato un controller di dominio per un po 'di tempo. (Prima accadevo che questo accadesse sul mio laptop alcune volte.)

Può succedere anche se la password scade.

Answer 3

Ho avuto lo stesso problema dopo aver cambiato l'utente che stava eseguendo il servizio MSSQLSERVER

Per risolvere SPN errati con SQL Server ho usato questo strumento

http://www.microsoft.com/en- us / download / details.aspx? id = 39046 - Microsoft & # 174; Kerberos Configuration Manager per SQL Server

Nel mio caso ha funzionato abbastanza bene.

Answer 4

Questo errore si verifica in genere quando l'account utente di Windows è scaduto e ha già effettuato l'accesso con la vecchia password. Basta chiedere all'utente di riavviare la sua macchina e verificare se la password è scaduta o se ha cambiato la password.  Spero che questo aiuti !!!!!

Answer 5

La prima cosa da fare è andare nei registri (Management\SQL Server Logs) e vedere se SQL Server successfully registered the Service Principal Name (SPN). Se vedi una sorta di errore (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service), sai da dove iniziare.

L'abbiamo visto accadere quando abbiamo cambiato l'account con cui era in esecuzione SQL Server. Il ripristino dell'account di sistema locale ha risolto il problema. Microsoft ha anche una guida sulla configurazione manuale dell'SPN.

Answer 6

Ho risolto il mio errore Cannot Generate SSPI Context utilizzando Gestione configurazione SQL Server. Dal momento che ho il client nativo 10.0 di SQL Server sul mio computer, la connessione al server sta tentando di utilizzare named pipe (o memoria condivisa?). Altre macchine potrebbero eseguire la mia app senza problemi. Quando ho guardato il gestore della configurazione, le pipe con nome e la memoria condivisa erano entrambe abilitate (bene). Tuttavia, alias, il nome del computer era lì con TCP forzato. Dato che non sapevo quale effetto avrebbe avuto la modifica, ho cambiato la stringa di connessione nel mio programma per usare & Lt; servername & Gt;. & Lt; domainname & Gt; anziché. Fisso.

Answer 7

Se stai ospitando su IIS, assicurati che la password per l'account AppPool non sia cambiata .

In caso affermativo, segui questi passaggi:

• Vai a IIS
• Fai clic su Pool di applicazioni
• Seleziona l'AppPool della tua applicazione
• Fai clic destro sul tuo AppPool
• Impostazioni avanzate
• Identità
• Aggiorna password
• Riavvia AppPool

Answer 8

Il " Impossibile generare il contesto SSPI " l'errore è molto generico e può accadere per una moltitudine di ragioni. È solo un errore di copertina per qualsiasi errore Kerberos / NTLM sottostante. Il link all'articolo KB di Gbn è un ottimo punto di partenza e risolve di solito i problemi. Se i problemi persistono, ti consiglio di seguire i passaggi per la risoluzione dei problemi in Risoluzione dei problemi relativi agli errori Kerberos .

Answer 9

Ho anche riscontrato questo problema e gli amministratori del server lo hanno risolto seguendo la stessa soluzione proposta da indu_teja in http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx

La soluzione proposta da indu_teja dice:

  

Se ottieni questo " Errore di contesto SSPI " ;. I problemi che affrontiamo sono:

     

  
1. Non saremo in grado di connetterci a SQL Server da remoto.
  
2. Tuttavia saremo in grado di connetterci al server con un account locale.
  

     

CAUSA: il problema potrebbe essere dovuto alla mancata sincronizzazione corretta per   SPN in Active Directory.

     

Risoluzione:

     

  
1. È necessario ripristinare SPN. Utilizzare la sintassi & Quot; SET SPN & Quot ;. Puoi verificare la sintassi in net una volta.
  
2. Cambia l'account del servizio server sql dall'account di dominio all'account locale, ricicla sql e quindi ripristina nuovamente con il tuo account di dominio e ricicla il server sql.
  

Answer 10

Ho appena avuto lo stesso problema e tutto ciò che ho fatto è stato eliminare le credenziali di accesso dell'utente nel server sql utilizzando un altro ID utente e aggiungendole nuovamente.

Answer 11

Ecco il mio caso. Avevo una macchina remota che ospitava SQL Server. Dal mio computer locale, stavo provando ad accedere all'istanza SQL tramite un codice C # e stavo ottenendo questo errore. La mia password per l'account utente sul mio computer / dominio era scaduta . L'ho risolto con il seguente:

1. Ha aperto il computer remoto, che mi ha richiesto una modifica della password
2. Ho cambiato la mia password all'interno di questo prompt e ho effettuato l'accesso al computer remoto
3. I " bloccato " il mio computer locale (utilizzando il tasto windows + L in modo da non dover firmare completamente) in modo da poter tornare alla pagina di accesso
4. Sono tornato sul mio computer locale con la nuova password

Tutto quindi ha funzionato bene.

Answer 12

Nel mio caso era un SPN mancante, dovevo eseguire questi due comandi:

  

setspn -a MSSQLSvc: SERVERNAME SERVERNAME   setspn -a MSSQLSvc: SERVERNAME: 1433 SERVERNAME

In altre parole, nel mio caso avevo già inserito l'FQDN correttamente, ma non solo il nome NETBIOS, dopo averli aggiunti funzionava bene. Beh, inizialmente non lo ha fatto, ma dopo aver atteso 2 minuti lo ha fatto.

Answer 13

Ho avuto questo errore, è successo perché la mia password è scaduta e ho dovuto cambiarla. Non me ne sono accorto, perché in alcuni programmi potevo ancora accedere e tutto avrebbe funzionato normalmente (comprese le finestre), ma non potevo accedere a nessun server sql.

Answer 14

Forse hai usato Integrated Security = SSPI nella stringa di connessione. SSPI viene utilizzato per le connessioni Trusted utilizzando Windows Authentication.hence, per funzionare correttamente nell'autenticazione di Windows, il sistema e il server di database devono trovarsi nello stesso dominio e utilizzare lo stesso indirizzo del server DNS o devono essere nel dominio trusted.

se il sistema e il server database si trovano nello stesso dominio, controllare l'indirizzo del server DNS delle proprietà IPV4 nella connessione di rete del sistema e fornire lo stesso server DNS utilizzato dal server database.

Answer 15

In vb.net, se si utilizza un server collegato, controllare la stringa di connessione. Sicurezza integrata = true; non funziona in tutti i provider SQL, genera un'eccezione se utilizzato con il provider OleDb. Quindi, fondamentalmente, Integrated Security = SSPI; è preferito poiché funziona con entrambi gli ampli SQLClient &; OleDB fornisce. Se il problema persiste, rimuovi completamente la sintassi.

Answer 16

Posso risolverlo ripristinando il dominio (macchina server, che è il server di dominio, ma non correlato a SQL Server tranne la gestione del dominio) seguito dalle macchine client.

Grazie a tutti per il vostro supporto immediato!

Answer 17

Ho avuto un esempio davvero strano di questo;Tutti i prodotti Web che avevano stringhe di connessione contenenti il ​​nome del computer Windows del server SQL funzionavano correttamente, ma i prodotti che avevano un FQDN con il dominio interno allegato restituivano un errore SSPI.cioè.ComputerName vs ComputerName.Domain (Ping ha sempre funzionato come previsto)

Ciò dava problemi SOLO quando veniva utilizzato un nuovo server SQL e i file host indicavano sia il nome del computer che il nome del computer come FQDN per le stringhe di connessione.

La soluzione in questo caso è stata impostare tutte le stringhe di connessione solo sul nome del computer, rimuovendo i riferimenti al dominio.

SQL:2008R2SQL2012

IIS:2008R2

Answer 18

Abbiamo riscontrato questo problema nei casi in cui abbiamo cambiato l'utente del servizio da Domain1 \ ServiceUser a Domain2 \ ServiceUser. Gli SPN sono rimasti registrati in Domain1 \ ServiceUser e mai registrati in Domain2 \ ServiceUser. Abbiamo registrato gli SPN in Domain2 \ ServiceUser, ma il problema persisteva. Abbiamo quindi rimosso gli SPN in Domain1 \ ServiceUser e il problema è stato risolto.