Utilizzo dell'autenticazione Kerberos in SQL Server

Riepilogo

Nota: Per configurare il computer SQL Server per le connessioni di autenticazione Kerberos in versioni più recenti di SQL Server, vedere gli argomenti seguenti:

Utilizzo dell'autenticazione Kerberos con SQL Server

La registrazione di un nome principale servizio

Se si verificano problemi utilizzando le connessioni di Kerberos, è possibile utilizzare lo strumento Gestione configurazione di Kerberos, come illustrato nel post di blog MSDN seguente:

Gestione configurazione di Kerberos
È possibile utilizzare l'autenticazione Kerberos con Microsoft SQL Server 2000. SQL Server 2000 supporta questa funzionalità come parte di un'installazione tipica di dominio Microsoft Windows 2000 o Microsoft Windows Server 2003 Active Directory. Con Microsoft Windows 2000 Service Pack 3 (SP3) e Windows Server 2003, è possibile abilitare l'autenticazione Kerberos su cluster di server.

Per ulteriori informazioni su questa funzionalità aggiuntiva, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:
235529 supporto di Kerberos sui cluster di server basato su Windows 2000


Nota: È possibile utilizzare questa funzionalità solo se si esegue Windows 2000 SP3 o Windows Server 2003.

Il clustering di failover di SQL Server 2000 utilizza anche questa funzionalità. Quando la risorsa nome di rete di SQL Server è dipendente da un cluster basato su Windows 2000, è possibile utilizzare l'autenticazione Kerberos sulla risorsa dopo l'aggiornamento del computer a Windows 2000 SP3 o Windows Server 2003. Per installare il clustering di failover di SQL Server, è necessario disporre di Microsoft SQL Server 2000 Enterprise Edition o Developer Edition installata.

Nota: I concetti e le discussioni che si applicano a SQL Server 2000 in questo articolo si applicano anche a SQL Server 2005. Per ulteriori informazioni su questo argomento in SQL Server 2005, vedere i seguenti argomenti nella documentazione in linea di SQL Server 2005:
  • Procedura: attivare l'autenticazione Kerberos tra i server virtuali di SQL Server nei cluster di Server
  • Registrazione del nome principale servizio
Per ulteriori informazioni su come verificare che si utilizza l'autenticazione Kerberos in SQL Server 2005, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

909801 come assicurarsi che si utilizza l'autenticazione Kerberos quando si crea una connessione remota a un'istanza di SQL Server 2005

Ulteriori informazioni

SQL Server è possibile utilizzare l'autenticazione Kerberos per i cluster di server. È possibile utilizzare l'autenticazione Kerberos con computer autonomi che eseguono SQL Server o istanze di SQL Server in esecuzione su un server virtuale.

Connettersi a un server che esegue Microsoft Internet Information Services e stabilire una connessione di Kerberos in SQL Server 2000

In questa sezione viene descritto come connettersi a un server che esegue Microsoft Internet Information Services (IIS) per stabilire una connessione di Kerberos in un server che esegue SQL Server.

Nota Prima di effettuare la procedura di installazione, scaricare il Kerbtray e le utilità SetSPN.

Per scaricare l'utilità Kerbtray, visitare il seguente sito Web Microsoft:Con Kerbtray.exe, è facilmente possibile verificare o rimuovere (o entrambi) da qualsiasi computer associati che vengono utilizzati i ticket Kerberos.


Per scaricare l'utilità SetSPN, visitare il seguente sito Web Microsoft:

La procedura riportata di seguito viene fornito un esempio di una sequenza di installazione quando si utilizza l'autenticazione di Kerberos tramite una pagina IIS per accedere a un server che esegue SQL Server.

Passaggio 1: Configurare il controller di dominio

Su un controller di dominio in Active Directory Users and Computers:
  1. Pulsante destro del mouse del computer che si desidera impostare per la delega (server di servizi di IIS), quindi selezionare computer attendibile per la delega. Se il computer che esegue SQL Server è quello che sembra essere l'ultimo computer contattato ma che il computer è un server collegato, è necessario anche concesse autorizzazioni di delega. Se non si tratta dell'ultimo computer nella catena, tutti i computer che sono intermediari devono essere trusted per delega.
  2. Concedere l'autorizzazione di delega per l'account utente di dominio account di servizio di SQL Server. È necessario disporre di un account utente di dominio per le installazioni cluster di SQL Server (questo passaggio non è obbligatorio per i computer che eseguono SQL Server che utilizza un account di sistema locale):
    1. Nella cartella Users , destro l'account utente e quindi scegliere proprietà.
    2. Nella finestra di dialogo Proprietà account utente, scegliere il
      Scheda account .
    3. In Opzioni Account, fare clic per selezionare il Account è Trusted per delega casella di controllo. Assicurarsi che l'Account è sensibile e non può essere delegato è deselezionata per questo account.

      Nota: Il diritto "Account è trusted per delega" è obbligatorio per l'account del servizio SQL Server solo quando si delega credenziali dal server SQL di destinazione a un server SQL remoto, ad esempio in uno scenario di doppio hop come query distribuite, le query di server collegato, che utilizzano l'autenticazione di Windows.
    Nota: Questa procedura si applica solo a Windows 2000 Server. Se si utilizza Windows Server 2003, visitare il seguente sito Web Microsoft Developer Network (MSDN):
  3. Utilizzare l'utilità Kerbtray.exe per verificare che i ticket Kerberos sono stati ricevuti dall'host del controller di dominio:
    1. Pulsante destro del mouse sull'icona di Kerbtray nell'area di notifica e quindi fare clic su Elimina ticket.
    2. Attendere che l'icona verde Kerbtray passare da verde a giallo. Non appena questo si verifica, aprire una finestra del prompt dei comandi ed eseguire questo comando:
      del comando NET session * /d
      Verranno eliminare le sessioni esistenti e imporre un ticket Kerberos ricevuto e stabilire una nuova sessione.

Passaggio 2: Configurare il server di servizi IIS

  1. Sostituire i file di Wwwroot del sito Web predefinito con i file ASP di esempio. Per creare i file ASP di esempio, utilizzare il codice fornito nella sezione "ASP test script per il recupero dei dati di SQL Server".
  2. Aggiungere il file nella cartella Wwwroot. A tale scopo, utilizzare il codice di esempio nella sezione "ASP Test Script per SQL Server il recupero dei dati". Salvare il file come default. ASP.
  3. Riconfigurare il server Web per utilizzare solo l'autenticazione integrata di Windows:
    1. Pulsante destro del mouse sul server Web predefinito e fare clic sulla cartella protezione.
    2. Nella cartella protezione, apportare le modifiche corrette e fare clic per deselezionare accesso anonimo.
    3. Dal prompt dei comandi, eseguire il comando:
      cscript C:\Inetpub\Adminscripts\adsutil.vbs get w3svc/NTAuthenticationProviders
      Se Negotiate è attivata, viene restituito il seguente:
       NTAuthenticationProviders : (STRING) Negotiate,NTLM 
      Per ulteriori informazioni, fare clic sul seguente numero di articolo per visualizzare l'articolo della Microsoft Knowledge Base:

      215383 come configurare IIS per supportare il protocollo Kerberos e il protocollo NTLM per l'autenticazione di rete

    Note
    • È necessario installare Microsoft Data Access (MDAC) 2.6 o versioni successive, sul server IIS. A tale scopo (e per rendere gli strumenti disponibili per il test), installare gli strumenti client di SQL Server 2000 per il server Web. Per installare solo MDAC 2.6 o versione successiva (senza installare gli strumenti client), visitare il seguente sito Web Microsoft:
    • IIS è un sistema comune di livello intermedio. IIS non è tuttavia il sistema di livello intermedio solo. Se IIS non è il sistema di livello intermedio nell'ambiente in uso, attenersi alla procedura appropriata per il sistema di livello intermedio.
  4. Verificare che il valore di HKLM\SW\MS\MSSQLSERVER\Client\DSQUERYsia presente nel Registro di sistema. Se il valore non è visualizzato, è necessario aggiungerlo come
    DSQUERY:Reg_SZ:DBNETLIB.
  5. Utilizzare l'utilità Kerbtray.exe per verificare che i ticket Kerberos sono stati ricevuti dall'host del controller di dominio:
    1. Pulsante destro del mouse sull'icona di Kerbtray nell'area di notifica e quindi fare clic su Elimina ticket.
    2. Attendere che l'icona verde Kerbtray passare da verde a giallo. Non appena questo si verifica, aprire una finestra del prompt dei comandi ed eseguire questo comando:
      del comando NET session * /d
      Verranno eliminare le sessioni esistenti e imporre un ticket Kerberos ricevuto e stabilire una nuova sessione.

Passaggio 3: Configurare il servizio SQL Server per creare dinamicamente SPN

A tale scopo, è necessario concedere le seguenti impostazioni di controllo accesso per l'account del servizio SQL Server nel servizio directory Active Directory:
  • Lettura servicePrincipalName
  • Scrivere servicePrincipalName
Avvisi
  • Se si utilizza lo snap-in Active Directory Service Interfaces (ADSI) Edit, l'utilità LDP o i client LDAP 3 e si modificano erroneamente gli attributi degli oggetti di Active Directory, si verificano problemi gravi. Per risolvere questi problemi, potrebbe essere necessario reinstallare Microsoft Exchange 2000 Server o Microsoft Exchange Server 2003. In alcuni casi, potrebbe essere necessario reinstallare Microsoft Windows 2000 Server o Microsoft Windows Server 2003, quindi reinstallare Exchange 2000 Server o Exchange Server 2003. È possibile garantire che questi problemi possano essere risolti. Modificare questi attributi a proprio rischio.
  • È necessario essere connessi come amministratore di dominio. In alternativa, è necessario chiedere all'amministratore di dominio di concedere autorizzazioni e diritti utente appropriati per l'account di avvio di SQL Server.
Per configurare il servizio SQL Server per creare nomi SPN dinamicamente all'avvio del servizio SQL Server, attenersi alla seguente procedura:
  1. Fare clic su Start, scegliere Esegui, digitare ADSIEdit. msce quindi fare clic su OK.

    Nota: Lo strumento ADSIEdit è incluso negli strumenti di supporto di Windows. Per ottenere gli strumenti di supporto, visitare il seguente sito Web Microsoft:
  2. In ADSI Edit snap-in, espandere il dominio [NomeDominio], DC = RootDomainName, espandere CN = Users, destro CN = AccountName , quindi scegliere proprietà.

    Note
    • DomainName è un segnaposto per il nome del dominio.
    • RootDomainName è un segnaposto per il nome del dominio principale.
    • Nome account è un segnaposto per l'account specificato per avviare il servizio SQL Server.
    • Se si specifica l'account di sistema locale per avviare il servizio SQL Server, nome account è un segnaposto per l'account utilizzato per accedere a Microsoft Windows.
    • Se si specifica un account utente di dominio per avviare il servizio SQL Server, nome account è un segnaposto per l'account utente di dominio.
  3. Nella CN = proprietà AccountName finestra di dialogo scegliere la scheda protezione .
  4. Nella scheda protezione , fare clic su Avanzate.
  5. Nella finestra di dialogo Impostazioni avanzate di protezione , assicurarsi che SELF è elencato in voci di autorizzazione.

    Se SELF non è elencato, fare clic su Aggiungie quindi aggiungere SELF.
  6. In autorizzazioni, fare clic su SELFe quindi fare clic su Modifica.
  7. Nella finestra di dialogo Voce autorizzazione , fare clic sulla scheda proprietà .
  8. Nella scheda proprietà , fare clic su questo oggetto solo nell'elenco Applica e quindi fare clic per selezionare le caselle di controllo per le autorizzazioni seguenti in autorizzazioni:
    • Lettura servicePrincipalName
    • Scrivere servicePrincipalName
  9. Fare clic su OK due volte.

    Nota: Per informazioni su questo processo, contattare il supporto tecnico di Active Directory e precisare l'articolo della Microsoft Knowledge Base.

    Nota: Per utilizzare lo strumento dsacls per determinare se l'account utente disponga dell'autorizzazione di scrittura ServicePrincipalName, utilizzare il comando dsacls . Di seguito è la sintassi:
    dsacls <distinguished_Name_of_service_account>
    Se l'account utente disponga dell'autorizzazione di scrittura ServicePrincipalName, verrà visualizzato il seguente output:
    Allow NT Authority\SELF SPECIAL ACCESS for Validated Write to Service principal nameWRITE PROPERTY
    Lo strumento dsacls fa parte degli strumenti di supporto.
  10. Nella CN = proprietà AccountName finestra di dialogo fare clic su Editor attributi.
  11. Nell'elenco di attributi, selezionare servicePrincipalName nella colonna attributo e quindi fare clic su Modifica.
  12. Nella finestra di dialogo Editor di stringa multivalore , rimuovere i nomi principali di servizio (SPN) per le istanze di SQL Server che utilizzano l'account del servizio SQL Server.

    Avviso È necessario eliminare gli SPN solo per le istanze di SQL Server che siano lavorando. Altre istanze di SQL Server che utilizzano l'account del servizio saranno in grado di rimuovere gli SPN correlate a queste istanze al successivo avvio di tali istanze.
  13. Chiudere lo snap-in ADSI Edit.
Dopo aver eseguito questi passaggi, problemi SPN vengono eliminati anche se si modifica la porta TCP/IP o il nome di dominio per le nuove installazioni di SQL Server 2005 o per le istanze esistenti di SQL Server 2005.

Importante Si consiglia di non concedere il permesso WriteServicePrincipalName per l'account del servizio SQL quando si verificano le seguenti condizioni:
  • Esistono più controller di dominio.
  • Cluster di SQL Server.
In questo scenario, il SPN per il SQL Server può essere eliminato a causa di latenza di replica di Active Directory. Ciò potrebbe causare problemi di connettività all'istanza di SQL Server.

Si supponga di avere il seguente:
  • Un'istanza virtuale di SQL con due nodi di cluster di SQL: il nodo e il nodo B.
  • Il nodo è stato autenticato da un controller di dominio e il nodo B viene autenticato dal controller di dominio B.


Può verificarsi quanto segue:
  1. L'istanza cluster di SQL è attivo nel nodo e registrato il SPN SQL nel controller di dominio durante l'avvio di...
  2. L'istanza cluster di SQL failover al nodo B quando il nodo viene arrestato normalmente.
  3. L'istanza cluster di SQL annullata la registrazione il proprio nome SPN dal controller di dominio durante il processo di arresto sul nodo A.
  4. il SPN verrà rimosso dal controller di dominio, ma la modifica non è ancora stata replicata al controller di dominio B.
  5. Durante l'avvio del nodo B, l'istanza cluster di SQL tenta di registrare il SPN di SQL con il controller di dominio B. Successivamente, il SPN esiste ancora il nodo B non viene registrato il SPN.
  6. Dopo un po' di tempo l'eliminazione di SPN (dal passaggio 3) per il controller di dominio B come parte della replica di Active Directory replica i controller di dominio. Il risultato finale è che non esiste alcun SPN valido per l'istanza SQL nel dominio e si vedano quindi i problemi di connessione all'istanza cluster di SQL.

Nota: Questo problema viene risolto in SQL Server 2012.


Passaggio 4: Configurare i computer client

  1. Per ogni client che si connetterà, verificare che Microsoft Internet Explorer è configurato per utilizzare l'autenticazione di Windows:
    1. In Internet Explorer, scegliere Opzioni Internetdal menu Strumenti .
    2. Fare clic sulla scheda Avanzate .
    3. Nella sezione protezione, fare clic su
      Abilita autenticazione Windows integrata (richiede riavvio), quindi scegliere OK.

Passaggio 5: Verificare la configurazione

Per ogni computer coinvolti:
  1. Accedere al computer e quindi utilizzare Kerbtray.exe per verificare che il computer può ottenere un ticket Kerberos valido dal controller di dominio.
  2. Utilizzare Kerbtray.exe per rimuovere tutti i ticket sul computer.
  3. Creare e connettersi alla pagina Web che restituisce i dati di SQL Server.

    Nota: Sostituire SQLSERVERNAME con il nome del computer che esegue SQL Server:
    • Se vengono restituiti dati, questa pagina Visualizza il tipo di autenticazione Negotiatee i dati di SQL Server per il risultato di sp_helpdb la stored procedure che deve restituire un elenco dei database nel server che è in corso la connessione a tramite la. Pagina ASP.
    • Se si ha attivato il controllo in SQL Server, nel registro dell'applicazione si vedrà che la connessione è "attendibile".

Script di test ASP per il recupero dei dati di SQL Server

Di seguito è riportato uno script di test ASP per i dati di SQL Server. Se si utilizza questo esempio di codice, assicurarsi di sostituire
SQLSERVERNAME con il nome del computer che esegue SQL Server.
<%@ Language=VBScript %><HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
</HEAD>
<BODY>
<%="'auth_user' is" & request.servervariables("auth_user")%>
<P>
<%="'auth_type' is" & request.servervariables("auth_type")%>
<P>
Connections string is <B>" Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME </B>
<P>
<%
set rs = Server.CreateObject("ADODB.Recordset")
set cn = Server.CreateObject("ADODB.Connection")
cn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME"
rs.open "MASTER..sp_helpdb",cn
Response.Write cstr(rs.Fields.Count) +"<BR>"
while not rs.EOF
Response.Write cstr(rs(0))+"<BR>"
rs.MoveNext
wend
rs.Close
cn.Close
set rs = nothing ' Frees memory reserved by the recordset.
set cn = nothing ' Frees memory reserved by the connection.
%>
</BODY>
</HTML>

Come raccogliere un elenco di informazioni sul nome di principio server Active Directory

Per raccogliere un elenco di informazioni nome principale (SPN) di server Active Directory, digitare il seguente comando su uno dei controller di dominio, dove betaland è il nome di dominio NetBIOS e
NewoutputUsers.txt è il nome del file di output che verrà utilizzato per i risultati di porta. Se si utilizza un percorso completo, il file viene inserito nella cartella corrente in cui viene eseguito dalla riga di comando. Questo comando di esempio query intero dominio:
LDIFDE -d "CN = Users, DC =betaland" servicePrincipalName -l -F
NewoutputUsers.txt
Questa sintassi consente di creare un file denominato NewoutputUsers.txt che contiene informazioni che sono simile a quello nella sezione "Dominio livello di output di NewouputUsers.txt" in questo articolo.

Questo output può essere travolgente, quando si raccolta per un intero dominio. Pertanto, per limitare le informazioni raccolte su un nome utente specifico, utilizzare la sintassi seguente, dove
Nome utente è il nome utente e
betaland è il dominio che si esegue la query:
LDIFDE -d "CN =Nome utente, DC =betaland" servicePrincipalName -l -F
NewoutputUsers.txt
Raccolta delle informazioni per un utente specifico notevolmente riduce i dati che devono cercare. Se è raccogliere le informazioni per un intero dominio, cercare il nome utente specifico del server in questione. Nell'esempio di output, vedere:
  • Voci per i server che non esistono più, ma che non sono stati completamente rimossi da Active Directory.
  • L'utente "Nome utente" non valido SPN informazioni dieci server diversi.
Inoltre, è possibile utilizzare lo strumento Active Directory Service Interfaces (ADSI) per correggere i movimenti di Active Directory che non sono validi.


Avviso Se si utilizza lo snap-in ADSI Edit, l'utilità LDP o qualsiasi altro client LDAP versione 3 e si modificano erroneamente gli attributi degli oggetti Active Directory, è possibile causare seri problemi. Questi problemi possono richiedere la reinstallazione di Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, o sia di Windows e di Exchange. Microsoft non garantisce che i problemi che si verificano se si modificano erroneamente gli attributi degli oggetti di Active Directory possano essere risolti. Modificare questi attributi a proprio rischio.

Output di livello di dominio di NewouputUsers.txt

dn: CN=User Name,CN=Users,DC=betalandchangetype: add
servicePrincipalName: MSSQLSvc/CLUSTERDEFAULT.betaland:1257
servicePrincipalName: MSSQLSvc/INST3.betaland:3616
servicePrincipalName: MSSQLSvc/INST2.betaland:3490
servicePrincipalName: MSSQLSvc/SQLMAN.betaland:1433
servicePrincipalName: MSSQLSvc/VSS1.betaland:1433
servicePrincipalName: MSSQLSvc/INST1.betaland:2536
servicePrincipalName: MSSQLSvc/INST4.betaland:3967
servicePrincipalName: MSSQLSvc/SQLVIRTUAL1.betaland:1434
servicePrincipalName: MSSQLSvc/SQLVIRTUAL.betaland:1433
servicePrincipalName: MSSQLSvc/SQLBUSTER.betaland:1315

Riferimenti

Per ulteriori informazioni sulla delega degli account di protezione, vedere l'argomento "Delega degli Account di protezione" nella documentazione in linea di SQL Server.


Per ulteriori informazioni, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base:
262177 come abilitare la registrazione eventi Kerberos

321708 come utilizzare lo strumento di diagnostica di rete (Netdiag.exe) in Windows 2000

326985 come risolvere i problemi relativi a Kerberos in IIS

244474 come forzare Kerberos a utilizzare TCP anziché UDP in Windows Server 2003, Windows XP e Windows 2000

Proprietà

ID articolo: 319723 - Ultima revisione: 30 gen 2017 - Revisione: 1

Microsoft SQL Server 2000 Standard Edition, Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition

Feedback