Problemi noti della configurazione Kerberos (SharePoint Server 2010)

SharePoint 2010
 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Esiste un problema noto secondo il quale alcuni client Kerberos (inclusi .NET Framework, Internet Explorer 7 e Internet Explorer 8) non formano correttamente i nomi delle entità servizio (SPN, Service Principal Name) quando tentano di eseguire l'autenticazione in applicazioni Web abilitate per Kerberos configurate su porte non predefinite, ovvero porte diverse dalle porte 80 e 443. La causa del problema è dovuta all'impossibilità per il client di formare correttamente l'SPN nella richiesta TGS specificandolo senza numero di porta (come indicato nel parametro Sname nella richiesta TGS).

Esempio:

Se l'applicazione Web viene eseguita in http://intranet.contoso.com:1234, il client richiederà un ticket per un servizio con un SPN http/intranet.contoso.com anziché http/intranet.contoso.com:1234.

Informazioni dettagliate su questo problema sono disponibili negli articoli seguenti:

Per ovviare a questo problema, registrare gli SPN con e senza numero di porta, ad esempio:

  • http://intranet.contoso.com:12345

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

È consigliabile registrare la porta non predefinita in modo che in caso di risoluzione del problema in un Service Pack o in un hotfix futuro le applicazioni che utilizzano la soluzione alternativa continuino a funzionare.

Si noti che questa soluzione alternativa non funziona se si verificano le condizioni seguenti:

  • Sono presenti più applicazioni Web in esecuzione su una porta non predefinita

  • Le applicazioni Web si associano al nome host del server o alla stessa intestazione host (su porte diverse)

  • I pool di applicazioni IIS dell'applicazione Web utilizzano account di servizio diversi

  • http://server.contoso.com:5000 AppPool Id: contoso\svcA

  • http://server.contoso.com:5001 AppPool Id: contoso\svcB

Se si verificano queste condizioni, applicando le indicazioni fornite per questa soluzione alternativa si otterranno SPN duplicati registrati in account di servizio diversi che interromperanno l'autenticazione Kerberos.

Se sono presenti più siti Web che condividono un nome host comune su più porte e si utilizzano identità di pool di applicazioni IIS diversi per le applicazioni Web, non sarà possibile utilizzare l'autenticazione Kerberos in tutti i siti Web. Un'applicazione potrà utilizzare Kerberos, mentre la altre richiederanno un altro protocollo di autenticazione. Per utilizzare Kerberos in tutte le applicazioni dello scenario, è necessario eseguire una delle operazioni seguenti:

  1. Eseguire tutte le applicazioni Web con un account di servizio condiviso

  2. Eseguire ogni sito con la relativa intestazione host

Esiste un problema noto con alcuni client Kerberos (inclusi Internet Explorer 7 e 8) che tentano di eseguire l'autenticazione in servizi abilitati per Kerberos configurati per la risoluzione con CNAME DNS anziché record A. La causa del problema è dovuta all'impossibilità per il client di formare correttamente l'SPN nella richiesta TGS creando mediante il nome host (record A) anziché il nome di alias (CNAME).

Esempio:

Record A: wfe01.contoso.com

CNAME: intranet.contoso.com (alias wfe01.contoso.com)

Se il client tenta di eseguire l'autenticazione in http://intranet.contoso.com, non formerà correttamente l'SPN e richiederà un ticket Kerberos per http/wfe01.contoso.com anziché http/intranet.contoso.com.

Informazioni dettagliate su questo problema sono disponibili negli articoli seguenti:

https://support.microsoft.com/kb/911149/it

https://support.microsoft.com/kb/938305/it

Per ovviare a questo problema, configurare i servizi abilitati per Kerberos utilizzando record A DNS anziché alias CNAME. L'hotfix citato nell'articolo della Knowledge Base consentirà di risolvere questo problema per Internet Explorer, ma non per .NET Framework (utilizzato da Microsoft Office SharePoint Server per le comunicazioni tra servizi Web).

NotaNote
L'autenticazione in modalità kernel non è supportata nei prodotti SharePoint 2010. Queste indicazioni vengono fornite esclusivamente a scopo informativo.

A partire da IIS versione 7.0 è disponibile una nuova funzionalità di autenticazione denominata autenticazione in modalità kernel. Quando un sito Web IIS viene configurato per l'utilizzo dell'autenticazione in modalità kernel, HTTP.sys autentica le richieste del client anziché il processo di lavoro del pool di applicazioni. Poiché HTTP.sys viene eseguito in modalità kernel, offre prestazioni migliori ma introduce anche alcuni processi complessi per la configurazione Kerberos. HTTP.sys infatti viene eseguito con l'identità del computer e non con l'identità del processo di lavoro. Quando HTTP.sys riceve un ticket Kerberos, per impostazione predefinita tenta di decrittografare il ticket utilizzando la chiave di crittografia del server (nota anche come chiave segreta) e non la chiave dell'identità utilizzata per l'esecuzione del processo di lavoro.

Se un singolo server Web viene configurato per l'utilizzo dell'autenticazione in modalità kernel, Kerberos funziona senza ulteriori attività di configurazione o SPN aggiuntivi poiché il server registra automaticamente un SPN HOST quando viene aggiunto al dominio. In caso di più server Web con carico bilanciato, la configurazione dell'autenticazione in modalità kernel predefinita non funziona o comunque genera errori a intermittenza, poiché il client non può garantire che il ticket di servizio ricevuto nella richiesta TGS funzioni con il server che autentica la richiesta.

Per ovviare a questo problema, è possibile eseguire le operazioni seguenti:

È possibile osservare un aumento del traffico di autenticazione quando si utilizza l'autenticazione Kerberos con IIS 7.0 e versioni successive. Questo problema potrebbe essere correlato alle impostazioni di autenticazione di Windows in IIS, in modo particolare:

 

AuthPersistNonNTLM

Attributo booleano facoltativo.

Specifica se IIS riautentica automaticamente ogni richiesta non NTLM (ad esempio Kerberos), anche nella stessa connessione. True consente più autenticazioni per le stesse connessioni.

Il valore predefinito è False.

NotaNote
False indica che il client verrà autenticato una sola volta nella stessa connessione. IIS memorizzerà nella cache del server un token o ticket per una sessione TCP che rimane attiva.

authPersistSingleRequest

Attributo booleano facoltativo.

L'impostazione di questo flag su True indica che l'autenticazione persiste solo per una singola richiesta in una connessione. IIS reimposta l'autenticazione alla fine di ogni richiesta e forza la riautenticazione alla successiva richiesta della sessione.

Il valore predefinito è False.

Per istruzioni su come configurare la persistenza dell'autenticazione in IIS 7.0, vedere È possibile che si verifichi un rallentamento delle prestazioni se si utilizza l'autenticazione integrata di Windows con il protocollo di autenticazione Kerberos in IIS 7.0 e Implementazione del controllo di accesso (le informazioni potrebbero essere in lingua inglese).

Quando si configura l'autenticazione Kerberos, è possibile che vengano accidentalmente configurati nomi delle entità servizio duplicati, soprattutto se si utilizza SetSPN -A oppure lo strumento ADSI Edit (adsiedit.msc) per creare gli SPN. È consigliabile in genere utilizzare SetSPN -S per la creazione degli SPN, poiché l'opzione -S controlla la presenza di un SPN duplicato prima di creare l'SPN specificato.

Se si sospetta la presenza di SPN duplicati nell'ambiente in uso, utilizzare il comando SetSPN -X per eseguire una query per la ricerca di tutti gli SPN duplicati nell'ambiente (solo Windows 2008 o versioni successive). Se vengono restituiti SPN duplicati, controllare perché sono stati registrati ed eliminare gli eventuali SPN duplicati che non sono necessari. Se si dispone di due servizi eseguiti con due identità diverse ed entrambi utilizzano lo stesso SPN (problema di SPN duplicati), sarà necessario riconfigurare uno dei servizi per l'utilizzo di un SPN diverso o per la condivisione di un'identità del servizio comune.

Se si sospetta che un SPN non sia stato registrato oppure che sia stato registrato in un formato non valido, è possibile utilizzare SetSPN -Q <inserire SPN> per ricercare un SPN specifico.

In alcuni ambienti gli utenti possono essere membri di più gruppi di Active Directory, con un conseguente aumento delle dimensioni dei ticket Kerberos. Se le dimensioni dei ticket aumentano in modo eccessivo, è possibile che l'autenticazione Kerberos abbia esito negativo. Per ulteriori informazioni su come modificare la dimensione massima dei token, vedere Nuova soluzione per i problemi con l'autenticazione Kerberos in caso di utenti appartenenti a più gruppi (https://support.microsoft.com/kb/327825/it).

NotaNote
Quando si modifica la dimensione massima dei token, considerare che se si configura un valore che supera il valore massimo dell'impostazione del Registro di sistema possono verificarsi errori di autenticazione Kerberos. È consigliabile non superare decimali 65535, esadecimali FFFF, come dimensione massima dei token.

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)

Potrebbe essere necessario installare un hotfix per l'autenticazione Kerberos in tutti i computer che eseguono Windows Server 2008 o Windows Vista nell'ambiente in uso. Sono inclusi tutti i computer che eseguono SharePoint Server 2010, SQL Server o Windows Server 2008 in cui SharePoint Server tenta di eseguire l'autenticazione Kerberos. Seguire le istruzioni fornite nella pagina del supporto tecnico per applicare l'hotfix qualora si verifichino i sintomi documentati nel caso in essa illustrato.

Mostra: