Condividi tramite

Panoramica dell'autenticazione Kerberos per prodotti Microsoft SharePoint 2010

  • Articolo

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Nei Prodotti Microsoft SharePoint 2013 sono stati introdotti miglioramenti significativi relativamente alla modalità di gestione dell'identità nella piattaforma. È molto importante comprendere in che modo tali modifiche incidano sulla progettazione delle soluzioni e sulla configurazione della piattaforma per consentire l'utilizzo di scenari che richiedono la delega dell'identità utente a sistemi integrati. Il protocollo Kerberos versione 5 svolge un ruolo fondamentale nel consentire la delega e a volte può essere necessario in questi scenari.

In questa serie di articoli vengono fornite informazioni utili per eseguire le operazioni seguenti:

  • Comprendere i concetti relativi all'identità nei prodotti SharePoint 2010

  • Imparare in che modo l'autenticazione Kerberos riveste un ruolo molto importante negli scenari di autenticazione e delega

  • Identificare le situazioni in cui è opportuno sfruttare l'autenticazione Kerberos oppure in cui può essere necessaria nelle strutture delle soluzioni

  • Configurare l'autenticazione Kerberos end-to-end all'interno dell'ambiente di cui si dispone, inclusi gli scenari per cui vengono utilizzate diverse applicazioni di servizio in SharePoint Server

  • Testare e verificare che l'autenticazione Kerberos sia configurata correttamente e funzioni come previsto

  • Trovare ulteriori strumenti e risorse utili per configurare l'autenticazione Kerberos nell'ambiente di cui si dispone

Questa serie di articoli è raccolta in due sezioni principali:

  • Questa panoramica dell'autenticazione Kerberos nei prodotti SharePoint 2010

    In questo articolo sono contenute informazioni di carattere concettuale su come gestire l'identità nei Prodotti SharePoint 2010, sul protocollo Kerberos e sul ruolo chiave dell'autenticazione Kerberos nelle soluzioni di SharePoint 2010.

  • Configurazione dettagliata

    In questo gruppo di articoli vengono illustrati i passaggi da eseguire per configurare l'autenticazione Kerberos e la delega Kerberos in diversi scenari con soluzioni di SharePoint.

A chi sono destinati questi articoli sull'autenticazione Kerberos

L'identità e la delega nei Prodotti SharePoint 2010 rappresentano un argomento molto vasto, con diversi aspetti da comprendere. In questa serie di articoli l'argomento viene affrontato sia da un punto di vista concettuale che tecnico e viene trattato in modo da soddisfare le esigenze di diversi gruppi di destinatari:

Dall'inizio alla fine

Per sapere tutto il necessario sull'identità e sull'autenticazione Kerberos nei Prodotti SharePoint 2010.

Se ancora non si conoscono i Prodotti SharePoint 2010, l'autenticazione Kerberos e l'autenticazione basata sulle attestazioni, è necessario leggere la prima sezione di questo documento, in cui vengono trattati i concetti di base relativi all'identità e alla delega e in cui vengono presentate le nozioni fondamentali sulle attestazioni e sull'autenticazione Kerberos. Mediante i collegamenti forniti, è inoltre possibile accedere ad articoli esterni e informazioni aggiuntive utili per acquisire una buona conoscenza di base prima di proseguire con gli articoli sulla configurazione dettagliata.

Aggiornamento da Office SharePoint Server 2007

Per conoscere le differenze rispetto alla versione 2007 e prepararsi per l'aggiornamento alla versione 2010.

Se si dispone di un ambiente Microsoft Office SharePoint Server 2007 esistente già configurato per l'utilizzo dell'autenticazione Kerberos e della delega Kerberos, è consigliabile leggere gli articoli seguenti:

  • Scenari di identità nei prodotti SharePoint 2010

  • Nozioni fondamentali sulle attestazioni

  • Differenze relative all'autenticazione Kerberos in Windows 2008 R2 e Windows 7

  • Differenze relative alla configurazione Kerberos nei prodotti SharePoint 2010

  • Considerazioni per l'aggiornamento da Office SharePoint Server 2007

In caso di ulteriori dubbi su come configurare la delega per una determina funzionalità o per un particolare scenario, leggere gli articoli sulla configurazione dettagliata, soprattutto gli elenchi di controllo della configurazione, per essere certi che l'ambiente sia configurato correttamente dopo l'aggiornamento.

Procedura dettagliata

Per avere istruzioni dettagliate su come configurare la delega Kerberos in SharePoint Server e nelle applicazioni di servizio SharePoint Server applicabili.

Negli articoli sulla configurazione dettagliata vengono trattati diversi scenari in cui vengono utilizzati i Prodotti SharePoint 2010 e che possono essere configurati per l'utilizzo della delega Kerberos. Ogni scenario viene illustrato in modo approfondito, fornendo anche un elenco di controllo della configurazione e istruzioni dettagliate per configurare correttamente l'autenticazione Kerberos nell'ambiente in uso. Gli scenari illustrati sono i seguenti:

Leggere interamente il primo scenario relativo alla configurazione di base, in quanto è un prerequisito per tutti gli scenari successivi.

Nota

Negli scenari sono inclusi comandi "SetSPN" che è possibile decidere di copiare dal documento e incollare in una finestra del prompt dei comandi. In tali comandi sono contenuti segni meno. In Microsoft Word è disponibile una funzionalità di formattazione automatica che tende a convertire i segni meno in trattini. Se tale funzionalità è attivata in Word e si tenta di copiare e incollare, i comandi non funzioneranno correttamente. Per ovviare al problema, sostituire i trattini con segni meno. Per disattivare la funzionalità di formattazione automatica in Word, scegliere Opzioni dal menu File, fare clic sulla scheda Strumenti di correzione e quindi aprire la finestra di dialogo Correzione automatica.

Ambienti con prodotti SharePoint 2010 esistenti

Per sapere come verificare la configurazione ed eseguirne il debug se già si dispone di un ambiente con prodotti SharePoint 2010 e non si riesce a far funzionare l'autenticazione Kerberos.

Negli articoli sulla configurazione dettagliata sono inclusi numerosi elenchi di controllo per valutare l'ambiente in uso in diversi scenari. Prestare particolare attenzione allo Scenario 1, Configurazione di base, in cui vengono trattati gli strumenti e le tecniche di base per valutare la configurazione Kerberos.

Scenari di identità nei prodotti SharePoint 2010

Quando si apprende il significato di identità nel contesto dell'autenticazione nei Prodotti SharePoint 2010, è possibile esaminare concettualmente in che modo la piattaforma gestisce l'identità in tre scenari principali, ovvero autenticazione in ingresso, autenticazione tra farm/all'interno della farm e autenticazione in uscita.

Diagramma di autenticazione della farm

Identità in ingresso

Lo scenario di autenticazione in ingresso indica il modo in cui un client presenta la propria identità alla piattaforma, ovvero si autentica nell'applicazione Web o nel servizio Web. SharePoint Server utilizzerà l'identità del client per autorizzarlo ad accedere alle risorse protette di SharePoint Server quali pagine Web, documenti e così via.

I Prodotti SharePoint 2010 supportano due modalità con cui un client può autenticarsi nella piattaforma, ovvero la modalità classica e la modalità attestazioni.

Modalità classica

La modalità classica consente l'utilizzo dei tipici metodi di autenticazione IIS (Internet Information Services) già noti da versioni precedenti di SharePoint Server. Quando un'applicazione Web di SharePoint Server 2010 è configurata per l'utilizzo della modalità classica, è possibile scegliere tra i metodi di autenticazione IIS descritti di seguito.

Autenticazione integrata di Windows

L'autenticazione integrata di Windows consente ai client Windows di eseguire l'autenticazione con SharePoint Server senza che sia necessario specificare manualmente le credenziali, ovvero nome utente e password. Gli utenti che accedono a SharePoint Server da Internet Explorer effettueranno l'autenticazione utilizzando le credenziali con cui viene eseguito il processo Internet Explorer, che per impostazione predefinita sono le credenziali specificate dall'utente per connettersi al desktop. I servizi o le applicazioni che accedono a SharePoint Server con la modalità integrata di Windows tentano di effettuare l'autenticazione utilizzando le credenziali del thread in esecuzione, che per impostazione predefinita corrisponde all'identità del processo.

NTLM

NT LAN Manager (NTLM) è il tipo di protocollo predefinito quando è selezionata l'autenticazione integrata di Windows. Tale protocollo si avvale di una sequenza In attesa/Risposta in tre parti per autenticare i client. Per ulteriori informazioni su NTLM, vedere Microsoft NTLM (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Vantaggi:

  • È facile da configurare e in genere non richiede ulteriori attività di configurazione dell'infrastruttura o dell'ambiente per funzionare.

  • Funziona quando il client non fa parte del dominio o non si trova in un dominio ritenuto attendibile dal dominio in cui risiede SharePoint Server.

Svantaggi:

  • Richiede che SharePoint Server contatti il controller di dominio ogni volta che è necessario convalidare la risposta di autenticazione per un client, aumentando il traffico verso i controller di dominio.

  • Non consente la delega delle credenziali dei client ai sistemi back-end, condizione nota anche come regola del doppio hop.

  • È un protocollo di proprietà.

  • Non supporta l'autenticazione server.

  • È considerato meno sicuro dell'autenticazione Kerberos.

Protocollo Kerberos

Kerberos è un protocollo più sicuro che supporta l'autenticazione tramite ticket. Un server di autenticazione Kerberos concede un ticket in risposta a una richiesta di autenticazione inviata da un computer client, se tale richiesta contiene credenziali utente valide e un nome dell'entità servizio (SPN) valido. Il computer client quindi utilizza il ticket per accedere alle risorse in rete. Perché l'autenticazione Kerberos sia possibile, i computer client e server devono disporre di una connessione di tipo trusted al centro distribuzione chiavi del dominio. Tale centro distribuisce chiavi segrete condivise per consentire la crittografia. I computer client e server devono inoltre essere in grado di accedere ai servizi directory Active Directory. Per Active Directory, il dominio radice della foresta è il centro dei riferimenti di autenticazione Kerberos. Per ulteriori informazioni sul protocollo Kerberos, vedere Funzionamento del protocollo di autenticazione Kerberos versione 5 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) e Microsoft Kerberos (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Vantaggi:

  • È il protocollo più sicuro per l'autenticazione integrata di Windows.

  • Consente la delega delle credenziali dei client.

  • Supporta l'autenticazione reciproca di client e server.

  • Genera meno traffico verso i controller di dominio.

  • È un protocollo aperto supportato da numerose piattaforme e molti fornitori.

Svantaggi:

  • Richiede ulteriori attività di configurazione dell'infrastruttura e dell'ambiente per funzionare correttamente.

  • Richiede che i client dispongano della connettività al centro distribuzione chiavi (controller di dominio Active Directory negli ambienti Windows) sulla porta TCP/UDP 88 (Kerberos) e sulla porta TCP/UDP 464 (Kerberos: Modifica password - Windows).

Altri metodi

Oltre all'autenticazione NTLM e Kerberos, SharePoint Server supporta altri tipi di autenticazione IIS, tra cui l'autenticazione di base, l'autenticazione del digest e l'autenticazione basata su certificati, non trattate in questo documento. Per ulteriori informazioni sul funzionamento di questi protocolli, vedere Metodi di autenticazione supportati in IIS 6.0 (IIS 6.0) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Autenticazione basata sulle attestazioni

Il supporto dell'autenticazione basata sulle attestazioni è una nuova funzionalità nei Prodotti SharePoint 2010 e si basa su Windows Identity Foundation (WIF). In un modello basato sulle attestazioni SharePoint Server accetta una o più attestazioni su un client in fase di autenticazione per identificare e autorizzare tale client. Le attestazioni arrivano sotto forma di token SAML e sono affermazioni relative al client fatte da un'autorità attendibile. Un'attestazione ad esempio può indicare che Francesco è un membro del gruppo Enterprise Admins per il dominio Contoso.com. Se questa attestazione proviene da un provider ritenuto attendibile da SharePoint Server, la piattaforma può utilizzare tali informazioni per autenticare Francesco e autorizzarlo ad accedere alle risorse di SharePoint Server. Per ulteriori informazioni sull'autenticazione basata sulle attestazioni, vedere Guida all'identità basata sulle attestazioni e al controllo di accesso (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Le attestazioni supportate dai Prodotti SharePoint 2010 per l'autenticazione in ingresso sono dei tipi seguenti: attestazioni di Windows, attestazioni di autenticazione basata su moduli e attestazioni SAML.

Attestazioni di Windows

Con l'accesso in modalità attestazioni di Windows, SharePoint Server autentica il client utilizzando l'autenticazione integrata di Windows standard (NTLM/Kerberos) e quindi converte l'identità di Windows risultante in un'identità basata sulle attestazioni.

Attestazioni di autenticazione basata su moduli

In modalità attestazioni di autenticazione basata su moduli SharePoint Server reindirizza il client a una pagina di accesso in cui sono ospitati i controlli di accesso ASP.NET standard. La pagina autentica il client mediante provider di appartenenze e di ruoli ASP.NET, in modo del tutto analogo al funzionamento dell'autenticazione basata su moduli in Office SharePoint Server 2007. Dopo la creazione dell'oggetto identità che rappresenta l'utente, SharePoint Server converte tale identità in un oggetto identità basata sulle attestazioni.

Attestazioni SAML

In modalità attestazioni SAML SharePoint Server accetta i token SAML provenienti da un provider di token di sicurezza esterno attendibile (servizio token di sicurezza). Quando l'utente tenta di eseguire l'accesso (vedere il commento), viene reindirizzato a un provider di attestazioni esterno (ad esempio, il provider di attestazioni Windows Live ID), che autentica l'utente e genera un token SAML. SharePoint Server accetta ed elabora questo token, aggiungendo le attestazioni e creando un oggetto identità basata sulle attestazioni per l'utente.

Per ulteriori informazioni sull'autenticazione basata sulle attestazioni nei Prodotti SharePoint 2010, vedere Identità basata sulle attestazioni di SharePoint (le informazioni potrebbero essere in lingua inglese).

Nota sull'autenticazione basata sulle attestazioni in ingresso e su Attestazioni per il servizio token Windows (C2WTS)

Alcune applicazioni di servizio richiedono l'utilizzo di Attestazioni per il servizio token Windows (C2WTS) di Windows Identity Foundation (WIF) per convertire le attestazioni all'interno della farm in credenziali di Windows per l'autenticazione in uscita. È importante comprendere che C2WTS funziona solo se come metodo di autenticazione in ingresso si utilizza la modalità classica oppure le attestazioni di Windows. Se sono configurate le attestazioni, C2WTS richiede esclusivamente attestazioni di Windows. L'applicazione Web non può utilizzare più forme di attestazioni, altrimenti C2WTS non funzionerà.

Identità all'interno di un ambiente con prodotti SharePoint 2010

Negli ambienti con Prodotti SharePoint 2010 viene utilizzata l'autenticazione basata sulle attestazioni per le comunicazioni all'interno della farm e tra farm con la maggior parte delle applicazioni di servizio SharePoint e dei prodotti integrati con SharePoint, indipendentemente dal meccanismo di autenticazione in ingresso utilizzato. Questo significa che, anche in caso di utilizzo dell'autenticazione classica per eseguire l'autenticazione in una determinata applicazione Web, i prodotti SharePoint convertono l'identità in ingresso in un'identità basata sulle attestazioni per eseguire l'autenticazione nelle applicazioni di servizio SharePoint e nei prodotti in grado di riconoscere attestazioni. Effettuando la standardizzazione secondo il modello basato sulle attestazioni per le comunicazioni all'interno della farm e tra farm, la piattaforma può astrarsi dai protocolli in ingresso utilizzati.

Nota

Alcuni prodotti integrati con SharePoint Server, tra cui SQL Server Reporting Services, non sono in grado di riconoscere attestazioni e non sfruttano l'architettura di autenticazione basata sulle attestazioni all'interno della farm. SharePoint Server può inoltre avvalersi delle attestazioni e della delega Kerberos classica in altri scenari, ad esempio se la web part Visualizzatore RSS è configurata per utilizzare un feed autenticato. Fare riferimento alla documentazione relativa a ogni prodotto o applicazione di servizio per determinare se sia in grado di supportare l'autenticazione basata sulle attestazioni e la delega dell'identità.

Identità in uscita

L'identità in uscita nei Prodotti SharePoint 2010 rappresenta gli scenari in cui i servizi all'interno della farm devono autenticarsi in servizi e sistemi line-of-business esterni. A seconda dello scenario, l'autenticazione può essere eseguita secondo uno dei due modelli concettuali di base descritti di seguito.

Sottosistema attendibile

Nel sottosistema attendibile il servizio front-end autentica e autorizza il client e quindi esegue l'autenticazione con altri servizi back-end, senza passare l'identità del client al sistema back-end. Tale sistema considera attendibile il servizio front-end per eseguire l'autenticazione e l'autorizzazione a nome suo. Il modo più comune per implementare questo modello consiste nell'utilizzare l'account di servizio condiviso per l'autenticazione nel sistema esterno.

Diagramma del sottosistema attendibile

In SharePoint Server questo modello può essere implementato in diversi modi:

  • Mediante l'identità del pool di applicazioni IIS. A tale scopo, in genere nell'applicazione Web viene eseguito codice che eleva le autorizzazioni mentre viene effettuata una chiamata a un sistema esterno. Anche altri metodi, come l'utilizzo di RevertToSelf, possono avvalersi dell'identità del pool di applicazioni per l'autenticazione nei sistemi esterni.

  • Mediante un account di servizio. A tale scopo, in genere le credenziali dell'applicazione vengono archiviate nell'archivio sicuro e quindi vengono utilizzate per l'autenticazione in un sistema esterno. Altri metodi prevedono l'archiviazione delle credenziali dell'account di servizio sotto altre forme, ad esempio come stringhe di connessione incorporate.

  • Mediante l'autenticazione anonima. In questo caso il sistema esterno non richiede alcuna autenticazione. Il servizio SharePoint Server front-end pertanto non deve passare alcuna identità al sistema back-end.

Delega

Nel modello basato sulla delega il servizio front-end innanzitutto autentica il client e quindi ne utilizza l'identità per effettuare l'autenticazione in un altro sistema back-end che esegue la propria autenticazione e autorizzazione.

Diagramma del processo di delega

Nei Prodotti SharePoint 2010 questo modello può essere implementato in diversi modi:

  • Mediante la delega Kerberos. Se il client si autentica nel servizio front-end utilizzando l'autenticazione Kerberos, è possibile utilizzare la delega Kerberos per passare l'identità del client al sistema back-end.

  • Mediante le attestazioni. L'autenticazione basata sulle attestazioni consente il passaggio delle attestazioni del client tra i servizi, purché vi sia una relazione di trust fra i due servizi ed entrambi siano in grado di riconoscere attestazioni.

Nota

La maggior parte delle applicazioni di servizio fornite con SharePoint Server attualmente non consente l'autenticazione basata sulle attestazioni in uscita, ma le attestazioni in uscita sono una funzionalità della piattaforma che verrà sfruttata in futuro. Inoltre, molti dei sistemi line-of-business più comuni oggi non supportano l'autenticazione basata sulle attestazioni in ingresso, pertanto l'autenticazione basata sulle attestazioni in uscita non può essere utilizzata oppure richiede ulteriori attività di sviluppo per funzionare correttamente.

Delega oltre i limiti del dominio e della foresta

Gli scenari descritti in questa serie di articoli sull'autenticazione Kerberos richiedono che il servizio SharePoint Server e le origini dati esterne si trovino nello stesso dominio di Windows, condizione necessaria per la delega vincolata Kerberos. Il protocollo Kerberos supporta due tipi di delega, ovvero la delega di base (non vincolata) e la delega vincolata. La delega di base Kerberos consente di oltrepassare i limiti del dominio in una stessa foresta, ma non di oltrepassare il limite della foresta, indipendentemente dalla relazione di trust. La delega vincolata Kerberos non consente di oltrepassare i limiti del dominio o della foresta in alcuno scenario.

Alcuni servizi SharePoint Server possono essere configurati per l'utilizzo della delega di base Kerberos, mentre altri servizi richiedono l'utilizzo della delega vincolata. Tutti i servizi basati su Attestazioni per il servizio token Windows (C2WTS) devono utilizzare la delega vincolata Kerberos per consentire a C2WTS di avvalersi della transizione di protocollo Kerberos per convertire le attestazioni in credenziali di Windows.

Le applicazioni di servizio e i prodotti seguenti richiedono C2WTS e la delega vincolata Kerberos:

  • Excel Services

  • PerformancePoint Services

  • InfoPath Forms Services

  • Servizi Visio

Le applicazioni di servizio e i prodotti seguenti non hanno questi requisiti e pertanto possono utilizzare la delega di base, se necessario:

  • servizio di integrazione applicativa dei dati e Servizi di integrazione applicativa Microsoft

  • Access Services

  • Microsoft SQL Server Reporting Services (SSRS)

  • Microsoft Project Server 2010

L'applicazione di servizio seguente non consente la delega delle credenziali dei client e pertanto non ha questi requisiti:

  • Microsoft SQL Server PowerPivot per Microsoft SharePoint

Nozioni fondamentali sulle attestazioni

Per un'introduzione ai concetti relativi alle attestazioni e all'autenticazione basata sulle attestazioni, vedere Introduzione alle attestazioni (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) e Identità basata sulle attestazioni di SharePoint (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Nozioni fondamentali sul protocollo Kerberos

Per una panoramica di carattere concettuale sul protocollo Kerberos, vedere Microsoft Kerberos (Windows) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x410) (le informazioni potrebbero essere in lingua inglese), Che cos'è Kerberos (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) e Chiedi al team dei servizi directory - Kerberos per l'amministratore con tante attività da eseguire (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Vantaggi del protocollo Kerberos

Prima di esaminare i dettagli relativi a come configurare SharePoint Server o qualsiasi applicazione Web per l'utilizzo del protocollo Kerberos, è opportuno parlare di tale protocollo in termini generali e dei motivi per cui utilizzarlo.

Vi sono di solito tre motivi principali per utilizzare il protocollo Kerberos:

  1. Delega delle credenziali dei client. Il protocollo Kerberos consente la rappresentazione dell'identità di un client da parte di un servizio, che può quindi passare tale identità ad altri servizi di rete per conto del client. NTLM non consente questo tipo di delega. Tale limitazione di NTLM è nota come "regola del doppio hop". L'autenticazione basata sulle attestazioni, come l'autenticazione Kerberos, può essere utilizzata per delegare le credenziali dei client, ma richiede che l'applicazione back-end sia in grado di riconoscere attestazioni.

  2. Sicurezza. Le funzionalità come la crittografia AES, l'autenticazione reciproca o il supporto dell'integrità e della riservatezza dei dati rendono il protocollo Kerberos più sicuro rispetto a NTLM.

  3. Prestazioni potenzialmente più elevate. L'autenticazione Kerberos richiede meno traffico verso i controller di dominio rispetto a NTLM (a seconda della verifica PAC; vedere Blog del team di supporto per Microsoft Open Specifications - Informazioni sulla convalida PAC di Microsoft Kerberos (le informazioni potrebbero essere in lingua inglese)). Se la verifica PAC è disabilitata o non necessaria, il servizio che autentica il client non deve effettuare una chiamata RPC al controller di dominio (vedere Si verifica un ritardo nel processo di autenticazione utente quando si esegue un'applicazione server a traffico elevato in un membro di dominio in Windows 2000 o Windows Server 2003). L'autenticazione Kerberos inoltre richiede meno traffico tra client e server rispetto a NTLM. I client possono autenticarsi nei server Web con due richieste/risposte rispetto al tipico handshake a tre vie di NTLM. Questo miglioramento tuttavia non è in genere evidente nelle reti a bassa latenza per le singole transazioni, ma può essere rilevato in termini di velocità effettiva globale del sistema. Ricordare che sulle prestazioni dell'autenticazione possono influire diversi fattori ambientali. È pertanto consigliabile testare le prestazioni dell'autenticazione Kerberos e di NTLM nell'ambiente di cui si dispone prima di decidere quale dei due metodi sia migliore.

Questo è solo un elenco parziale dei vantaggi derivanti dall'utilizzo del protocollo Kerberos. Vi sono anche altri motivi, tra cui l'autenticazione reciproca, l'interoperabilità tra le piattaforme e il trust transitivo tra domini. Nella maggior parte dei casi, sono tuttavia la delega e la sicurezza i fattori principali che determinano l'adozione del protocollo Kerberos.

Delega Kerberos, delega vincolata e transizione di protocollo

Il protocollo Kerberos versione 5 nella piattaforma Windows supporta due tipi di delega dell'identità, ovvero la delega di base (non vincolata) e la delega vincolata.

Tipo Vantaggi Svantaggi

Delega di base

  • Consente di oltrepassare i limiti del dominio in una stessa foresta.

  • Richiede meno attività di configurazione rispetto alla delega vincolata.

  • Non supporta la transizione di protocollo.

  • È sicura. Se il servizio front-end viene compromesso, l'identità del client può essere delegata a qualsiasi servizio della foresta che accetti l'autenticazione Kerberos.

Delega vincolata

  • Consente la transizione da un protocollo di autenticazione in ingresso non Kerberos a Kerberos (ad esempio, da NTLM a Kerberos e dalle attestazioni a Kerberos).

  • È più sicura. Le identità possono essere delegate solo a un servizio specifico.

  • Non consente di oltrepassare i limiti del dominio.

  • Richiede ulteriori attività di configurazione.

I servizi abilitati per l'utilizzo di Kerberos possono delegare l'identità più volte tra più servizi e più hop. Mentre un'identità passa da un servizio all'altro, il metodo di delega può cambiare dal tipo di base a quello vincolato, ma non l'inverso. Questo è un importante dettaglio di progettazione da comprendere: se un servizio back-end richiede la delega di base (ad esempio, per oltrepassare i limiti di un dominio), tutti i servizi davanti al servizio back-end dovranno utilizzare la delega di base. Se un qualsiasi servizio front-end utilizza la delega vincolata, il servizio back-end non potrà trasformare il token vincolato in un token non vincolato per oltrepassare i limiti di un dominio.

La transizione di protocollo consente a un servizio di autenticazione abilitato per l'utilizzo di Kerberos (servizio front-end) di convertire un'identità non Kerberos in un'identità Kerberos che è possibile delegare ad altri servizi abilitati per Kerberos (servizio back-end). La transizione di protocollo richiede la delega vincolata Kerberos, pertanto le identità sottoposte a tale transizione non possono oltrepassare i limiti del dominio. A seconda dei diritti utente del servizio front-end, il ticket Kerberos restituito dalla transizione di protocollo può essere un token di identificazione oppure un token di rappresentazione. Per ulteriori informazioni sulla delega vincolata e sulla transizione di protocollo, vedere gli articoli seguenti:

Come procedura consigliata generale, quando è necessaria la delega Kerberos, utilizzare la delega vincolata, se possibile. Se è necessaria la delega oltre i limiti del dominio, tutti i servizi inclusi nel percorso di delega dovranno utilizzare la delega di base.

Differenze relative all'autenticazione Kerberos in Windows 2008 R2 e Windows 7

In Windows Server 2008 R2 e Windows 7 sono state introdotte nuove funzionalità relative all'autenticazione Kerberos. Per una panoramica di tali differenze, vedere Modifiche all'autenticazione Kerberos (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x410) e Miglioramenti di Kerberos (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). È inoltre consigliabile acquisire familiarità con l'autenticazione in modalità kernel di IIS 7.0 (Impostazioni di autenticazione in modalità kernel di Internet Information Services (IIS) 7.0 (le informazioni potrebbero essere in lingua inglese), (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x410) (le informazioni potrebbero essere in lingua inglese)), anche se non è supportata nelle farm di SharePoint Server.

Differenze relative alla configurazione Kerberos nei prodotti SharePoint 2010

La maggior parte dei concetti di base relativi alla configurazione dell'autenticazione Kerberos nei Prodotti SharePoint 2010 è rimasta invariata. È ancora necessario configurare nomi dell'entità servizio, nonché le impostazioni di delega per gli account computer e gli account di servizio. Sono state tuttavia apportate alcune modifiche di cui è opportuno essere a conoscenza:

  • Delega vincolata. È richiesta per i servizi che utilizzano Attestazioni per il servizio token Windows. È necessaria per consentire alla transizione di protocollo di convertire le attestazioni in token di Windows.

  • Applicazioni di servizio. In Office SharePoint Server 2007 i servizi di provider di servizi condivisi richiedono nomi SPN speciali e modifiche del Registro di sistema del server per consentire la delega. Nei Prodotti SharePoint 2010 le applicazioni di servizio utilizzano l'autenticazione basata sulle attestazioni e Attestazioni per il servizio token Windows, pertanto non è più necessario apportare queste modifiche.

  • Windows Identity Foundation (WIF). Attestazioni per il servizio token Windows (C2WTS) di WIF è un nuovo servizio di cui si avvalgono i Prodotti SharePoint 2010 per convertire le attestazioni in token di Windows per gli scenari di delega.

Considerazioni per l'aggiornamento da Office SharePoint Server 2007

Se si sta aggiornando una farm di Office SharePoint Server 2007 a SharePoint Server 2010, è necessario considerare diversi aspetti per l'esecuzione dell'aggiornamento:

  • Se le applicazioni Web cambiano URL, ricordarsi di aggiornare i nomi dell'entità servizio in base ai nomi DNS.

  • Eliminare i nomi dell'entità servizio di provider di servizi condivisi perché non sono più necessari in SharePoint Server 2010.

  • Avviare Attestazioni per il servizio token Windows nei server in cui sono in esecuzione le applicazioni di servizio che richiedono la delega, ad esempio Excel Services e Servizio grafica di Visio.

  • Configurare la delega vincolata Kerberos con "utilizzo di qualsiasi protocollo di autenticazione" per consentire la delega vincolata Kerberos con C2WTS.

  • Assicurarsi che l'autenticazione in modalità kernel sia disabilitata in IIS.