Risoluzione del messaggio di errore "Impossibile generare il contesto SSPI"

Traduzione articoli Traduzione articoli
Identificativo articolo: 811889 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo viene descritta la procedura dettagliata di risoluzione delle cause pi¨ comuni che possono portare alla generazione dell'errore "Impossibile generare il contesto SSPI". Questo messaggio di errore pu˛ essere visualizzato nelle seguenti circostanze:
  • Si sta stabilendo una connessione a SQL Server.
  • Si sta utilizzando la protezione integrata.
  • Viene utilizzato Kerberos per effettuare una delega di protezione.

Terminologia Kerberos e nome dell'entitÓ servizio

Il driver di SQL Server presente su un computer client si avvale della protezione integrata per utilizzare il token di protezione di Windows dell'account utente per connettersi a un computer che esegue SQL Server. Il token di protezione di Windows viene delegato dal client al computer che esegue SQL Server. Tale delega viene effettuata dal driver di SQL Server quando il token di protezione dell'utente viene delegato da un computer a un altro utilizzando una delle seguenti configurazioni:
  • NTLM su Named Pipe (non viene utilizzato SSPI)
  • NTLM su socket TCP/IP con SSPI
  • Kerberos su socket TCP/IP con SSPI
Security Support Provider Interface (SSPI) Ŕ un insieme di API di Windows che consentono la delega e l'autenticazione reciproca su un livello di trasposto dati generico, quale ad esempio i socket TCP/IP. Pertanto, SSPI permette a un computer che esegue un sistema operativo Windows di delegare in maniera sicura un token di protezione utente da un computer a un altro utilizzando qualsiasi livello di trasporto in grado di trasmettere byte di dati non elaborati.

Il messaggio di errore "Impossibile generare il contesto SSPI" viene generato quando SSPI utilizza Kerberos per la delega su TCP/IP e Kerberos non Ŕ in grado di completare le operazioni necessarie per delegare correttamente il token di protezione al computer di destinazione che esegue SQL Server.

Motivi della scelta di NTLM o Kerberos nell'interfaccia SSPI

Kerberos utilizza un identificatore detto nome dell'entitÓ servizio (SPN, Service Principal Name). Un SPN pu˛ essere considerato come un identificatore univoco a livello di dominio o di insieme di strutture di un'istanza in una risorsa del server di rete. Pu˛ esistere un SPN per un servizio Web, per un servizio SQL o per un servizio SMTP. ╚ anche possibile avere pi¨ istanze di servizi Web sullo stesso computer fisico identificato da un SPN univoco.

L'SPN per SQL Server Ŕ composto dai seguenti elementi:
  • Classe di servizio: Identifica la classe generale del servizio. ╚ sempre MSSQLSvc nel caso di SQL Server.
  • Host: Nome completo di dominio DNS del computer che esegue SQL Server.
  • Porta: Numero di porta su cui il servizio Ŕ in ascolto.
Di seguito Ŕ riportato un tipico esempio di SPN per un computer che esegue SQL Server:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Il formato di un SPN per un'istanza predefinita e quello di un SPN per un'istanza denominata non sono diversi. Il numero di porta Ŕ l'elemento che associa l'SPN a una determinata istanza.

Quando il driver di SQL Server presente su un client utilizza la protezione integrata per connettersi a SQL Server, il codice del driver tenta di risolvere il nome completo DNS del computer che esegue SQL Server utilizzando le API di rete WinSock. Per effettuare questa operazione, il codice del driver chiama le API WinSock gethostbyname e gethostbyaddr. Anche se un indirizzo IP o un nome host viene passato come nome del computer che esegue SQL Server, il driver di SQL Server tenta di risolvere comunque il nome completo DNS del computer se questo utilizza la protezione integrata.

Quando il driver di SQL Server presente sul client risolve il nome completo DNS del computer che esegue SQL Server, viene utilizzato il corrispondente DNS per formare l'SPN per tale computer. Pertanto, qualsiasi problema relativo al modo in cui l'indirizzo IP o il nome host viene risolto nel nome completo DNS da WinSock pu˛ indurre il driver di SQL Server a creare un SPN non valido per il computer SQL Server.

Ad esempio, SPN non validi che possono essere creati dal driver di SQL Server del lato client come risultato della risoluzione di nomi completi DNS possono essere:
  • 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 di SQL Server crea un SPN non valido, l'autenticazione pu˛ comunque funzionare in quanto l'interfaccia SSPI ricerca l'SPN nel servizio Active Directory senza trovarlo. Se l'SPN non viene trovato, non viene eseguita alcuna autenticazione Kerberos. A questo punto, il livello SSPI passa alla modalitÓ di autenticazione NTLM e, utilizzando questa autenticazione, l'accesso ha in genere esito positivo. Se il driver di SQL Server crea un SPN valido ma questo non viene assegnato al contenitore appropriato, sarÓ impossibile utilizzare l'SPN e verrÓ generato un messaggio di 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 tutti gli altri account, il contenitore appropriato Ŕ l'account di avvio di SQL Server. PoichÚ la procedura di autenticazione prevede l'utilizzo del primo SPN individuato, accertarsi che non esistano SPN assegnati a contenitori non appropriati. In altre parole, ogni SPN deve essere assegnato a un solo contenitore.

L'elemento essenziale perchÚ l'autenticazione Kerberos riesca Ŕ che la funzionalitÓ DNS sulla rete sia valida. ╚ possibile verificare questa funzionalitÓ sul client e sul server utilizzando l'utilitÓ della riga di comando Ping. Sul computer client eseguire il comando riportato di seguito per ottenere l'indirizzo IP del server che esegue SQL Server (dove il nome del computer che esegue SQL Server Ŕ SQLServer1):
ping sqlserver1
Per verificare se l'utilitÓ Ping ha risolto il nome completo DNS di SQLServer1, eseguire il comando seguente:
ping -a indirizzo IP
Ad esempio:
C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] con 32 byte di dati:
	
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
	
Statistiche di ping per 123.123.123.123: 
    Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi: 
    Minimo = 0ms, Massimo = 0ms, Medio = 0ms
C:\>ping -a 123.123.123.123
	
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] con 32 byte di dati:
	
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Risposta da 123.123.123.123: byte=32 durata<10ms TTL=128
Statistiche di ping per 123.123.123.123: 
    Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi: 
    Minimo = 0ms, Massimo = 0ms, Medio = 0ms

C:\>
Quando il comando ping -a IndirizzoIP viene risolto nel nome completo DNS corretto del computer che esegue SQL Server, significa che anche la risoluzione sul lato client avrÓ esito positivo.

Creazione del nome dell'entitÓ servizio per SQL Server

Questa Ŕ una delle fasi critiche dell'interazione tra Kerberos e SQL Server. Con SQL Server il servizio SQL Server pu˛ essere eseguito a fronte di uno dei seguenti account: un account LocalSystem, un account utente locale o un account utente di dominio. Quando l'istanza del servizio SQL Server viene avviata, tenta di registrare il proprio SPN in Active Directory utilizzando la chiamata all'API DsWriteAccountSpn. Se la chiamata non ha esito positivo, nel Visualizzatore eventi viene registrato il seguente avviso:

Origine: MSSQLServer ID evento: 19011 Descrizione: SuperSocket info: (SpnRegister) : Errore 8344.

Per ulteriori informazioni sulla funzione DsWriteAccountSpn, visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
http://msdn2.microsoft.com/en-us/library/ms676056.aspx

Spiegazione semplificata

Se il servizio SQL Server viene eseguito con l'account LocalSystem, SPN viene registrato automaticamente e Kerberos pu˛ interagire correttamente con il computer che esegue SQL Server. Se invece il servizio SQL Server viene eseguito con un account di dominio o un account locale, nella maggior parte dei casi il tentativo di creare l'SPN non ha esito positivo in quanto l'account di dominio e l'account locale non dispongono dei diritti per impostare i propri SPN. Quando la creazione dell'SPN non riesce, significa che non Ŕ stato configurato alcun SPN per il computer che esegue SQL Server. Se si fanno delle prove utilizzando un account di amministratore di dominio per eseguire il servizio SQL Server, l'SPN verrÓ creato correttamente in quanto le credenziali a livello di amministratore di dominio necessarie per creare un SPN sono presenti.

Se non viene utilizzato un account di amministratore di dominio per eseguire il servizio SQL Server, ad esempio per evitare rischi di protezione, il computer che esegue SQL Server non potrÓ creare il proprio SPN. SarÓ pertanto necessario creare manualmente un SPN per il computer che esegue SQL Server se si desidera utilizzare Kerberos al momento della connessione con un computer che esegue SQL Server. Questa situazione si verifica se si esegue SQL Server in un account utente di dominio o in un account utente locale. L'SPN creato deve essere assegnato all'account del servizio SQL Server presente nel computer in questione. L'SPN non pu˛ essere assegnato al contenitore computer a meno che il computer che esegue SQL Server non venga avviato con il sistema locale. Deve essere presente soltanto un SPN, che deve essere assegnato al contenitore appropriato. In genere, si tratta dell'account del servizio SQL Server corrente. Questo Ŕ tuttavia l'account del computer con sistema locale.

Verifica del dominio

Verificare che il dominio a cui ci si connette sia in grado di comunicare con il dominio a cui appartiene il computer che esegue SQL Server. Nel dominio anche la risoluzione dei nomi deve funzionare correttamente.
  1. Se il dominio di accesso Ŕ lo stesso del computer SQL Server, utilizzare l'autenticazione di Windows per accedere a SQL Server. Se l'autenticazione non riesce, significa che esiste un problema di account di Windows o di account di dominio che deve essere risolto. In tal caso, contattare l'amministrazione della protezione o l'amministratore del dominio affinchÚ verifichi se l'account di Windows o di dominio dispone delle autorizzazioni appropriate.
  2. Se il dominio di accesso Ŕ diverso dal dominio a cui appartiene il computer SQL Server, verificare la relazione di trust esistente tra i due domini.
  3. Verificare se il dominio a cui appartiene il server e l'account di dominio utilizzato per la connessione appartengono allo stesso insieme di strutture. Si tratta infatti di una condizione essenziale per il corretto funzionamento di SSPI.
  4. Utilizzare l'opzione L'account Ŕ trusted per delega in Utenti e computer di Active Directory all'avvio di SQL Server.
  5. Utilizzare l'utilitÓ Manipulate Service Principal Names for Accounts (SetSPN.exe) disponibile nel Resource Kit di Windows 2000. Gli account di amministratore di dominio Windows 2000 o Windows 2003 possono utilizzare tale utilitÓ per controllare l'SPN assegnato a un servizio e a un account. Nel caso di SQL Server, deve essere presente soltanto un SPN. L'SPN deve essere assegnato al contenitore appropriato che, nella maggior parte dei casi, Ŕ l'account del servizio SQL Server corrente, mentre Ŕ l'account del computer nel caso in cui SQL Server venga avviato con l'account di sistema locale. Se SQL Server viene avviato mentre si Ŕ connessi mediante un account LocalSystem, l'SPN verrÓ configurato automaticamente. Se invece si utilizza un account di dominio per avviare SQL Server o tutte le volte che si cambia l'account utilizzato per avviare SQL Server, sarÓ necessario eseguire SetSPN.exe per rimuovere gli SPN scaduti e successivamente sarÓ necessario aggiungere un SPN valido. Per ulteriori informazioni, vedere l'argomento dedicato alla delega degli account di protezione nella documentazione in linea di SQL Server 2000. A questo scopo visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
    http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx
    Per ulteriori informazioni sui Resource Kit di Windows 2000, visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true
  6. Verificare che la risoluzione dei nomi funzioni correttamente. I metodi di risoluzione dei nomi possono includere DNS, WINS, file HOSTS e LMHOSTS. Per ulteriori informazioni sulla risoluzione dei problemi relativi alla risoluzione dei nomi, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito (il contenuto potrebbe essere in inglese):
    169790 Risoluzione dei problemi di base del protocollo TCP/IP
  7. Per ulteriori informazioni sulla risoluzione dei problemi relativi all'accesso e ai firewall in Active Directory, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:
    291382 Domande frequenti sul servizio DNS di Windows 2000
    224196 Limitazione del traffico di replica di Active Directory a una porta specifica

Configurazione del servizio SQL Server per la creazione dinamica di SPN per le istanze di SQL Server

Per configurare il servizio SQL Server in modo che gli SPN vengano creati dinamicamente, Ŕ necessario modificare le impostazioni di controllo di accesso dell'account nel servizio directory Active Directory, concedendo all'account del servizio SQL Server l'autorizzazione di lettura e di scrittura per servicePrincipalName.

Avviso Se si utilizza lo snap-in Active Directory Service Interfaces (ADSI) Edit, l'utilitÓ LDP o qualsiasi altro client LDAP versione 3 e si modificano in modo errato gli attributi degli oggetti di Active Directory potrebbero insorgere gravi problemi che possono richiedere la reinstallazione di Microsoft Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server o di Windows ed Exchange. Microsoft non garantisce che i problemi causati dall'errata modifica degli attributi di oggetti di Active Directory possano essere risolti. La modifica di tali attributi Ŕ a rischio e pericolo dell'utente.

Nota Per concedere le autorizzazioni e i diritti utente corretti all'account di avvio di SQL Server, Ŕ necessario accedere al sistema come amministratore del dominio o chiedere all'amministratore del dominio di eseguire questa operazione.

Per configurare il servizio SQL Server in modo che gli SPN vengano creati dinamicamente, attenersi alla seguente procedura:
  1. Fare clic sul pulsante Start, scegliere Esegui, digitare Adsiedit.msc, quindi scegliere OK.
  2. Nello snap-in ADSI Edit espandere Dominio [Nomedominio], espandere DC= Nomedominioradice, espandere CN=Users, fare clic con il pulsante destro del mouse su CN= Nomeaccount, quindi scegliere ProprietÓ.

    Note
    • Nomedominio Ŕ il segnaposto del nome del dominio.
    • Nomedominioradice Ŕ il segnaposto del nome del dominio radice.
    • Nomeaccount Ŕ il segnaposto dell'account specificato per l'avvio del servizio SQL Server.
    • Se si specifica l'account di sistema locale per l'avvio del servizio SQL Server, Nomeaccount Ŕ il segnaposto dell'account utilizzato per accedere a Microsoft Windows.
    • Se si specifica un account utente di dominio per l'avvio del servizio SQL Server, Nomeaccount Ŕ il segnaposto dell'account utente di dominio.
  3. Nella finestra di dialogo delle proprietÓ di CN= Nomeaccount scegliere la scheda Protezione.
  4. Nella scheda Protezione fare clic su Avanzate.
  5. Nella finestra di dialogo Impostazioni di protezione avanzate assicurarsi che in Autorizzazioni sia elencato SELF.

    Incaso contrario scegliere Aggiungi, quindi aggiungere SELF.
  6. In Autorizzazioni fare clic su SELF, quindi scegliere Modifica.
  7. Nella finestra di dialogo Voce di autorizzazione scegliere la scheda ProprietÓ.
  8. Nella scheda ProprietÓ fare clic su Solo l'oggetto specificato nell'elenco Applica a, quindi assicurarsi che in Autorizzazioni siano selezionate le caselle di controllo per le seguenti autorizzazioni:
    • Lettura servicePrincipalName
    • Scrittura servicePrincipalName
  9. Scegliere OK tre volte, quindi chiudere lo snap-in ADSI Edit.
Per informazioni utili per l'esecuzione di questo processo, contattare il servizio di supporto tecnico Microsoft per Active Directory e fare riferimento a questo articolo della Microsoft Knowledge Base.

Verifica dell'ambiente server

Verificare alcune impostazioni di base del computer su cui Ŕ installato SQL Server:
  1. Kerberos non Ŕ supportato nei computer basati su Windows 2000 che eseguono il Servizio cluster di Windows, a meno che non sia stato applicato il Service Pack 3 o versione successiva per Windows 2000. Pertanto, qualsiasi tentativo di utilizzare l'autenticazione SSPI in un'istanza di cluster di SQL Server potrebbe non avere esito favorevole. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    235529 Informazioni sul supporto di Kerberos in cluster di server basati su Windows 2000
  2. Verificare che nel server sia installato Windows 2000 Service Pack 1 (SP1). Per ulteriori informazioni sul supporto di Kerberos in server basati su Windows 2000, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    267588 Messaggio di errore "Impossibile generare il contesto SSPI" alla connessione a SQL Server 2000
  3. In un cluster, se cambia l'account utilizzato per avviare SQL Server, l'Agente SQL Server o servizi di ricerca globale, ad esempio viene impostata una nuova password, attenersi alla procedura descritta nel seguente articolo della Microsoft Knowledge Base:
    239885 INF: come modificare gli account di servizio su un server virtuale SQL
  4. Verificare che l'account utilizzato per avviare SQL Server disponga delle autorizzazioni appropriate. Se si utilizza un account che non Ŕ un membro del gruppo degli amministratori locali, vedere l'argomento relativo all'impostazione di account di servizio di Windows nella documentazione in linea di SQL Server, in cui Ŕ riportato un elenco dettagliato delle autorizzazioni richieste da questo account (informazioni in lingua inglese):
    http://msdn2.microsoft.com/en-us/library/aa176564(SQL.80).aspx

Verifica dell'ambiente client

Verificare i seguenti aspetti del client:
  1. Assicurarsi che il provider del supporto di protezione NTLM sia correttamente installato e abilitato sul client. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    269541 Messaggio di errore quando ci si connette a SQL Server se manca la chiave del Registro di sistema relativa al provider del supporto di protezione LM di Windows NT: "Impossibile generare il contesto SSPI"
  2. Verificare se si stanno utilizzando credenziali memorizzate nella cache. Se si Ŕ connessi al client utilizzando credenziali memorizzate nella cache, disconnettersi dal computer e riconnettersi quando sarÓ possibile connettersi a un controller di dominio per impedire l'impiego di credenziali memorizzate nella cache. Per ulteriori informazioni su come determinare se si stanno utilizzando credenziali memorizzate nella cache, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    242536 L'utente non viene informato quando l'accesso viene eseguito con credenziali presenti nella cache
  3. Verificare che le date sul client e sul server siano valide. Se le date sono troppo distanti, i certificati potrebbero essere considerati non validi.
  4. SSPI utilizza un file denominato Security.dll. Se qualsiasi altra applicazione installa un file con questo nome, Ŕ possibile che venga utilizzato quest'ultimo file anzichÚ il file SSPI effettivo. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    253577 Errore: 80004005: Impossibile inizializzare il pacchetto SSPI con il driver Microsoft ODBC di SQL Server
  5. Se il sistema operativo del client Ŕ Microsoft Windows 98, sarÓ necessario installare il componente Client per reti Microsoft sul client. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
    267550 ERRORE: "Asserzione non riuscita" alla connessione a SQL Server tramite TCP/IP

Verifica dell'utilitÓ Configurazione di rete client

L'utilitÓ Configurazione di rete client (CNU, Client Network Utility) viene fornita con MDAC (Microsoft Data Access Components) ed Ŕ utilizzata per configurare la connettivitÓ tra computer che eseguono SQL Server. ╚ possibile utilizzare l'utilitÓ Cliconfg.exe CNU di MDAC per configurare la connettivitÓ:
  1. Nella scheda Generale il modo di definizione dei protocolli varia a seconda della versione di MDAC. Nelle versioni meno recenti di MDAC Ŕ possibile selezionare un protocollo "predefinito", mentre nelle versioni pi¨ recenti Ŕ possibile abilitare uno o pi¨ protocolli per connettersi a SQL Server, di cui uno preferenziale al primo posto dell'elenco. Dato che SSPI viene applicato solo a TCP/IP, Ŕ possibile utilizzare un diverso protocollo, ad esempio Named Pipe, per evitare l'errore.
  2. In CNU controllare la scheda Alias per verificare se Ŕ stato definito un alias per il server a cui si sta tentando di connettersi. Se Ŕ stato definito un alias, verificare le impostazioni del computer relative alla modalitÓ di connessione a SQL Server. A tale proposito Ŕ possibile eliminare il server alias per vedere se il comportamento cambia.
  3. Se il server alias non Ŕ definito in CNU, aggiungere l'alias per il server a cui si desidera connettersi. Quando si esegue questa opzione si definisce esplicitamente anche il protocollo, oltre che facoltativamente l'indirizzo IP e la porta.

Informazioni da raccogliere per aprire un caso presso il Servizio Supporto Tecnico Clienti Microsoft (PSS, Product Support Services)

Se non Ŕ possibile identificare la causa del problema utilizzando i suggerimenti forniti in questo articolo, raccogliere le informazioni riportate di seguito e aprire un caso presso il Servizio Supporto Tecnico Clienti Microsoft:

Per un elenco completo di numeri di telefono del Servizio Supporto Tecnico Clienti Microsoft e per informazioni sui costi dell'assistenza, visitare il sito Web Microsoft all'indirizzo:
http://support.microsoft.com/contactus/?ws=support
  1. Generare un report sqldiag da SQL Server. Per ulteriori informazioni, vedere l'argomento relativo all'utilitÓ sqldiag nella documentazione in linea di SQL Server.
  2. Catturare una schermata dell'errore sul computer client.
  3. Al prompt dei comandi sul nodo da cui non si riesce a stabilire una connessione a SQL Server, digitare il comando seguente:
    net start > started.txt
    Questo comando genera un file Started.txt nella directory in cui Ŕ stato eseguito.
  4. Sul computer client salvare i valori della chiave di registro presente al di sotto della seguente chiave:
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. In un ambiente cluster ottenere il valore della seguente chiave di registro per ciascun nodo del cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. In un ambiente cluster verificare se la seguente chiave di registro esiste su ciascun nodo server del cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Acquisire i risultati, se dal client Ŕ possibile stabilire una connessione a SQL Server utilizzando un nome UNC (Universal Naming Convention) o il nome di rete SQL nel caso di un cluster.
  8. Acquisire i risultati, se dal client Ŕ possibile eseguire il ping del nome computer o del nome di rete SQL nel caso di un cluster.
  9. Salvare il nome degli account utente utilizzati per avviare ciascun servizio di SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. L'addetto al servizio di supporto deve sapere se SQL Server Ŕ configurato per un'autenticazione di tipo misto o solo per l'autenticazione di Windows.
  11. Verificare se Ŕ possibile connettersi al computer che esegue SQL Server dallo stesso client utilizzando l'autenticazione d SQL Server.
  12. Verificare se Ŕ possibile connettersi utilizzando il protocollo Named Pipe.

Configurazione manuale di un nome dell'entitÓ servizio per SQL Server

Per ulteriori informazioni su come impostare manualmente un nome dell'entitÓ servizio per SQL Server, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
319723 Utilizzo dell'autenticazione Kerberos in SQL Server


SSPI (Security Support Provider Interface) Ŕ l'interfaccia per la protezione di Microsoft Windows NT utilizzata per l'autenticazione Kerberos. Supporta lo schema di autenticazione del provider supporto protezione NTLM. L'autenticazione avviene a livello del sistema operativo quando ci si connette a un dominio Windows ed Ŕ disponibile solo per computer basati su Windows 2000 in cui sia abilitato il protocollo Kerberos e in ci venga utilizzato Active Directory.

SSPI viene utilizzata solo per connessioni TCP/IP stabilite utilizzando l'autenticazione di Windows. (L'autenticazione di Windows Ŕ anche nota con il nome di connessioni trusted o protezione integrata.) SSPI non viene utilizzato da connessioni Named Pipe o multiprotocollo. Pertanto, Ŕ possibile evitare il problema configurando i client affinchÚ si connettano da un protocollo diverso da TCP/IP.

Quando un client SQL Server tenta di utilizzare la protezione integrata su socket TCP/IP per connettersi a un computer remoto che esegue SQL Server, la libreria di rete del client SQL Server utilizza l'API SSPI per eseguire la delega della protezione. Il client di rete SQL Server (Dbnetlib.dll) effettua una chiamata alla funzione AcquireCredentialsHandle e avvia la fase di negoziazione per il parametro pszPackage. Questo informa il provider di protezione di eseguire la negoziazione della delega. In questo contesto, negoziare significa tentare di effettuare l'autenticazione Kerberos o NTLM su computer basati su Windows. In altre parole, Windows utilizza la delega Kerberos se al computer di destinazione che esegue SQL Server Ŕ associato un SPN correttamente configurato. In caso contrario, utilizza la delega NTLM.

Nota Verificare di non stare utilizzando un account "SYSTEM" per avviare qualsiasi servizio di SQL Server (MSSQLServer, SQLServerAgent, MSSearch). La parola chiave SYSTEM pu˛ infatti causare dei conflitti con il Centro distribuzione chiavi (KDC).

Riferimenti

Per ulteriori informazioni sul funzionamento della protezione Kerberos e SSPI, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:
266080 Risposte alle domande frequenti relative a Kerberos
231789 Processo di accesso locale per Windows 2000
304161 L'autenticazione SSPI reciproca viene indicata sul lato client ma non sul lato server
232179Amministrazione Kerberos in Windows 2000
230476 Descrizione di errori comuni relativi a Kerberos in Windows 2000
262177 Attivazione della registrazione di eventi Kerberos
277658 Errore di Setspn se il nome di dominio non corrisponde al nome NetBIOS in cui Ŕ registrato l'SPN di SQL Server
244474Come forzare Kerberos a utilizzare TCP anzichÚ UDP in Windows Server 2003, Windows XP e in Windows 2000
326985Risoluzione dei problemi relativi a Kerberos in IIS
Per ottenere un white paper relativo alla protezione in Microsoft SQL Server 2000, visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sp3sec00.mspx

ProprietÓ

Identificativo articolo: 811889 - Ultima modifica: martedý 16 luglio 2013 - Revisione: 21.2
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Chiavi:á
kbsqlmanagementtools kbhowtomaster kbhowto KB811889
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com