Configurazione dell'autenticazione Kerberos: configurazione di base (SharePoint Server 2010)
Si applica a: SharePoint Server 2010
Ultima modifica dell'argomento: 2017-01-18
Nel primo scenario verranno configurate due applicazioni Web SharePoint Server 2010 per l'utilizzo del protocollo Kerberos per l'autenticazione delle richieste client in arrivo. Un'applicazione Web verrà configurata a fini dimostrativi per l'utilizzo di porte standard (80/443) e l'altra per l'utilizzo di una porta non predefinita (5555). Questo scenario verrà utilizzato come base per tutti gli scenari successivi, in cui si partirà dal presupposto che siano state completate le attività indicate di seguito.
Importante
Come requisito è necessario configurare le applicazioni Web con l'autenticazione di Windows classica basata sull'autenticazione Kerberos in modo che gli scenari funzionino come previsto. L'autenticazione basata sulle attestazioni di Windows può essere utilizzata in alcuni scenari, ma è possibile che non produca i risultati descritti negli scenari che seguono.
Nota
Se si sta eseguendo l'installazione in Windows Server 2008, potrebbe essere necessario installare l'hotfix seguente per l'autenticazione Kerberos:
Un'autenticazione Kerberos ha esito negativo con codice errore 0X80090302 oppure 0x8009030f in un computer in cui è in esecuzione Windows Server 2008 o Windows Vista quando viene utilizzato l'algoritmo AES (https://support.microsoft.com/kb/969083/it)
In questo scenario vengono eseguite le operazioni seguenti:
Configurare due applicazioni Web con aree predefinite in cui viene utilizzato il protocollo Kerberos per l'autenticazione
Creare due raccolte siti di prova, una in ogni applicazione Web
Verificare la configurazione IIS dell'applicazione Web
Verificare che i client possano eseguire l'autenticazione nell'applicazione Web e che venga utilizzato il protocollo Kerberos per l'autenticazione
Configurare la web part Visualizzatore RSS per visualizzare i feed RSS in un'applicazione Web locale e remota
Eseguire una ricerca per indicizzazione in ogni applicazione Web e testare la ricerca di contenuto in ogni raccolta siti di prova
Elenco di controllo della configurazione
| Area di configurazione | Descrizione |
|---|---|
DNS |
Registrare un record A DNS per l'IP virtuale (VIP ) con bilanciamento carico di rete delle applicazioni Web |
Active Directory |
Creare account di servizio per il pool di applicazioni IIS delle applicazioni Web Registrare i nomi delle entità servizio per le applicazioni Web nell'account di servizio creato per il pool di applicazioni IIS dell'applicazione Web Configurare la delega vincolata Kerberos per gli account di servizio |
Applicazione Web SharePoint |
Creare account gestiti di SharePoint Server Creare l'applicazione del servizio di ricerca di SharePoint Creare le applicazioni Web SharePoint |
IIS |
Verificare che l'autenticazione Kerberos sia abilitata Verificare che l'autenticazione in modalità kernel sia disabilitata Installare i certificati per SSL |
Client Windows 7 |
Verificare che gli URL delle applicazioni Web si trovino nell'area Intranet o in un'area configurata per l'autenticazione automatica con l'autenticazione integrata di Windows |
Configurazione del firewall |
Aprire le porte del firewall per consentire il traffico HTTP su porte predefinite e non predefinite Verificare che i client possano connettersi alle porte Kerberos in Active Directory |
Verifica dell'autenticazione del browser |
Verificare che l'autenticazione funzioni correttamente nel browser Verificare le informazioni di accesso nel registro eventi di sicurezza del server Web Utilizzare strumenti di terze parti per verificare che l'autenticazione Kerberos sia configurata correttamente |
Verifica di query e indice di ricerca di SharePoint Server |
Verificare l'accesso al browser dai server di indicizzazione Caricare il contenuto di esempio ed eseguire una ricerca per indicizzazione Testare il servizio di ricerca |
Verifica della delega front-end Web |
Configurare le origini di feed RSS in ogni raccolta siti Aggiungere le web part Visualizzatore RSS alla home page di ogni raccolta siti |
Istruzioni dettagliate per la configurazione
Configurare DNS
Configurare DNS per le applicazioni Web nell'ambiente in uso. In questo esempio sono presenti due applicazioni Web, http://portal e http://teams:5555, ed entrambe vengono risolte nello stesso VIP con Bilanciamento carico di rete (192.168.24.140/24).
Per informazioni di carattere generale su come configurare DNS, vedere Gestione dei record DNS (le informazioni potrebbero essere in lingua inglese).
Applicazioni Web SharePoint Server
http://portal - Configurare un nuovo record A DNS per l'applicazione Web portal. In questo esempio si dispone di un "portale" host configurato per la risoluzione nel VIP con bilanciamento del carico.
.jpg "Immagine di un record DNS")
http://teams:5555 - Configurare un nuovo record A DNS per l'applicazione Web del team
.jpg "Immagine di un record DNS")
Nota
È importante accertarsi che le voci DNS siano record A e non alias CNAME per il corretto funzionamento dell'autenticazione Kerberos in ambienti con più applicazioni Web in esecuzione con intestazioni host e account di servizio dedicati separati. Per una spiegazione del problema noto relativo all'utilizzo di CNAME con le applicazioni Web abilitate per Kerberos, vedere Problemi noti della configurazione Kerberos (SharePoint Server 2010).
Configurare Active Directory
Successivamente verranno configurati gli account Active Directory per le applicazioni Web dell'ambiente. Come procedura consigliata, configurare ogni applicazione Web per l'esecuzione nel proprio pool di applicazioni IIS con il proprio contesto di sicurezza (identità del pool di applicazioni).
Account di servizio delle applicazioni SharePoint Service
Nell'esempio sono presenti due applicazioni Web SharePoint Server eseguite in due pool di applicazioni IIS separati con le proprie identità del pool di applicazioni.
| Applicazione Web (area predefinita) | Identità del pool di applicazioni IIS |
|---|---|
vmlab\svcPortal10App |
|
vmlab\ svcTeams10App |
Nomi delle entità servizio
Per ogni account di servizio configurare un insieme di nomi delle entità servizio (SPN, Service Principal Name) mappati al nomi host DNS assegnati a ogni applicazione Web.
Utilizzare SetSPN, uno strumento da riga di comando in Windows Server 2008, per configurare un nuovo nome dell'entità servizio. Per una spiegazione completa dell'utilizzo di SetSPN, vedere Setspn (le informazioni potrebbero essere in lingua inglese). Per informazioni sui miglioramenti apportati in SetSPN in Windows Server 2008, vedere Nuove funzionalità di SETSPN.EXE in Windows Server 2008 (le informazioni potrebbero essere in lingua inglese).
In tutte le applicazioni Web SharePoint Server viene utilizzato il formato SPN seguente, indipendentemente dal numero di porta:
HTTP/<nome HOST DNS>
HTTP/<FQDN DNS>
Esempio:
HTTP/portal
HTTP/portal.vmlab.local
Per le applicazioni Web eseguite su porte non predefinite (diverse da 80/443), registrare SPN aggiuntivi con il numero di porta:
HTTP/<Nome host DNS>:<porta>
HTTP/<FQDN DNS>:<porta>
Esempio:
HTTP/teams:5555
HTTP/teams.vmlab.local:5555
Nota
Vedere l'appendice per informazioni sul motivo per cui è consigliabile configurare gli SPN con e senza numero di porta per i servizi HTTP in esecuzione su porte non predefinite (80, 443). Dal punto di vista tecnico la notazione corretta per fare riferimento a un servizio HTTP eseguito su una porta non predefinita include il numero di porta nell'SPN, ma a causa di problemi noti descritti nell'appendice, è necessario configurare gli SPN anche senza porta. Si noti che gli SPN senza porta per le applicazioni Web teams non indicano che i servizi saranno accessibili utilizzando le porte predefinite (80, 443) dell'esempio.
Nell'esempio sono stati configurati i nomi delle entità servizio seguenti per i due account creati nel passaggio precedente:
| Host DNS | Identità del pool di applicazioni IIS | Nomi delle entità servizio |
|---|---|---|
Portal.vmlab.local |
vmlab\svcPortal10App |
HTTP/portal HTTP/portal.vmlab.local |
Teams.vmlab.local |
vmlab\ svcTeams10App |
HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Per creare i nomi delle entità servizio sono stati eseguiti i comandi riportati di seguito:
SetSPN -S HTTP/Portal vmlab\svcportal10App
SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App
SetSPN -S HTTP/Teams vmlab\svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App
SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App
Importante
Non configurare i nomi delle entità servizio con HTTPS anche se nell'applicazione Web viene utilizzato SSL.
Nell'esempio è stata utilizzata una nuova opzione della riga di comando -S, introdotta in Windows Server 2008, che verifica se l'SPN esiste prima di crearlo nell'account. Se l'SPN esiste già, il nuovo SPN non verrà creato e verrà visualizzato un messaggio di errore.
Se vengono rilevati SPN duplicati, per risolvere il problema utilizzare un nome DNS diverso per l'applicazione Web, modificando pertanto l'SPN, oppure rimuovere l'SPN esistente dall'account in cui è stato rilevato.
Importante
Prima di eliminare un SPN esistente, accertarsi che non sia più necessario, altrimenti esiste il rischio di interrompere l'autenticazione Kerberos per un'altra applicazione nell'ambiente.
Nomi delle entità servizio e SSL
È comune confondere i nomi delle entità servizio Kerberos con gli URL per le applicazioni Web HTTP, poiché la sintassi dei formati SPN e URI è molto simile. È importante tuttavia sapere che si tratta di due elementi diversi e univoci. I nomi delle entità servizio Kerberos vengono utilizzati per identificare un servizio e se il servizio è un'applicazione HTTP, lo schema del servizio sarà "HTTP", indipendentemente dal fatto che l'accesso al servizio venga effettuato con SSL o senza. Pertanto, anche se si accede all'applicazione Web utilizzando "https://app", non si configura un nome dell'entità servizio con HTTPS, ad esempio "HTTPS/app".
Configurare la delega vincolata Kerberos per computer e account di servizio
A seconda dello scenario, alcune funzionalità in SharePoint Server 2010 possono richiedere la configurazione della delega vincolata. Se ad esempio la web part Visualizzatore RSS è configurata per la visualizzazione di un feed RSS da un'origine autenticata, sarà necessaria la delega per utilizzare il feed di origine. In altre situazioni potrebbe essere necessario configurare la delega vincolata per consentire alle applicazioni di servizio (ad esempio Excel Services) di delegare l'identità del client ai sistemi back-end.
In questo scenario verrà configurata la delega vincolata Kerberos per consentire alla web part Visualizzatore RSS di leggere da un'applicazione Web remota un feed RSS locale protetto e un feed RSS remoto protetto. In scenari successivi verrà configurata la delega vincolata Kerberos per altre applicazioni di servizio di SharePoint Server 2010.
Nella figura seguente vengono descritti concettualmente gli elementi che verranno configurati in questo scenario:
.jpg "Diagramma dello scenario")
Sono presenti due applicazioni Web, ognuna con la propria raccolta siti con una pagina di sito che ospita due web part Visualizzatore RSS. In ogni applicazione Web è presente una singola area predefinita configurata per l'utilizzo dell'autenticazione Kerberos, in modo che tutti i feed provenienti da questi siti Web richiedano l'autenticazione. In ogni sito un Visualizzatore RSS sarà configurato per leggere un feed RSS locale da un elenco e l'altro sarà configurato per leggere un feed di autenticazione nel sito remoto.
A tale scopo, verrà configurata la delega vincolata Kerberos per consentire la delega tra gli account di servizio del pool di applicazioni IIS. Nella figura seguente vengono descritti concettualmente i percorsi di delega vincolata necessari:
.jpg "Diagramma della delega del pool di applicazioni")
Come è noto, l'applicazione Web viene identificata per nome di servizio utilizzando il nome dell'entità servizio (SPN) assegnato all'identità del pool di applicazioni IIS. È necessario consentire agli account di servizio che elaborano le richieste di delegare l'identità del client ai servizi designati. Nel complesso è necessario configurare i percorsi di delega condivisa seguenti:
| Tipo entità | Nome entità | Delega al servizio |
|---|---|---|
Utente |
svcPortal10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Utente |
svcTeams10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Nota
Potrebbe sembrare ridondante configurare la delega da un servizio a se stesso, ad esempio l'account di servizio del portale che definisce come destinazione della delega l'applicazione di servizio portal, ma questa configurazione è necessaria negli scenari in cui più server eseguono il servizio. Questo aspetto consente di prevedere lo scenario in cui un server può dover definire come destinazione della delega un altro server che esegue lo stesso servizio, ad esempio un server Web front-end che elabora una richiesta con un visualizzatore RSS che utilizza l'applicazione Web locale come origine dati. A seconda della configurazione e della topologia di farm, esiste la possibilità che la richiesta RSS venga gestita da un server diverso, il che richiede il corretto funzionamento della delega.
Per configurare la delega è possibile utilizzare lo snap-in Utenti e computer di Active Directory. Fare clic con il pulsante destro del mouse su ogni account di servizio e aprire la finestra di dialogo delle proprietà. Nella finestra di dialogo verrà visualizzata una scheda per la delega. Si noti che questa scheda è disponibile soltanto se all'oggetto è stato assegnato un SPN. Ai computer viene assegnato un SPN per impostazione predefinita. Nella scheda della delega selezionare Utente attendibile per la delega solo ai servizi specificati e quindi Utilizza un qualsiasi protocollo di autenticazione.
Fare clic sul pulsante Aggiungi per aggiungere i servizi di destinazione della delega dell'utente (account di servizio). Per selezionare un SPN, cercare l'oggetto a cui è applicato l'SPN. In questa istanza si tenta di definire come destinazione della delega un servizio HTTP e pertanto verrà ricercato l'account di servizio del pool di applicazioni IIS a cui è stato assegnato l'SPN nel passaggio precedente.
Nella finestra di dialogo Seleziona utenti, computer o gruppi fare clic su Utenti e computer, cercare gli account di servizio del pool di applicazioni IIS (nell'esempio vmlab\svcPortal10App e vmlab\svcTeams10App) e quindi fare clic su OK.
Verrà chiesto di selezionare i servizi assegnati agli oggetti per nome dell'entità servizio.
Nella finestra di dialogo Aggiungi servizi fare clic su Seleziona tutto e quindi su OK. Si noti che quando si torna alla finestra di dialogo della delega in realtà non vengono visualizzati tutti gli SPN selezionati. Per visualizzarli tutti, selezionare la casella di controllo Espanso nell'angolo in basso a sinistra.
Effettuare queste operazioni per ogni account di servizio dell'ambiente che richiede la delega, in questo esempio l'elenco degli account di servizio.
Configurare SharePoint Server
Dopo aver configurato Active Directory e DNS, creare l'applicazione Web nella farm di SharePoint Server 2010. In questo documento si presuppone che l'installazione di SharePoint Server sia stata completata e che siano state configurate la topologia di farm e l'infrastruttura di supporto, ad esempio il bilanciamento del carico. Per ulteriori informazioni su come installare e configurare la farm di SharePoint vedere Distribuzione di SharePoint Server 2010.
Configurare gli account di servizio gestiti
Prima di creare le applicazioni Web, configurare gli account di servizio creati nei passaggi precedenti come account di servizio gestiti in SharePoint Server. Se si esegue questa procedura in anticipo sarà possibile ignorare questo passaggio durante la creazione delle applicazioni Web.
Per configurare un account gestito
In Amministrazione centrale SharePoint fare clic su Sicurezza.
In Sicurezza generale fare clic su Configura account gestiti.
Fare clic su Registra account gestito e creare un account gestito per ogni account di servizio. In questo esempio sono stati creati cinque account di servizio gestiti:
Account Scopo VMLAB\svcSP10Search
Account del servizio di ricerca di SharePoint
VMLAB\svcSearchAdmin
Account del servizio di amministrazione della ricerca di SharePoint
VMLAB\svcSearchQuery
Account del servizio di query di ricerca di SharePoint
VMLAB\svcPortal10App
Account del pool di applicazioni IIS dell'applicazione Web portal
VMLAB\svcTeams10App
Account del pool di applicazioni IIS dell'applicazione Web teams
Nota
Gli account gestiti in SharePoint Server 2010 non corrispondono agli account di servizio gestiti in Active Directory di Windows Server 2008 R2.
Creare l'applicazione del servizio di ricerca di SharePoint Server
In questo esempio l'applicazione del servizio di ricerca di SharePoint Server verrà configurata in modo che l'applicazione Web appena creata possa essere sottoposta a ricerca per indicizzazione. Creare una nuova applicazione Web del servizio di ricerca di SharePoint Server e posizionare i servizi di ricerca, query e amministrazione nel server applicazioni, in questo esempio vmSP10App01. Per una spiegazione dettagliata della configurazione dell'applicazione del servizio di ricerca, vedere Procedura dettagliata: provisioning dell'applicazione del servizio di ricerca (le informazioni potrebbero essere in lingua inglese).
Nota
I servizi di ricerca vengono posizionati in un singolo server applicazioni solo ai fini della dimostrazione. Una descrizione completa delle opzioni e delle procedure consigliate per la topologia del servizio di ricerca di SharePoint Server 2010 non rientra nell'ambito di questo documento.
Creare l'applicazione Web
Passare ad Amministrazione centrale e selezionare Gestisci applicazioni Web nella sezione Gestione applicazioni. Sulla barra degli strumenti selezionare Nuova e creare l'applicazione Web. Configurare quanto segue:
Selezionare Autenticazione in modalità classica.
Configurare la porta e l'intestazione host per ogni applicazione Web.
Selezionare Negozia come provider di autenticazione.
Nel pool di applicazioni selezionare Crea nuovo pool di applicazioni e quindi l'account gestito creato nel passaggio precedente.
In questo esempio sono state create due applicazioni Web con le impostazioni seguenti:
| Impostazione | http://Portal Web Application | http://Teams Web Application |
|---|---|---|
Autenticazione |
Modalità classica |
Modalità classica |
Sito Web IIS |
Nome: SharePoint - Portal - 80 Porta: 80 Intestazione host: Portal |
Nome: SharePoint - Teams - 5555 Porta: 80 Intestazione host: Teams |
Configurazione sicurezza |
Provider di autenticazione: Negozia Consenti accesso anonimo: No Usa SSL (Secure Sockets Layer): No |
Provider di autenticazione: Negozia Consenti accesso anonimo: No Usa SSL (Secure Sockets Layer): No |
URL pubblico |
http://Portal:80 |
http://Teams:5555 |
Pool di applicazioni |
Nome: SharePoint - Portal80 Account servizio: vmlab\svcPortal10App |
Nome: SharePoint - Teams5555 Account servizio: vmlab\svcTeams10App |
Durante la creazione della nuova applicazione Web, viene anche creata una nuova area, quella predefinita, configurata per l'utilizzo del provider di autenticazione di Windows. Per visualizzare il provider e le relative impostazioni per l'area nella gestione delle applicazioni Web, selezionare innanzitutto l'applicazione Web e quindi fare clic su Provider di autenticazione sulla barra degli strumenti. Nella finestra di dialogo relativa ai provider di autenticazione vengono elencate tutte le aree dell'applicazione Web selezionata insieme al provider di autenticazione di ogni area. Selezionando l'area, verranno visualizzate le opzioni di autenticazione corrispondenti.
Se le impostazioni di Windows non sono state configurate correttamente ed è stato selezionato NTLM quando è stata creata l'applicazione Web, è possibile utilizzare la finestra di dialogo di modifica dell'autenticazione per l'area per passare da NTLM a Negozia. Se non è stata selezionata la modalità classica per l'autenticazione, sarà necessario creare una nuova area estendendo l'applicazione Web a un nuovo sito Web IIS oppure eliminare e ricreare l'applicazione Web.
Creare raccolte siti
Per verificare se l'autenticazione funziona correttamente, sarà necessario creare almeno una raccolta siti in ogni applicazione Web. Poiché la creazione e la configurazione della raccolta siti non ha effetto sulla funzionalità Kerberos, è sufficiente seguire le indicazioni sulla creazione di una raccolta siti in Creare una raccolta siti (SharePoint Foundation 2010).
Per questo esempio sono state configurate due raccolte siti:
| Applicazione Web | Percorso raccolta siti | Modello raccolta siti |
|---|---|---|
http://portal |
/ |
Portale di pubblicazione |
http://teams:5555 |
/ |
Sito del team |
Creare i mapping di accesso alternativo
L'applicazione Web portal verrà configurata per l'utilizzo sia di HTTPS che di HTTP per illustrare il funzionamento della delega con servizi protetti tramite SSL. Per configurare SSL, l'applicazione Web portal necessita di un secondo mapping di accesso alternativo di SharePoint Server per l'endpoint HTTPS.
Per configurare i mapping di accesso alternativo
In Amministrazione centrale fare clic su Gestione applicazioni.
In Applicazioni Web fare clic su Configura mapping di accesso alternativo.
Nell'elenco a discesa Selezionare un insieme di mapping di accesso alternativo selezionare Cambia Insieme di mapping di accesso alternativo.
Selezionare l'applicazione Web portal.
Fare clic su Modifica URL pubblici sulla barra degli strumenti in alto.
In un'area libera aggiungere l'URL HTTPS per l'applicazione Web. Questo URL corrisponderà al nome del certificato SSL che verrà creato nei passaggi successivi.
Fare clic su Salva.
L'URL HTTPS dovrebbe ora essere visibile nell'elenco delle aree dell'applicazione Web.
Configurazione IIS
Installare certificati SSL
Sarà necessario configurare un certificato SSL in ogni istanza di SharePoint Server che ospita il servizio applicazione Web per ogni applicazione Web in cui viene utilizzato SSL. La descrizione della configurazione di un certificato SSL e dell'affidabilità dei certificati non rientra nell'ambito di questo documento. Per informazioni sulle risorse da consultare per la configurazione di certificati SSL in IIS, vedere la sezione relativa alla configurazione SSL in questo documento.
Verificare che l'autenticazione Kerberos sia abilitata
Per verificare che l'autenticazione Kerberos sia abilitata nel sito Web
Aprire Gestione IIS.
Selezionare il sito Web IIS da verificare.
In Visualizzazione funzionalità, in IIS, fare doppio clic su Autenticazione.
Selezionare l'opzione Autenticazione di Windows, che dovrebbe essere abilitata.
Sul lato destro, in Azioni, selezionare Provider e verificare che l'opzione Negozia sia posizionata all'inizio dell'elenco.
Verificare che l'autenticazione in modalità kernel sia disabilitata
L'autenticazione in modalità kernel non è supportata in SharePoint Server 2010. Per impostazione predefinita, per tutte le applicazioni Web SharePoint Server l'autenticazione in modalità kernel deve essere disabilitata nei siti Web IIS corrispondenti. Anche in situazioni in cui l'applicazione Web è stata configurata in un sito Web IIS esistente, SharePoint Server disabilita l'autenticazione in modalità kernel quando effettua il provisioning di una nuova applicazione Web nel sito IIS esistente.
Per verificare che l'autenticazione in modalità kernel sia disabilitata
Aprire Gestione IIS.
Selezionare il sito Web IIS da verificare.
In Visualizzazione funzionalità, in IIS, fare doppio clic su Autenticazione.
Selezionare l'opzione Autenticazione di Windows, che dovrebbe essere abilitata.
Fare clic su Impostazioni avanzate.
Verificare che siano disabilitati sia EAP che l'autenticazione in modalità kernel.
Configurare il firewall
Prima di testare l'autenticazione, verificare che i client possano accedere alle applicazioni Web SharePoint Server sulle porte HTTP configurate. Accertarsi inoltre che i client possano eseguire l'autenticazione in Active Directory e richiedere ticket Kerberos dal centro distribuzione chiavi (KDC, Key Distribution Center) sulle porte Kerberos standard.
Aprire le porte del firewall per consentire il traffico HTTP su porte predefinite e non predefinite
È necessario in genere configurare il firewall in ogni server Web front-end per accettare le richieste in entrata sulle porte TCP 80 e TCP 443. Aprire Windows Firewall con sicurezza avanzata e selezionare le regole in entrata seguenti:
Servizi Web (traffico HTTP in entrata)
Servizi Web (traffico HTTPS in entrata)
Verificare che siano aperte le porte appropriate nell'ambiente in uso. Nell'esempio si accede a SharePoint Server su HTTP (porta 80) e pertanto è stata abilitata questa regola.
È inoltre necessario aprire una porta non predefinita utilizzata nell'esempio (TCP 5555). Se sono presenti siti Web in esecuzione su porte non predefinite, è inoltre necessario configurare regole personalizzate per accettare il traffico HTTP su tali porte.
Verificare che i client possano connettersi alle porte Kerberos nel ruolo Active Directory
Per utilizzare l'autenticazione Kerberos, i client dovranno richiedere ticket di concessione ticket (TGT) e ticket di servizio (ST) del centro distribuzione chiavi sulla porta 88 UDP o TCP. Per impostazione predefinita, quando si installa il ruolo Active Directory in Windows Server 2008 e versioni successive, il ruolo configurerà le regole in entrata seguenti per consentire questo tipo di comunicazione:
Centro distribuzione chiavi Kerberos - PCR (TCP-In)
Centro distribuzione chiavi Kerberos - PCR (UDP-In)
Centro distribuzione chiavi Kerberos (TCP-In)
Centro distribuzione chiavi Kerberos (UDP-In)
Verificare che nell'ambiente queste regole siano abilitate e che i client possano connettersi al centro distribuzione chiavi (controller di dominio) sulla porta 88.
Testare l'autenticazione del browser
Dopo aver configurato Active Directory, DNS e SharePoint Server, è possibile verificare che l'autenticazione Kerberos sia configurata correttamente passando alle applicazioni Web. Quando si eseguono i test nel browser, verificare che vengano soddisfatte le condizioni seguenti:
L'utente del test deve aver eseguito l'accesso al computer Windows XP, Vista o Windows 7 aggiunto al dominio in cui è installato SharePoint Server oppure deve aver eseguito l'accesso a un dominio considerato attendibile dal dominio di SharePoint Server.
L'utente del test deve utilizzare Internet Explorer 7.0 o versioni successive. Internet Explorer 6.0 non è più supportato in SharePoint Server 2010. Vedere Pianificare il supporto browser (SharePoint Server 2010).
Nel browser deve essere abilitata l'autenticazione integrata di Windows. Nella scheda Avanzate in Opzioni Internet verificare che nella sezione Sicurezza sia abilitata l'opzione Abilita autenticazione di Windows integrata*.
La rete Intranet locale deve essere configurata per consentire l'accesso automatico dei client. Nella scheda Sicurezza in Opzioni Internet selezionare Intranet locale e quindi fare clic sul pulsante Livello personalizzato. Scorrere l'elenco verso il basso e verificare che sia selezionata l'opzione Accesso automatico solo nell'area Intranet.
Nota
È possibile configurare l'accesso automatico in altre aree, ma la descrizione delle procedure consigliate per le aree di sicurezza di Internet Explorer esula dall'ambito di questo documento. Per questa dimostrazione verrà utilizzata l'area Intranet per tutti i test.
Verificare che sia selezionata l'opzione Rileva automaticamente rete Intranet in Opzioni Internet->Sicurezza->Intranet locale->Siti.
Se si utilizzano nomi di dominio completo (FQDN) per accedere alle applicazioni Web SharePoint Server, verificare che i nomi FQDN siano inclusi nell'area Intranet in modo esplicito o per inclusione di caratteri jolly, ad esempio "*.vmlab.local".
Il modo più semplice per determinare se viene utilizzata l'autenticazione Kerberos consiste nell'accedere a una workstation di prova e passare al sito Web in questione. Se non viene chiesto di specificare le credenziali dell'utente e il rendering del sito viene eseguito correttamente, è possibile presumere che l'autenticazione integrata di Windows funzioni correttamente. Il passaggio successivo consiste nel determinare se è stato utilizzato il protocollo di negoziazione per negoziare l'autenticazione Kerberos come provider di autenticazione per la richiesta. Questa operazione può essere effettuata nei modi seguenti:
Registri di sicurezza Web front-end
Se l'autenticazione Kerberos funziona correttamente, saranno inclusi eventi di accesso nei registri eventi di sicurezza nei server Web front-end con ID evento = 4624. Nelle informazioni generali relative a questi eventi dovrebbero essere inclusi l'ID di sicurezza registrato nel computer e il processo di accesso utilizzato, che dovrebbe essere Kerberos.
KList
KList è un'utilità da riga di comando inclusa nell'installazione predefinita di Windows Server 2008 e Windows Server 2008 R2 che può essere utilizzata per elencare ed eliminare i ticket Kerberos in un computer specifico. Per eseguire KLIST, aprire una finestra del prompt dei comandi in Windows Server 2008 e digitare Klist.
Se si desidera svuotare la cache dei ticket, eseguire Klist con il parametro facoltativo purge: Klist purge
KerbTray
KerbTray è un'utilità disponibile gratuitamente con Windows Server 2000 Resource Kit Tool che può essere installata nel computer client per visualizzare la cache dei ticket Kerberos. Eseguire il download e l'installazione da Windows 2000 Resource Kit Tool: Kerbtray.exe (le informazioni potrebbero essere in lingua inglese). Al termine dell'installazione, eseguire le azioni seguenti:
Passare ai siti Web in cui viene utilizzata l'autenticazione Kerberos.
Eseguire KerbTray.exe.
Visualizzare la cache dei ticket Kerberos facendo clic con il pulsante destro del mouse sull'icona di KerbTray sulla barra delle applicazioni e scegliendo List Tickets.
Controllare che i ticket di servizio per le applicazioni Web autenticate siano inclusi nell'elenco dei ticket memorizzati nella cache. Nell'esempio sono stati esplorati i siti Web riportati di seguito con gli SPN registrati seguenti:
URL sito Web Nome SPN http://portal
HTTP/Portal.vmlab.local
http://teams:5555
HTTP/Teams.vmlab.local
Fiddler
Fiddler è un analizzatore di traffico HTTP gratuito che può essere scaricato dal percorso seguente: http://www.fiddlertool.com/ (le informazioni potrebbero essere in lingua inglese). In Fiddler sarà possibile osservare il client e il server negoziare l'autenticazione Kerberos e il client inviare i ticket di servizio Kerberos al server nelle intestazioni HTTP in ogni richiesta. Per utilizzare Fiddler per verificare che l'autenticazione Kerberos funzioni correttamente, eseguire le azioni seguenti:
Scaricare e installare Fiddler (www.fiddlertool.com (le informazioni potrebbero essere in lingua inglese)) nel computer client.
Disconnettersi dal desktop e riaccedere per scaricare le eventuali connessioni al server Web memorizzate nella cache e forzare il browser a eseguire l'autenticazione Kerberos e l'handshake di autenticazione.
Avviare Fiddler.
Aprire Internet Explorer e passare all'applicazione Web (http://portal nell'esempio).
Le richieste e le risposte al server Web front-end SharePoint Server dovrebbero essere visibili in Fiddler.
Il primo HTTP 401 è il tentativo del browser di eseguire la richiesta GET senza autenticazione. In risposta il server invia il messaggio HTTP 401 di autorizzazione negata e in questa risposa indica i metodi di autenticazione supportati. Nella richiesta successiva il client invia di nuovo la richiesta precedente, specificando questa volta il ticket di servizio per l'applicazione Web nelle intestazioni della richiesta. Se l'autenticazione viene eseguita, il server invierà la risorsa richiesta.
NetMon 3.4
NetMon 3.4 è un analizzatore di pacchetti di rete gratuito di Microsoft che può essere scaricato dall'Area download Microsoft: Microsoft Network Monitor 3.4 (le informazioni potrebbero essere in lingua inglese).
In NetMon vengono mostrate tutte le richieste e le risposte TCP al centro distribuzioni chiavi e ai server Web SharePoint Server, con una visibilità completa del traffico che costituisce una richiesta di autenticazione completa. Per verificare il corretto funzionamento dell'autenticazione Kerberos con NetMon, eseguire le azioni seguenti:
Scaricare e installare NetMon 3.4 (Microsoft Network Monitor 3.4 (le informazioni potrebbero essere in lingua inglese)).
Disconnettersi dal client e quindi riaccedere per svuotare la cache dei ticket Kerberos. Facoltativamente è possibile utilizzare KerbTray per svuotare la cache dei ticket facendo clic con il pulsante destro del mouse su KerbTray e scegliendo Purge Tickets.
Avviare NetMon in modalità di amministratore. Fare clic con il pulsante destro del mouse sul collegamento di NetMon e scegliere Esegui come amministratore.
Avviare una nuova acquisizione nelle interfacce che si connettono al controller di Active Directory nell'ambiente e i server Web front-end.
Aprire Internet Explorer e accedere all'applicazione Web.
Dopo che è stato eseguito il rendering del sito Web, arrestare l'acquisizione e aggiungere un filtro di visualizzazione per visualizzare i frame per l'autenticazione Kerberos e il traffico HTTP.
Nella finestra dei frame dovrebbe essere visibile il traffico sia HTTP che KerberosV5.
Testare l'autenticazione Kerberos su SSL
Per descrivere chiaramente gli SPN richiesti quando un client accede a una risorsa protetta da SSL, è possibile utilizzare uno strumento come NetMon per catturare il traffico tra il client e il server ed esaminare le richieste di ticket di servizio Kerberos.
Disconnettersi e quindi rieseguire l'accesso al computer client oppure cancellare tutti i ticket Kerberos memorizzati nella cache utilizzando KerbTray.
Avviare una nuova acquisizione NetMon nel computer client. NetMon deve essere avviato con autorizzazioni di amministratore.
Accedere all'applicazione Web utilizzando SSL, in questo esempio https://portal.
Arrestare l'acquisizione NetMon ed esaminare il traffico KerberosV5. Per informazioni su come filtrare la visualizzazione dell'acquisizione, vedere le istruzioni nella sezione NetMon 3.4 di questo articolo.
Cercare la richiesta TGS inviata dal client. Nella richiesta è possibile osservare l'SPN richiesto nel parametro "Sname".
Si noti che il parametro "Sname" è HTTP/portal.vmlab.local e non HTTPS/portal.vmlab.local.
Testare query e indice di ricerca di SharePoint Server
Verificare l'accesso al browser dai server di indicizzazione
Prima di eseguire una ricerca per indicizzazione, accertarsi che il server di indicizzazione possa accedere alle applicazioni Web ed eseguire l'autenticazione. Accedere al server di indicizzazione e aprire le raccolte siti di prova nel browser. Se il rendering dei siti viene eseguito correttamente e non vengono visualizzate finestre di dialogo di autenticazione, andare al passaggio successivo. Se si verificano problemi durante l'accesso ai siti nei browser, tornare ai passaggi precedenti per verificare che tutte le operazioni di configurazione siano state eseguite correttamente.
Caricare il contenuto di esempio ed eseguire una ricerca per indicizzazione
In ogni raccolta siti caricare in una raccolta documenti un documento di base, ovvero un documento facilmente identificabile nella ricerca. Creare ad esempio un documento di testo contenente le parole "alfa, beta, delta" e salvarlo in una raccolta documenti in ogni raccolta siti.
Passare quindi ad Amministrazione centrale SharePoint e avviare una ricerca per indicizzazione completa nell'origine di contenuto Siti di SharePoint locali, in cui per impostazione predefinita dovrebbero essere contenute le due raccolte siti di prova.
Testare il servizio di ricerca
Se l'indicizzazione è stata eseguita correttamente, gli elementi che supportano la ricerca dovrebbero essere visibili nell'indice senza errori nel registro di ricerca per indicizzazione.
Nota
Se è stata configurata l'applicazione profilo utente e viene eseguita una ricerca per indicizzazione nell'archivio dei profili, configurare le autorizzazioni appropriate nell'applicazione profilo utente per consentire all'account di accesso al contenuto di accedere ai dati del profilo. Se le autorizzazioni per l'applicazione profilo utente non sono state configurate, verranno generati errori nei registri di ricerca per indicizzazione in cui viene indicato che non è stato possibile per il crawler accedere al servizio profili perché è stato generato un errore HTTP 401 durante il tentativo di accesso al servizio. L'errore 401 restituito non dipende da Kerberos, bensì dall'account di accesso al contenuto che non dispone delle autorizzazioni per leggere i dati del profilo.
Passare quindi a ogni raccolta siti ed eseguire una ricerca del documento di base. La query di ricerca di ogni raccolta siti deve restituire il documento di base caricato.
Testare la delega Web front-end
Come ultimo passaggio di questo scenario viene utilizzata la web part Visualizzatore RSS in ogni raccolta siti per verificare che la delega funzioni sia localmente che da postazione remota.
Configurare le origini di feed RSS in ogni raccolta siti
Per l'applicazione portal è necessario abilitare i feed RSS nella raccolta siti. Per attivare i feed RSS, seguire le istruzioni fornite in Gestire feed RSS in Office.com.
Dopo l'abilitazione dei feed RSS, creare un nuovo elenco personalizzato e aggiungere una voce di elenco ai fini del test. Scegliere Feed RSS dal menu della barra degli strumenti Elenco per visualizzare il feed RSS. Copiare l'URL del feed da utilizzare nei passaggi successivi.
Eseguire questa operazione per ogni raccolta siti.
Aggiungere le web part Visualizzatore RSS alla home page di ogni raccolta siti
Nell'applicazione portal sarà necessario abilitare le caratteristiche per le raccolte siti SharePoint Server Enterprise per l'utilizzo della web part Visualizzatore RSS. Aggiungere quindi due web part Visualizzatore RSS alla home page. Per la prima web part, configurare l'URL del feed in modo da puntare al feed RSS locale creato nel passaggio precedente. Per la seconda web part, configurare l'URL del feed in modo da puntare all'URL del feed remoto. Al termine, entrambe le web part dovrebbero eseguire correttamente il rendering del contenuto dai feed RSS locale e remoto.