Il nome dell'entità di destinazione non è corretto. Impossibile generare il contesto SSPI

Sto lottando per ottenere una connessione SQL Server dalla macchina A alla macchina B che esegue SQL Server.

Ho cercato su Google ampiamente e tutte le cose che ho trovato non hanno funzionato. Né ti guidano passo dopo passo nel processo di risoluzione del problema.

Non stiamo usando Kerberos, ma NTLM dove configurato.

Le macchine coinvolte sono (xx è usato per oscurare parte del nome della macchina per motivi di sicurezza):

• xxPRODSVR001 : controller di dominio di Windows Server 2012
• xxDEVSVR003 - Windows Server 2012 (questa macchina sta generando l'errore)
• xxDEVSVR002 - Windows Server 2012 (questa macchina esegue SQL Server 2012)

I seguenti SPN sono registrati nel controller di dominio (xxPRODSVR001). Ho oscurato il dominio con yyy per motivi di sicurezza:

ServicePrincipalNames registrati per CN = xxDEVSVR002, CN = Computers, DC = yyy, DC = local:

            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

ServicePrincipalNames registrati per CN = xxDEVSVR003, CN = Computers, DC = yyy, DC = local:

            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

Ora, se solo il messaggio di errore di SQL Server fosse più descrittivo e mi dicesse a quale nome principale stava cercando di connettersi, potrei essere in grado di diagnosticare questo.

Quindi qualcuno può spiegarmi come risolvere questo problema o riesci a vedere qualcosa di sbagliato in ciò che ho fornito?

Sarei felice di generare più informazioni di debug, dimmi solo di cosa hai bisogno.

Ho avuto questo problema con un'app ASP.NET MVC su cui stavo lavorando.

Mi sono reso conto di aver recentemente cambiato la mia password e sono stato in grado di risolverlo disconnettendomi e ricollegandomi.

Ho ricevuto questo errore durante la connessione tramite SQL Server Management Studio utilizzando l'autenticazione di Windows. La mia password era scaduta ma non l'avevo ancora cambiata. Una volta modificato, ho dovuto disconnettermi e riconnettermi in modo che la macchina funzionasse utilizzando le mie nuove credenziali.

Prova a impostare Integrated Security=trueper rimuovere questo parametro dalla stringa di connessione.

IMPORTANTE: come ha commentato l'utente @Auspex,

La rimozione di Integrated Security impedirà questo errore, perché l'errore si verifica quando si tenta di accedere con le credenziali di Windows. Sfortunatamente, la maggior parte delle volte, vuoi essere in grado di accedere con le tue credenziali di Windows

Ho ricevuto lo stesso errore durante il tentativo di autenticazione di Windows. Sembra ridicolo, ma nel caso in cui aiuti qualcun altro: è stato perché il mio account di dominio è stato bloccato in qualche modo mentre ero ancora connesso (!). Lo sblocco dell'account lo ha risolto.

Accedevo a Windows 10 con un PIN invece di una password. Mi sono disconnesso e ho effettuato di nuovo l'accesso con la mia password e sono stato in grado di accedere a SQL Server tramite Management Studio.

L'errore di contesto SSPI indica sicuramente che si sta tentando di autenticare utilizzando Kerberos .

Poiché l'autenticazione Kerberos L'autenticazione Windows di SQL Server si basa su Active Directory , che richiede una relazione rafforzata tra il computer e il controller di dominio di rete, è necessario iniziare convalidando tale relazione.

Puoi verificare rapidamente tale relazione, tramite il seguente comando Powershell Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

Se restituisce False , è necessario riparare il canale protetto Active Directory del computer, poiché senza di esso non è possibile la convalida delle credenziali di dominio all'esterno del computer.

Puoi riparare il tuo Computer Secure Channel, tramite quanto segue comando Powershell :

Test-ComputerSecureChannel -Repair

Controlla i log degli eventi di sicurezza, se stai usando Kerberos dovresti vedere i tentativi di accesso con il pacchetto di autenticazione: Kerberos.

L'autenticazione NTLM potrebbe non riuscire e quindi viene effettuato un tentativo di autenticazione Kerberos. Potresti anche vedere un tentativo di accesso NTLM non riuscito nel registro degli eventi di sicurezza?

Puoi attivare la registrazione degli eventi di Kerberos in dev per provare a eseguire il debug del motivo per cui Kerberos non riesce, sebbene sia molto prolisso.

Kerberos Configuration Manager di Microsoft per SQL Server può aiutarti a diagnosticare e risolvere rapidamente questo problema.

Ecco una bella storia da leggere: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Solo per aggiungere un'altra potenziale soluzione a questo più ambiguo degli errori The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Verificare che l'IP che viene risolto durante il ping di SQL Server sia lo stesso di quello in Configuration Manager. Per verificare, apri Gestione configurazione SQL Server e quindi vai a Configurazione di rete SQL Server> Protocolli per MSSQLServer> TCP / IP.

Assicurati che TCP / IP sia abilitato e nella scheda Indirizzi IP, assicurati che l'IP su cui il server risolve quando esegue il ping sia lo stesso qui. Questo ha risolto questo errore per me.

Il problema sembra essere un problema di credenziali di Windows. Ricevo lo stesso errore sul mio laptop da lavoro con una VPN. Presumibilmente sono loggato come mio dominio / nome utente, che è quello che uso con successo quando mi connetto direttamente, ma non appena passo a una VPN con un'altra connessione ricevo questo errore. Ho pensato che fosse un problema DNS in quanto potevo eseguire il ping del server, ma risulta che avevo bisogno di eseguire SMSS esplicitamente come mio utente dal prompt dei comandi.

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

Accedi sia alla tua casella SQL che al tuo client e digita:

ipconfig /flushdns
nbtstat -R

Se non funziona, rinnova il tuo DHCP sulla tua macchina client ... Funziona per 2 PC nel nostro ufficio.

Mi sono appena imbattuto in questo e l'ho risolto facendo 2 cose:

1. Concessione di autorizzazioni di lettura / scrittura servicePrincipalName all'account di servizio utilizzando ADSI Edit, come descritto in https://support.microsoft.com/en-us/kb/811889

2. Rimozione degli SPN che esistevano in precedenza nell'account del computer SQL Server (al contrario dell'account del servizio) utilizzando

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

   dove 1234 era il numero di porta utilizzato dall'istanza (la mia non era un'istanza predefinita).

Nel mio caso, il riavvio di SQL Server 2014 (sul mio server di sviluppo) ha risolto il problema.

Stavo testando IPv6 su un cluster di PC in una rete isolata e ho riscontrato questo problema quando ho ripristinato IPv4. Ero stato giocato nella directory attiva, DNS e DHCP, quindi non ho idea di cosa ho spinto per interrompere l'installazione di Kerberos.

Ho ritestato la connessione al di fuori del mio software con questo utile suggerimento per collegare la connettività remota che ho trovato.

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

quindi, dopo una breve ricerca, ho trovato questo sul sito Web Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

esegui lo strumento sul server SQL per vedere se ci sono problemi se lo stato dice errore, quindi premi il pulsante di correzione che appare.

Questo ha risolto il problema per me.

Ciò è solitamente dovuto a nomi di principio del servizio (SPN) mancanti, errati o duplicati

Passaggi per risolvere:

1. Conferma l'account AD utilizzato da SQL Server
2. Esegui il seguente comando in Powershell o CMD in modalità amministratore (l'account di servizio non deve contenere il dominio)

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

3. Assicurati che l'output restituito contenga un SPN completamente qualificato, non completamente qualificato, con una porta e senza una porta.

   Uscita prevista:

   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. Se non vedi tutto quanto sopra, esegui il seguente comando in PowerShell o CMD in modalità amministratore (assicurati di cambiare la porta se non usi il 1433 predefinito)

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. Una volta completato quanto sopra, normalmente sono necessari alcuni minuti per la propagazione DNS

Inoltre, se ricevi un messaggio relativo agli SPN duplicati trovati, potresti volerli eliminare e ricrearli

Ho avuto questo problema durante l'accesso all'applicazione web. Potrebbe essere dovuto al fatto che di recente ho cambiato una password di Windows.

Questo problema è stato risolto quando ho aggiornato la password per il pool di app in cui ho ospitato l'applicazione web.

Controlla le corrispondenze dell'orologio tra il client e il server.

Quando ho riscontrato questo errore a intermittenza, nessuna delle risposte precedenti ha funzionato, quindi abbiamo scoperto che il tempo si era spostato su alcuni dei nostri server, una volta sincronizzati nuovamente l'errore è andato via. Cerca w32tm o NTP per vedere come sincronizzare automaticamente l'ora su Windows.

Dato che sono atterrato qui mentre cercavo una soluzione al mio problema, condividerò la mia soluzione qui, nel caso in cui altri atterrino anche qui.

Mi stavo collegando bene a SQL Server fino a quando la mia macchina non è stata spostata in un altro ufficio su un altro dominio . Quindi, dopo il passaggio, ho ricevuto questo errore relativo al nome principale di destinazione. Ciò che ha risolto il problema è stato la connessione utilizzando un nome completo come: server.domain.com . E in realtà, una volta che mi sono connesso al primo server in questo modo, potrei connettermi ad altri server usando solo il nome del server (senza la qualifica completa), ma il tuo chilometraggio può variare.

Mi sono imbattuto in questo oggi e volevo condividere la mia correzione, poiché questa è semplicemente trascurata e facile da risolvere.

Gestiamo il nostro rDNS e recentemente abbiamo rifatto il nostro schema di denominazione dei server. Come parte di ciò, avremmo dovuto aggiornare il nostro rDNS e dimenticarci di farlo.

Un ping ha restituito il nome host corretto, ma un ping -a ha restituito il nome host sbagliato.

Soluzione facile: cambia il rDNS, esegui un ipconfig / flushdns, aspetta 30 secondi (solo qualcosa che faccio), fai un altro ping -a, guarda che risolve il nome host corretto, connettiti ... guadagna.

Mi sono imbattuto in uno nuovo per questo: SQL 2012 ospitato su Server 2012. È stato incaricato di creare un cluster per SQL AlwaysOn.
Il cluster è stato creato e tutti hanno ricevuto il messaggio SSPI.

Per risolvere i problemi ha eseguito il seguente comando:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== l'account di dominio che ho impostato per SQL Avevo bisogno di un amministratore di dominio per eseguire il comando. Solo un server nel cluster ha avuto problemi.

Quindi riavviato SQL. Con mia grande sorpresa sono riuscito a connettermi.

Stavo cercando di connettermi a una macchina virtuale che esegue SQL Server 2015 dal mio laptop in un'app console di Visual Studio 2015. Ho eseguito la mia app la sera prima e va bene. Al mattino provo a eseguire il debug dell'app e ottengo questo errore. Ho provato ipconfig/flushe release+ renewe un mucchio di altra spazzatura, ma alla fine ...

Riavvia la tua VM e riavvia il client. Questo ha risolto il problema per me. Avrei dovuto saperlo, il riavvio funziona ogni volta.

Ho avuto questo problema sul mio server sql. Ho setspn -D mssqlsvc \ Hostname.domainname Hostname quindi mi sono fermato e ho avviato il mio servizio di server SQL.

Sto pensando che solo l'arresto e l'avvio del mio servizio sql l'avrebbe fatto.

Ho avuto lo stesso problema, ma bloccare e sbloccare la macchina ha funzionato per me. A volte, i problemi del firewall daranno errori.

Non sono sicuro che funzionerà per te o no, condivido solo la mia esperienza.

Ho provato tutte le soluzioni qui e nessuna di esse ha ancora funzionato. Una soluzione alternativa che funziona è fare clic su Connetti , immettere il nome del server, selezionare Opzioni, scheda Proprietà connessione. Impostare il "Protocollo di rete" su "Named Pipes". Ciò consente agli utenti di connettersi in remoto utilizzando le proprie credenziali di rete. Pubblicherò un aggiornamento quando avrò una correzione.

Nel mio caso, il problema era impostare il DNS sul wifi. Ho rimosso le impostazioni, le ho lasciate vuote e ho lavorato.

Assicurati che "Named Pipes" sia abilitato da "SQL Server Configuration Manager". Questo ha funzionato per me.

1. Apri "Gestione configurazione SQL Server".
2. Espandi "Configurazione di rete SQL Server", dall'elenco a sinistra.
3. Seleziona "Protocolli per [nome istanza]".
4. Fare clic con il tasto destro su "Named Pipes", dall'elenco a destra.
5. Seleziona "Abilita"
6. Riavvia il servizio Istanza.

Questo strumento Microsoft è come Magic. Eseguilo, collegalo al server SQL e fai clic su Correggi

La vecchia versione collegata qui ha funzionato su SQL Server 2017.

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

Nella mia situazione stavo cercando di utilizzare Integrated Security per connettersi da un PC a SQL Server su un altro PC su una rete senza dominio. Su entrambi i PC, stavo effettuando l'accesso a Windows con lo stesso account Microsoft . Sono passato a un account locale su entrambi i PC e SQL Server ora si connette correttamente.

Nel mio caso, poiché stavo lavorando nel mio ambiente di sviluppo, qualcuno aveva spento il controller di dominio e le credenziali di Windows non potevano essere autenticate. Dopo aver acceso il controller di dominio, l'errore è scomparso e tutto ha funzionato perfettamente.

Un'altra nicchia di questo problema causato dalle connessioni di rete. Mi connetto tramite client Windows VPN e questo problema si è verificato quando sono passato dal Wifi a una connessione cablata. La soluzione per la mia situazione era regolare manualmente la metrica dell'adattatore.

In PowerShell utilizzare Get-NetIPInterface per vedere tutti i valori delle metriche. I numeri più bassi hanno un costo inferiore e quindi sono preferiti da Windows. Ho cambiato Ethernet e VPN e le credenziali sono arrivate dove dovevano essere perché SSMS fosse felice.

Per configurare la funzionalità Metrica automatica: Nel Pannello di controllo, fare doppio clic su Connessioni di rete. Fare clic con il pulsante destro del mouse su un'interfaccia di rete e quindi selezionare Proprietà. Fare clic su Protocollo Internet (TCP / IP), quindi selezionare Proprietà. Nella scheda Generale, seleziona Avanzate. Per specificare una metrica, nella scheda Impostazioni IP, selezionare per deselezionare la casella di controllo Metrica automatica, quindi immettere la metrica desiderata nel campo Metrica interfaccia.

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

Mi sono imbattuto in una variante di questo problema, ecco le caratteristiche:

• L'utente è stato in grado di connettersi correttamente a un'istanza denominata, ad esempio, le connessioni a Server\Instancehanno avuto esito positivo
• L'utente non è stato in grado di connettersi all'istanza predefinita, ad esempio, le connessioni Servernon sono riuscite con lo screenshot dell'OP riguardante SSPI
• L'utente non è riuscito a connettere l'istanza predefinita con un nome completo, ad esempio, connessioni a Server.domain.comnon riuscite (timeout)
• L'utente non è stato in grado di connettersi all'indirizzo IP senza l'istanza denominata, ad esempio, le connessioni a 192.168.1.134non sono riuscite
• Altri utenti non nel dominio (ad esempio, gli utenti che utilizzano VPN alla rete) ma utilizzando le credenziali di dominio sono stati in grado di connettersi con successo all'istanza predefinita e all'indirizzo IP

Quindi, dopo molti grattacapi nel tentativo di capire perché questo singolo utente non è riuscito a connettersi, ecco i passaggi che abbiamo seguito per risolvere la situazione:

1. Dai un'occhiata al server nell'elenco SPN utilizzando
   setspn -l Server
   un file. Nel nostro caso, ha dettoServer.domain.com
2. Aggiungi una voce al file hosts che si trova in C:\Windows\System32\drivers\etc\hosts(esegui Blocco note come amministratore per modificare questo file). La voce che abbiamo aggiunto era
   Server.domain.com Server

Successivamente, siamo stati in grado di connetterci con successo tramite SSMS all'istanza predefinita.

Anch'io ho avuto questo problema su SQL Server 2014 durante la registrazione con l'autenticazione di Windows, per risolvere il problema ho riavviato il mio server una volta e poi ho provato ad accedere, ha funzionato per me.