Errore "Impossibile generare il contesto SSPI" quando si usa l'autenticazione di Windows per connettersi a SQL Server

Si applica a: SQL Server
Numero della Knowledge Base originale: 811889

Quando si usa l'autenticazione di Windows per connettere un'istanza di SQL Server in remoto, viene visualizzato il seguente messaggio di errore:

"Nome principale di destinazione scorretto. Impossibile generare il contesto SSPI."

Domande frequenti

Che cos'è SSPI?

Security Support Provider Interface (SSPI) è un set di API di Windows che consente la delega e l'autenticazione reciproca su qualsiasi livello di trasporto dati generico, ad esempio i socket TCP/IP. Uno o più moduli software forniscono le funzionalità di autenticazione effettive. Ogni modulo è denominato provider di supporto di sicurezza (SSP) e viene implementato come Libreria di collegamento dinamico (DLL).

Che cos'è Kerberos?

Il protocollo Kerberos v5 è un pacchetto di sicurezza standard del settore ed è uno dei tre pacchetti di sicurezza presenti nei sistemi operativi Windows. Per maggiori informazioni, consultare Security Support Providers (SSP).

Che cosa significa l'errore "Impossibile generare contesto SSPI"?

Questo errore indica che SSPI tenta ma non può utilizzare l'autenticazione Kerberos per delegare le credenziali client tramite TCP/IP o Named Pipes a SQL Server. Nella maggior parte dei casi, un nome dell'entità servizio (SPN) non configurato correttamente causa questo errore.

Che cos'è SPN?

Un nome dell'entità servizio (SPN) è un identificatore univoco di un'istanza del servizio. I nomi SPN vengono utilizzati dall'autenticazione Kerberos per associare un'istanza del servizio a un account di accesso al servizio. Questo processo di associazione consente a un'applicazione client di richiedere al servizio di autenticare un account anche se il client non dispone di un nome account.

Ad esempio, un nome SPN tipico per un server che esegue un'istanza di SQL Server è il seguente:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Il formato di un nome SPN per un'istanza predefinita è lo stesso di un nome SPN per un'istanza denominata. Il numero di porta è ciò che collega il nome SPN a una particolare istanza. Per maggiori informazioni sulla registrazione dei nomi SPN del servizio SQL Server, consultare Registrare un nome dell'entità servizio per le connessioni Kerberos.

Perché SSPI utilizza l'autenticazione NTLM o Kerberos?

L'autenticazione di Windows è il metodo preferito per l'autenticazione degli utenti a SQL Server. I client che utilizzano l'autenticazione di Windows vengono autenticati tramite NTLM o Kerberos.

Quando un client SQL Server utilizza la sicurezza integrata tramite socket TCP/IP a un server remoto che esegue SQL Server, la libreria di rete client di SQL Server utilizza l'API SSPI per eseguire la delega di sicurezza. Il client di rete SQL Server effettua una chiamata alla funzione AcquireCredentialsHandle e passa in "negotiate" per il parametro pszPackage. Questo processo notifica al provider di sicurezza sottostante di negoziare la delega. In questo contesto, "negotiate" significa provare l'autenticazione Kerberos o NTLM nei computer basati su Windows. In altre parole, Windows utilizza la delega Kerberos se il computer di destinazione che esegue SQL Server ha un SPN associato e configurato correttamente. In caso contrario, Windows utilizza la delega NTLM. Se il client SQL Server si connette localmente nello stesso computer in cui si trova SQL Server, viene sempre utilizzato NTLM.

Perché la connessione non esegue il failover a NTLM dopo problemi con Kerberos?

Quando il driver utilizza l'autenticazione di Windows per connettersi a SQL Server, il codice del driver SQL Server nel client utilizza l'API di rete WinSock per risolvere il DNS completo del server. Per eseguire questa operazione, il codice del driver chiama le API WinSock gethostbyname e gethostbyaddr. Se viene utilizzata la sicurezza integrata, il driver tenterà di risolvere il DNS completo del server anche se viene passato un indirizzo IP o un nome host come nome del server.

Quando il driver SQL Server nel client risolve il DNS completo del server, il DNS corrispondente viene utilizzato per formare il nome SPN per il server. Pertanto, i problemi di risoluzione dell'indirizzo IP o del nome host in un DNS completo di WinSock possono causare la creazione di un nome SPN non valido per il server da parte del driver SQL Server.

Ad esempio, il driver SQL Server lato client può essere utilizzato come DNS completo per risolvere nomi SPN non validi come indicato di seguito:

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Quando il driver SQL Server forma un nome SPN non valido, l'autenticazione funziona ancora perché l'interfaccia SSPI tenta di cercare il nome SPN nel servizio di Active Directory. Se l'interfaccia SSPI non trova il nome SPN, l'autenticazione Kerberos non viene eseguita. A quel punto, il livello SSPI passa alla modalità di autenticazione NTLM e l'accesso utilizza l'autenticazione NTLM e, generalmente, ha esito positivo. Se il driver SQL Server genera un nome SPN valido non assegnato al contenitore appropriato, il driver prova il nome SPN ma non può utilizzarlo. In questo caso, potrebbe verificarsi un errore "Impossibile generare il contesto SSPI". Se l'account di avvio di SQL Server è un account di sistema locale, il contenitore appropriato è il nome del computer. Per qualsiasi altro account, il contenitore appropriato è l'account di avvio di SQL Server. Poiché l'autenticazione utilizza il primo nome SPN individuato, assicurarsi che nessun nome SPN sia assegnato a contenitori non corretti. In altre parole, ogni SPN deve essere assegnato solo a un contenitore.

Come è possibile verificare il metodo di autenticazione della connessione?

Per determinare il metodo di autenticazione di una connessione, eseguire la query seguente:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Per maggiori informazioni, consultare Determinare se si è connessi a SQL Server tramite l'autenticazione Kerberos.

Come creare nomi SPN per SQL Server?

All'avvio di un'istanza del motore di database SQL Server, SQL Server tenta di registrare automaticamente il nome SPN per il servizio SQL Server utilizzando l'API DsWriteAccountSpn. Questa chiamata ha esito positivo se l'account del servizio SQL Server dispone dei diritti di lettura servicePrincipalName e scrittura servicePrincipalName in Active Directory. In caso contrario, sarà necessario che l'amministratore di Active Directory registri manualmente il nome SPN corretto utilizzando Microsoft Kerberos Manager per SQL Server oppure lo strumento Setspn predefinito. Per maggiori informazioni sulla gestione dei nomi SPN per SQL Server, consultare Registrare un nome dell'entità servizio per le connessioni Kerberos.

Correggere l'errore con Kerberos Configuration Manager (scelta consigliata)

Esistono vari motivi per cui le connessioni Kerberos hanno esito negativo, ad esempio nomi SPN non configurati correttamente, problemi di risoluzione dei nomi o diritti insufficienti per gli account di avvio del servizio SQL Server. Microsoft Kerberos Configuration Manager (KCM) è uno strumento che consente di verificare le cause dell'errore. Lo strumento KCM offre anche opzioni per risolvere eventuali problemi identificati nel processo.

Per risolvere gli errori di utilizzo dello strumento KCM, attenersi alla seguente procedura.

1. Nel computer in cui si verificano i problemi di connettività, scaricare e installare Kerberos Configuration Manager.

2. Avviare KerberosConfigMgr.exe dalla cartella %SystemDrive%:\Programmi\Microsoft\Kerberos Configuration Manager. Utilizzare quindi un account di dominio con autorizzazioni per connettersi al computer SQL Server a cui non è possibile connettersi.

3. Se si esegue lo strumento KCM nel computer SQL Server, selezionare Connetti, lasciando vuoto il nome del server e gli altri dettagli applicabili allo scenario. Selezionare Connetti per eseguire l'analisi. Al termine del recupero delle informazioni necessarie, lo strumento KCM passa automaticamente alla scheda SPN e, per impostazione predefinita, visualizza le informazioni per SQL Server, SQL Server Reporting Services, Analysis Services e AG Listeners. Per risolvere questo errore, deselezionare tutti gli elementi tranne SQL Server.

4. Esaminare la diagnosi dallo strumento utilizzando la colonna Stato e attenersi alla procedura pertinente per risolvere il problema:

   Stato	Altre informazioni	Azione
   Buone	L'elemento selezionato è configurato correttamente. È possibile passare all'elemento successivo nell'output.	Nessuna azione necessaria.
   SPN obbligatorio mancante	Questo stato viene segnalato quando il nome SPN identificato nella colonna SPN obbligatorio non è presente per l'account di avvio SQL Server in Active Directory.	1. Selezionare Correzione per esaminare le informazioni nella finestra di dialogo Avviso. 2. Selezionare Sì per aggiungere il nome SPN mancante ad Active Directory. 3. Se l'account di dominio dispone delle autorizzazioni necessarie per aggiornare Active Directory, l'SPN richiesto verrà aggiunto ad Active Directory. 4. Se il tuo account di dominio non dispone delle autorizzazioni necessarie per aggiornare Active Directory, utilizza Generate o Generate All per generare lo script che consentirà all'amministratore di Active Directory di aggiungere le SPN. 5. Dopo aver aggiunto i nomi SPN, eseguire di nuovo Kerberos Configuration Manager per verificare che i problemi del nome SPN siano stati risolti. 6. Inoltre, è possibile usare i comandi seguenti: - Consente SETSPN -Q spnName di individuare l'SPN e i relativi account correnti. - Usare SETSPN -D per rimuovere il nome SPN dall'account non corretto.
   Per utilizzare la configurazione Kerberos, è necessario utilizzare TCP	Ciò si verifica quando TCP non è abilitato nel computer client.	Per abilitare il protocollo TCP/IP per l'istanza di SQL Server, attenersi alla seguente procedura: 1. Nel riquadro della console di Gestione configurazione SQL Server espandere Configurazione di rete di SQL Server. Nel riquadro console, selezionare Protocolli per <nome istanza>. 3. Nel riquadro dei dettagli, fare clic con il pulsante destro del mouse su TCO/IP e selezionare Elimina. 4. Nel riquadro della console, selezionare Servizi SQL Server. Nel riquadro dettagli, fare clic con il pulsante destro del mouse su SQL Server (<nome istanza>), quindi selezionare Riavvia per arrestare e riavviare il servizio SQL Server. Per maggiori informazioni, consultare Abilitare o disabilitare un protocollo di rete del server.
   Porta dinamica	Questo messaggio viene visualizzato per le istanze denominate che utilizzano porte dinamiche (configurazione predefinita). Negli ambienti in cui è necessario utilizzare Kerberos per connettersi a SQL Server, è necessario impostare l'istanza denominata su una porta statica e utilizzare tale porta durante la registrazione del nome SPN.	Per configurare l'istanza di SQL Server per utilizzare una porta statica, attenersi alla seguente procedura: In Gestione configurazione SQL Server, nel riquadro console, espandere Configurazione di rete di SQL Server, espandere Protocolli per <nome istanza>, quindi fare doppio clic su TCP/IP. 2. Nella finestra di dialogo Proprietà TCP/IP, esaminare l'impostazione Ascolta tutto nella scheda Protocollo. 3. Se l'impostazione Ascolta tutto è impostata su Sì, passare alla scheda Indirizzi IP e scorrere fino alla fine di Windows per trovare l'impostazione IPAll. Eliminare il valore corrente contenuto nelle porte dinamiche TCP e impostare il valore desiderato nel campo Porta TCP. Selezionare OK e riavviare l'istanza di SQL Server per rendere effettive le impostazioni. 4. Se l'impostazione Ascolta tutto è impostata su No, passare alla scheda Indirizzi IP e controllare ogni indirizzo IP visualizzati in IP1, IP2. Per gli indirizzi IP abilitati, rimuovere il valore corrente contenuto nel campo Porte dinamiche TCP e impostare il valore desiderato nel campo Porta TCP. Selezionare OK e riavviare l'istanza di SQL Server per rendere effettive le impostazioni. Per maggiori informazioni, consultare Configurare un server per l'ascolto su una porta TCP specifica.
   SPN duplicato	È possibile riscontrare la situazione in cui lo stesso SPN è registrato in account diversi in Active Directory.	1. Selezionare il pulsante Correzione, visualizzare le informazioni nella finestra di dialogo Avviso e selezionare Sì se è possibile aggiungere il nome SPN mancante ad Active Directory. 2. Se l'account di dominio dispone delle autorizzazioni necessarie per aggiornare Active Directory, il nome SPN non corretto verrà eliminato. 3. Se l'account di dominio non dispone delle autorizzazioni necessarie per aggiornare Active Directory, utilizzare il pulsante Genera o Genera tutto per generare lo script necessario che è possibile consegnare l'amministratore di Active Directory per rimuovere i nomi SPN duplicati. Dopo aver rimosso i nomi SPN, eseguire di nuovo lo strumento KCM per verificare che i problemi del nome SPN siano stati risolti.

   Nota

   Se l'account di dominio che avvia lo strumento KCM non dispone di privilegi per modificare i nomi SPN in Active Directory, è possibile utilizzare il pulsante Genera o Genera tutto corrispondente nella colonna script SPN per generare i comandi necessari e collaborare con l'amministratore di Active Directory per risolvere i problemi identificati dallo strumento KCM.

5. Dopo aver risolto tutti i problemi identificati dallo strumento KCM, eseguirlo di nuovo. Assicurarsi che non vengano segnalati altri problemi e quindi ritentare la connessione. Se lo strumento segnala ancora problemi, ripetere la procedura precedente.

Correggere l'errore senza Kerberos Configuration Manager

Se non è possibile utilizzare lo strumento KCM, attenersi alla seguente procedura:

Passaggio 1: controllare la risoluzione dei nomi con il comando ping

Il fattore essenziale che consente di eseguire correttamente l'autenticazione Kerberos è la funzionalità DNS valida nella rete. È possibile verificare questa funzionalità nel client e nel server utilizzando l'utilità del prompt dei comandi Ping. Per ottenere l'indirizzo IP del server che esegue SQL Server, nel computer client (in cui il nome del computer è SQLServer1), eseguire il seguente comando:

ping sqlserver1

Per verificare se l'utilità Ping risolve il DNS completo di SQLServer1, eseguire il comando seguente:

ping -a <IPAddress>

Ad esempio:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Quando il comando ping -a <IPAddress> viene risolto nel DNS completo corretto del computer che esegue SQL Server, anche la risoluzione sul lato client ha esito positivo.

Per la diagnostica dettagliata, utilizzare il cmdlet Test-NetConnection o Test-Connection per testare la connettività TCP in base alla versione di PowerShell installata sul computer. Per maggiori informazioni su questo cmdlet, consultare la sezione Panoramica del cmdlet.

Verificare se sono presenti alias per il SQL Server di destinazione in Gestione configurazione di SQL Server e nell'utilità rete client di SQL Server. Se esiste un alias di questo tipo, assicurarsi che sia configurato correttamente controllando i nomi dei server, il protocollo di rete, il numero di porta e così via. Un alias di SQL Server potrebbe causare la generazione di un nome SPN imprevisto. Questo genererà credenziali NTLM se il nome SPN non viene trovato o un errore SSPI, se corrisponde inavvertitamente al nome SPN di un altro server.

Passaggio 2: Verificare la comunicazione tra domini

Verificare che il dominio a cui si accede possa comunicare con il dominio del server che esegue SQL Server. Nel dominio deve essere presente anche la risoluzione dei nomi corretta.

1. Assicurarsi di poter accedere a Windows utilizzando lo stesso account di dominio e la stessa password dell'account di avvio del servizio SQL Server. Ad esempio, l'errore SSPI può verificarsi in una delle situazioni seguenti:

   • L'account di dominio è bloccato.
   • Dopo la modifica della password dell'account, non è stato riavviato il servizio SQL Server.

2. Se il dominio di accesso è diverso dal dominio del server che esegue SQL Server, controllare la relazione di trust tra i domini.

3. Controllare se il dominio a cui appartiene il server e l'account di dominio utilizzato per connettersi si trovano nella stessa foresta. Questo passaggio è necessario per il funzionamento di SSPI.

Passaggio 3: Verificare SQL Server nomi SPN usando gli strumenti SQLCHECK e Setspn

Se è possibile accedere in locale al computer SQL Server e avere accesso come amministratore, usare SQLCHECK. SQLCheck fornisce la maggior parte delle informazioni necessarie per la risoluzione dei problemi in un unico file. Per maggiori informazioni su come utilizzare questo strumento e quali informazioni raccoglie, consultare la home page dello strumento. È anche possibile controllare i prerequisiti consigliati e la pagina dell'elenco di controllo. Dopo aver generato il file di output, esaminare la configurazione SPN per l'istanza di SQL Server nella sezione Informazioni su SQL Server del file di output.

Output di esempio:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Utilizzare l'output precedente per determinare le procedure successive (vedi gli esempi seguenti) e lo strumento Setspn per eseguire le azioni correttive necessarie per risolvere i problemi del nome SPN.

Passaggio 4: controllare l'autorizzazione dell'account di avvio di SQL Server nel server collegato

Se si utilizza Rappresenta come opzione di autenticazione nella pagina Sicurezza del server collegato, SQL Server è necessario passare le credenziali in ingresso a SQL Server in remoto. L'account di avvio di SQL Server in cui è definito il server collegato deve avere l'account considerato attendibile per la delega assegnato in Active Directory. Per maggiori informazioni, consultare Abilitare gli account computer e utente come attendibili per la delega.

Vedere anche

• Risolvere i problemi di connettività in SQL Server
• Risolvere i problemi di autenticazione coerenti
• Strumento client SSPI
• Abilitare la registrazione eventi in Kerberos
• Come forzare Kerberos a utilizzare TCP anziché UDP in Windows