Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: SQL Server
Numero KB originale: 811889
Riassunto
Questo articolo aiuta a risolvere l'errore "Impossibile generare il contesto SSPI" che si verifica quando si tenta di connettersi a SQL Server usando l'autenticazione di Windows. Questo errore indica in genere che l'interfaccia SSPI (Security Support Provider Interface) non può usare l'autenticazione Kerberos per delegare le credenziali client tramite TCP/IP o named pipe a SQL Server.
In questo articolo verranno fornite informazioni sulle cause comuni degli errori di contesto SSPI, dei nomi delle entità servizio (SPN) e del relativo ruolo nell'autenticazione e su come diagnosticare e correggere l'errore.
Prima di iniziare la risoluzione dei problemi, esaminare i prerequisiti e l'elenco di controllo per la risoluzione dei problemi di connettività di SQL Server.
Sintomi
Quando si usa l'autenticazione di Windows per connettersi a un'istanza di SQL Server in modalità remota, viene visualizzato il messaggio di errore seguente:
"Nome principale di destinazione scorretto. Impossibile generare il contesto SSPI.
Motivo
Questo errore si verifica in genere quando l'autenticazione di Windows non riesce a usare il protocollo Kerberos per delegare le credenziali client e non esegue correttamente il fallback all'autenticazione NTLM. Nella maggior parte dei casi, un nome dell'entità servizio (SPN) non configurato correttamente causa questo errore.
Per altre informazioni su SSPI, Kerberos e SPN, vedere Domande frequenti.
Correggere l'errore con Kerberos Configuration Manager
Note
Questo approccio risolve l'errore quando si ricevono in modo coerente questi messaggi di errore, non in modo intermittente.
Le connessioni Kerberos hanno esito negativo per diversi motivi, 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 controllare le cause dell'errore e fornisce opzioni per risolvere eventuali problemi identificati.
Seguire questa procedura per correggere l'errore usando KCM.
Nel computer in cui si verificano problemi di connettività, scaricare e installare Kerberos Configuration Manager.
Iniziare
KerberosConfigMgr.exedalla%SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Managercartella . Utilizzare quindi un account di dominio con autorizzazioni per connettersi al computer SQL Server a cui non è possibile connettersi.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 tutte le opzioni ad eccezione di SQL Server.
Esaminare la diagnosi dallo strumento usando la colonna Stato e seguire i passaggi pertinenti per risolvere il problema:
Stato Ulteriori informazioni Azione Bene L'elemento selezionato è configurato correttamente. È possibile passare all'elemento successivo nell'output. Nessuna azione necessaria. SPN obbligatorio mancante KCM segnala questo stato quando lo SPN identificato nella colonna SPN richiesto manca per l'account di avvio del 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, il nome SPN richiesto viene aggiunto ad Active Directory.
4. Se l'account di dominio non dispone delle autorizzazioni necessarie per aggiornare Active Directory, usare Genera o Genera tutto per generare lo script che consente all'amministratore di Active Directory di aggiungere i nomi SPN mancanti.
5. Dopo aver aggiunto gli SPN, eseguire nuovamente Kerberos Configuration Manager per verificare che i problemi degli SPN siano risolti.
6. Inoltre, è possibile usare i comandi seguenti:
- UsareSETSPN -Q spnNameper individuare il nome SPN e i relativi account correnti.
- UsareSETSPN -Dper 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.
2. Nel riquadro della console selezionare Protocolli per <il nome> dell'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.
5. Nel riquadro dei dettagli fare clic con il pulsante destro del mouse su SQL Server (<nome> istanza) e quindi scegliere 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 usare Kerberos per connettersi a SQL Server, impostare l'istanza denominata su una porta statica e usare tale porta durante la registrazione dell'SPN. Per configurare l'istanza di SQL Server per utilizzare una porta statica, attenersi alla seguente procedura:
1. In Gestione configurazione SQL Server, nel riquadro della console espandere Configurazione di rete di SQL Server, espandere Protocolli per il nome dell'istanza e quindi fare doppio clic su <.>
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 Questa situazione si verifica quando lo stesso SPN viene registrato con 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 viene 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 gli SPN, eseguire nuovamente il KCM per verificare che i problemi relativi agli SPN siano risolti.Note
Se l'account di dominio che avvia KCM non dispone dei privilegi per modificare i nomi SPN in Active Directory, usare il pulsante Genera o Genera tutto corrispondente nella colonna script SPN per generare i comandi necessari. Collaborare con l'amministratore di Active Directory per risolvere i problemi identificati da KCM.
Dopo aver risolto tutti i problemi identificati da KCM, eseguire di nuovo lo strumento. Assicurarsi che non vengano segnalati altri problemi e quindi ripetere 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:
Controllare la risoluzione dei nomi usando 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. Nel computer client eseguire il comando seguente per ottenere l'indirizzo IP del server che esegue SQL Server (dove il nome del computer è SQLServer1):
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 una diagnostica dettagliata, usare il cmdlet Test-NetConnection o Test-Connection per testare la connettività TCP in base alla versione di PowerShell installata nel computer. Per altre informazioni sui cmdlet di PowerShell, vedere Panoramica dei cmdlet.
Note
I metodi di risoluzione dei nomi possono includere file DNS, WINS, Host e Lmhosts. Per altre informazioni sui problemi di risoluzione dei nomi e sulla risoluzione dei problemi, vedere gli articoli seguenti:
Controllare se sono presenti alias per SQL Server di destinazione in Gestione configurazione SQL Server e nell'utilità Sql Server Client Network. Se tale alias esiste, 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 problema genera credenziali NTLM se l'SPN non viene trovato, oppure si verifica un errore SSPI se inavvertitamente corrisponde all'SPN di un altro server.
Verificare la comunicazione tra domini
Verificare che il dominio a cui si accede possa comunicare con il dominio del server che esegue SQL Server. Il dominio deve anche avere una risoluzione dei nomi corretta.
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 potrebbe verificarsi in una delle situazioni seguenti:
- L'account di dominio è bloccato.
- Non è stato riavviato il servizio SQL Server dopo la modifica della password.
Se il dominio di accesso è diverso dal dominio del server che esegue SQL Server, controllare la relazione di trust tra i domini.
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.
Verificare gli SPN di SQL Server utilizzando gli strumenti SQLCHECK e Setspn
Se è possibile accedere localmente 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 altre informazioni su come usare lo strumento e le informazioni raccolte, vedere la home page dello strumento. È anche possibile controllare la pagina dei prerequisiti e dell'elenco di controllo consigliati. 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.
Usare questo output per determinare i passaggi successivi (vedere gli esempi seguenti) e usare lo strumento Setspn per eseguire le azioni correttive necessarie per risolvere i problemi di SPN.
| Scenario | Azione suggerita |
|---|---|
| SPN non esiste | Aggiungi i nomi SPN richiesti per l'account del servizio SQL Server. |
| SPN duplicati | Eliminare il nome SPN registrato per il servizio SQL con l'account non corretto. |
| SPN con account non corretto | Eliminare il nome SPN registrato per il servizio SQL con l'account non corretto e quindi registrare il nome SPN nell'account del servizio corretto. |
| SPN non corretto è registrato | Eliminare il nome SPN non corretto e registrare il nome SPN corretto. |
Note
È possibile esaminare la sezione Informazioni di SQL Server del file di output dello strumento SQLCHECK per trovare l'account del servizio dell'istanza di SQL Server.
Setspn è uno strumento predefinito nelle versioni più recenti di Windows che consente di leggere, aggiungere, modificare o eliminare nomi SPN in Active Directory. È possibile usare questo strumento per verificare che i nomi SPN di SQL Server siano configurati in base alla registrazione di un nome dell'entità servizio per le connessioni Kerberos. Per altre informazioni, vedere Strumento Setspn ed esempi di come usarlo.
Per ulteriori informazioni sugli scenari in cui SQL Server registra automaticamente gli SPN e dove è necessaria la registrazione manuale degli SPN, vedere Registrare un Nome principale del servizio per le connessioni Kerberos.
Controllare i permessi per l'account di avvio di SQL Server sul server collegato
Se si usa Impersonate come opzione di autenticazione nella pagina Sicurezza del server collegato, SQL Server deve passare le credenziali in ingresso a SQL Server remoto. L'account di avvio di SQL Server in cui si definisce il server collegato deve avere l'attributo 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.
Note
Questo passaggio è necessario solo quando si risolvono i problemi relativi alle query del server collegato.
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 per un'istanza del servizio. L'autenticazione Kerberos usa gli SPN 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 risiede SQL Server, usa sempre NTLM.
Perché la connessione non commuta su NTLM dopo aver incontrato problemi con Kerberos?
Quando il driver usa l'autenticazione di Windows per connettersi a SQL Server, il codice del driver di SQL Server nel client usa 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 si usa la sicurezza integrata, il driver tenta di risolvere il DNS completo del server anche se si passa un indirizzo IP o un nome host come nome del server.
Quando il driver di SQL Server nel client risolve il DNS completamente qualificato del server, utilizza il DNS corrispondente per formare il nome di servizio SPN (Service Principal Name) per il server. Pertanto, se WinSock non riesce a risolvere l'indirizzo IP o il nome host in un DNS completo, il driver di SQL Server potrebbe creare un nome SPN non valido per il server.
Ad esempio, il driver SQL Server sul lato client può usare un DNS completo per risolvere i nomi SPN non validi come indicato di seguito:
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/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 questo punto, il livello SSPI passa alla modalità di autenticazione NTLM e l'accesso usa l'autenticazione NTLM e in genere 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 altre informazioni, vedere Come determinare se il tipo di autenticazione è Kerberos.
Come si creano gli SPN per SQL Server?
Quando viene avviata un'istanza del motore di database di SQL Server, SQL Server tenta di registrare automaticamente il nome SPN per il servizio SQL Server usando 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, l'amministratore di Active Directory deve registrare manualmente il nome SPN corretto usando Microsoft Kerberos Manager per SQL Server o 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.