Configurazione dell'autenticazione Kerberos per i server Accesso client con bilanciamento del carico

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

Per utilizzare l'autenticazione Kerberos su un array con carico bilanciato di server Accesso client, devono essere completate alcune operazioni di configurazione. Per ulteriori informazioni sull'utilizzo di Kerberos con un array di server Accesso client o una soluzione di bilanciamento del carico, vedere Utilizzo di Kerberos con un array del server Accesso client o una soluzione con carico bilanciato.

Creazione della credenziale di account del servizio alternativo in Active Directory

Tutti i computer all'interno dell'array di server Accesso client devono condividere lo stesso account del servizio. Inoltre, anche tutti i server Accesso client che possono essere richiamati in uno scenario di attivazione datacenter devono condividere lo stesso account del servizio. In generale, è sufficiente disporre di un solo account del servizio per ogni foresta. Questo account viene definito "credenziale di account del servizio alternativo" (credenziale ASA).

Tipo di credenziale

Per l'account del servizio alternativo, è possibile creare un account computer o un account utente. Poiché non consente l'accesso interattivo, un account computer utilizza criteri di sicurezza più semplici di un account utente ed è quindi la soluzione preferita per le credenziali ASA. Se si crea un account computer, la password in realtà non scade, ma si consiglia comunque di aggiornarla periodicamente. Il criterio di gruppo locale può specificare una validità massima per gli account computer e potrebbero essere presenti script pianificati per eliminare periodicamente gli account computer che non soddisfano i criteri correnti. L'aggiornamento periodico della password garantirà la non eliminazione degli account computer che non soddisfano il criterio locale. Il criterio di sicurezza locale determinerà quando deve essere modificata la password.

Nome della credenziale

Non sono previsti requisiti specifici per il nome della credenziale ASA. È possibile utilizzare qualsiasi nome conforme allo schema di denominazione.

Gruppi e ruoli

La credenziale ASA non richiede privilegi speciali di sicurezza. Se si distribuisce un account computer per le credenziali ASA, è sufficiente che l'account sia membro del gruppo di sicurezza Domain Computers. Se si distribuisce un account utente per le credenziali ASA, è sufficiente che l'account sia membro del gruppo di sicurezza Domain Users.

Password

La password fornita al momento della creazione dell'account in realtà non verrà mai utilizzata: la password verrà reimpostata dallo script. In questo modo, quando si crea l'account, è possibile utilizzare qualsiasi password conforme ai requisiti dell'organizzazione.

Scenari tra foreste

Se si dispone di una distribuzione tra foreste o a foresta di risorse e gli utenti si trovano all'esterno della foresta di Active Directory contenente Exchange, è necessario configurare i trust tra foreste e i suffissi dei nomi di routing tra foreste. Per ulteriori informazioni, vedere Accesso alle risorse negli insiemi di strutture e Routing dei suffissi nome negli insiemi di strutture.

Individuazione dei nomi principali di servizio da associare alle credenziali dell'account del servizio alternativo

Una volta creato l'account del servizio alternativo, è necessario stabilire i nomi principali di servizio (SPN) di Exchange da associare alle credenziali ASA. L'elenco dei nomi principali di servizio di Exchange può variare in base alla configurazione, ma deve includere almeno i seguenti elementi.

• http Utilizzare questo SPN per i Servizi Web Exchange, i download della Rubrica offline e il servizio di individuazione automatica.

• exchangeMDB Utilizzare questo SPN per l'accesso client RPC.

• exchangeRFR Utilizzare questo SPN per il servizio Rubrica.

• exchangeAB Utilizzare questo SPN per il servizio Rubrica.

I valori SPN devono essere configurati in modo che il nome corrisponda a quello utilizzato sul servizio di bilanciamento del carico della rete invece che sui singoli server.

Per consentire una pianificazione degli SPN da distribuire, considerare i seguenti scenari:

1. Sito singolo di Active Directory

2. Più siti di Active Directory

3. Più siti di Active Directory con resilienza del sito DAG

In ciascuno di questi scenari, si ipotizza che i nomi di dominio completi con bilanciamento del carico siano stati distribuiti per gli URL interni, gli URL esterni e gli URL di individuazione automatica utilizzati dai membri del server Accesso client. Per ulteriori informazioni, vedere Concetti relativi all'inoltro e al reinstradamento.

Sito singolo di Active Directory

Se si dispone di un sito singolo di Active Directory, l'ambiente potrebbe assomigliare a quello riportato nella seguente illustrazione.

Sulla base dei nomi di dominio completi utilizzati dai client interni di Outlook nell'illustrazione precedente, gli SPN seguenti dovrebbero essere distribuiti sulle credenziali ASA:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

I client esterni o su Internet che utilizzano Outlook via Internet non utilizzeranno l'autenticazione Kerberos. Di conseguenza, i nomi di dominio completi che sono utilizzati da questi client non devono essere aggiunti come SPN alle credenziali ASA.

Più siti di Active Directory

Se si dispone di più siti di Active Directory, l'ambiente potrebbe assomigliare a quello riportato nella seguente illustrazione.

Sulla base dei nomi di dominio completi utilizzati dai client interni di Outlook nell'illustrazione precedente, gli SPN seguenti dovrebbero essere distribuiti sulle credenziali ASA utilizzate dall'array del server Accesso client presso il sito ADSite1 di Active Directory:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

Sulla base dei nomi di dominio completi utilizzati dai client interni di Outlook nell'illustrazione precedente, gli SPN seguenti dovrebbero essere distribuiti sulle credenziali ASA utilizzate dall'array del server Accesso client all'interno del sito ADSite2 di Active Directory:

• http/mailsdc.corp.contoso.com

• http/autodsdc.corp.contoso.com

• exchangeMDB/outlooksdc.corp.contoso.com

• exchangeRFR/outlooksdc.corp.contoso.com

• exchangeAB/outlooksdc.corp.contoso.com

Più siti di Active Directory con resilienza del sito DAG

Se si dispone di più siti di Active Directory con resilienza del sito DAG, l'ambiente potrebbe assomigliare a quello riportato nella seguente illustrazione.

Poiché questa architettura comprende un gruppo di disponibilità del database (DAG) che si estende su entrambi i siti Active Directory, è necessario distribuire una singola credenziale ASA che venga utilizzata dai membri degli array di server Accesso client in ADSite1 e ADSite2. Se non si utilizza una singola credenziale ASA, i client avranno problemi di autenticazione Kerberos quando si eseguirà un passaggio tra datacenter perché i membri degli array del server Accesso client del datacenter secondario non riusciranno a decrittare il ticket della sessione Kerberos. Per ulteriori informazioni sull'attivazione del datacenter secondario, vedere Passaggi centro dati.

Sulla base dei nomi di dominio completi utilizzati dai client interni di Outlook nell'illustrazione precedente, gli SPN seguenti dovrebbero essere distribuiti sulle credenziali ASA utilizzate dagli array di server Accesso client in ADSite1 o ADSite2:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

• http/mailsdc.corp.contoso.com

• http/autodsdc.corp.contoso.com

• exchangeMDB/outlooksdc.corp.contoso.com

• exchangeRFR/outlooksdc.corp.contoso.com

• exchangeAB/outlooksdc.corp.contoso.com

Conversione della directory virtuale della Rubrica offline in un'applicazione

Inizialmente, la directory virtuale della Rubrica offline non è una applicazione Web, per cui non può essere controllata dal servizio Microsoft Exchange Service Host. Tuttavia, le richieste di autenticazione Kerberos rivolte alla directory virtuale della Rubrica offline non possono essere decrittografate dalle credenziali ASA.

Per convertire la directory virtuale della Rubrica offline in un'applicazione Web, eseguire lo script ConvertOABDir.ps1 su ciascun membro server Accesso client. Lo script crea anche un nuovo pool di applicazioni per la directory virtuale della Rubrica offline. Lo script si trova nella directory degli script di Exchange 2010 SP2 o può essere scaricato qui.

Distribuzione delle credenziali dell'account del servizio alternativo

Dopo aver creato le credenziali ASA, verificare che l'account si sia replicato su tutti i controller di dominio all'interno di tutti i siti Active Directory contenenti i server Accesso client che utilizzeranno le credenziali ASA.

È possibile eseguire lo script di credenziali AlternateServiceAccount in Exchange Management Shell. Per ulteriori informazioni, vedere Utilizzo dello script RollAlternateserviceAccountCredential.ps1 in Shell. Una volta eseguito lo script, si consiglia di verificare che tutti i server di destinazione siano stati correttamente aggiornati.

Per consentire la risoluzione dei problemi relativi agli errori di script, vedere Risoluzione dei problemi dello script RollAlternateServiceAccountCredential.ps1.

Il seguente output di esempio dello script RollAlternateServiceAccountPassword.ps1 utilizza un account computer creato come credenziali ASA. Il nome dell'account è contoso/newSharedServiceAccountName. Nel seguente esempio, lo script applica le impostazioni delle credenziali a ciascun membro di un array di server Accesso client chiamato outlook.corp.contoso.com.

Per eseguire lo script, utilizzare il comando seguente.

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

Una volta eseguito lo script, si riceverà il seguente output. Appare un messaggio che chiede di confermare la modifica della password.

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

Nel registro eventi appariranno inoltre due ID evento. Un evento indica l'inizio dello script e l'altro il completamento riuscito. Viene riportato un estratto dell'evento di completamento riuscito.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Verifica della distribuzione delle credenziali ASA

In Exchange Management Shell, eseguire il comando seguente per verificare le impostazioni sui server Accesso client.

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Il risultato di questo comando dovrebbe essere simile al seguente.

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

Se lo script è stato eseguito diverse volte e sono state apportate delle modifiche, la voce Precedente mostrerà quando è stata apportata l'ultima modifica.

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Associazione dei nomi principali di servizio alle credenziali dell'account del servizio alternativo

Prima di configurarli, verificare che i nomi principali del servizio di destinazione non siano già configurati su un altro account della foresta. Le credenziali ASA devono essere l'unico account della foresta associato a questi nomi principali di servizio. È possibile verificare che nessun altro account della foresta sia già associato agli stessi nomi principali di servizio eseguendo il comando setspn con i parametri –q e –f dalla riga di comando. Nell'esempio seguente viene mostrato come eseguire questo comando. Il comando non dovrebbe restituire nulla. Se restituisce un valore, al nome principale del servizio che si intende utilizzare è già associato un altro account.

Setspn -q -f exchangeMDB/outlook.corp.contoso.com

Il seguente comando offe un esempio di come impostare i nomi principali di servizio sulle credenziali ASA condivise. Il comando setspn con questa sintassi deve essere eseguito una volta per ogni nome principale del servizio che si individua.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

Una volta impostati, verificare che i nomi principali del servizio siano stati aggiunti utilizzando il comando seguente.

Setspn -L contoso\newSharedServiceAccountName$

Convalida dell'autenticazione Kerberos dei client Exchange

Una volta configurata l'autenticazione Kerberos e distribuito lo script RollAlternateServiceAccountPasswordl.ps1, verificare la corretta autenticazione dei client.

Verifica che il servizio Service Host di Microsoft Exchange sia in esecuzione

Il servizio Service Host di Microsoft Exchange sui server Accesso client Access è responsabile della gestione delle credenziali ASA. Se questo servizio non è in esecuzione, l'autenticazione Kerberos non sarà possibile. Per impostazione predefinita, il servizio è configurato per avviarsi automaticamente quando viene avviato il computer. Verificare che sia stato installato Exchange Server 2010 SP1 Rollup 3 o versione successiva su tutti i server Accesso client dell'ambiente.

Convalida dell'autenticazione da Outlook

Per garantire la capacità di Outlook di connettersi ai server Accesso client con l'autenticazione Kerberos, attenersi alla seguente procedura: 

1. Confermare la configurazione di Outlook in modo che punti al corretto array di server Accesso client con carico bilanciato.

2. Configurare le impostazioni di sicurezza del server degli account di posta elettronica per utilizzare la sicurezza di accesso alla rete Autenticazione Negotiate. In alternativa, è possibile configurare il cliente per utilizzare Autenticazione password Kerberos. Tuttavia, se per caso vengono rimossi i nomi principali di servizio, i client non saranno più in grado di eseguire l'autenticazione finché non verrà reimpostato il meccanismo Autenticazione Negotiate.

3. Verificare che Outlook via Internet non sia abilitato per il client. Se Outlook non riesce a eseguire l'autenticazione utilizzando Kerberos, cercherà di utilizzare automaticamente Outlook via Internet, quindi Outlook via Internet deve essere disabilitato per questo test.

4. Riavviare Outlook.

5. Se sul computer desktop è in esecuzione Windows 7,è possibile eseguire klist.exe per vedere quali ticket Kerberos sono stato concessi e sono in uso. Se non si dispone di Windows 7, si può reperire klist.exe in Windows Server 2003 Resource Kit.

Convalida tramite il cmdlet Test-OutlookConnectivity

Per verificare il funzionamento di Kerberos, utilizzare il cmdlet Test-OutlookConnectivity. Si tratta del modo migliore per vedere se è possibile stabilire la connettività TCP. Per impostazione predefinita, il cmdlet utilizzerà l'autenticazione Negotiate per una connessione TCP. Quindi, se è configurata, verrà utilizzata Kerberos. Il file klist.exe può essere utilizzato per visualizzare i ticket Kerberos sul computer. Può essere eseguito dal server Accesso client stesso, nonché da uno strumento di monitoraggio automatico come SCOM. Quando si utilizza il cmdlet Test-OutlookConnectivity, assicurarsi che la proprietà RPCClientAccessServer per il database delle cassette postali sia impostata sul nome dell'array di server Accesso client. In caso contrario, il cmdlet non verificherà la funzionalità delle credenziali ASA condivise.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

Per assicurarsi che la connessione venga eseguita utilizzando Kerberos, visualizzare klist.exe e verificare la presenza dei ticket Kerberos associati ai nomi principali di servizio che sono stati aggiunti.

Convalida di Kerberos dal server Accesso client

Per confermare il corretto funzionamento di Kerberos dal server Accesso client, è possibile esaminare i registri di protocollo per verificare le corrette connessioni di Kerberos. Oltre alle altre convalide, è possibile utilizzare questi registri per confermare l'utilizzo di Kerberos.

• Sul server Accesso client, esaminare i registri di protocollo della rubrica. Questi registri in genere si trovano nel seguente percorso: C:\Programmi\Microsoft\Exchange server\v14\Logging\AddressBook Service.

• Una volta eseguito lo script, esaminare l'ultimo file di registro e individuare il termine Kerberos. Se viene visualizzato il traffico Kerberos, la connessione è stata eseguita correttamente. La riga nel file di registro deve essere simile a quella seguente.

  2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,
  

Se viene visualizzato il termine Kerberos, il server sta creando correttamente le connessioni autenticate Kerberos. Per ulteriori informazioni sul registro di servizio della rubrica, vedere Informazioni sul servizio Rubrica.

Risoluzione dei problemi relativi agli errori di autenticazione

Durante la configurazione dell'autenticazione Kerberos, possono verificarsi diversi problemi.

Impossibile connettere i client Outlook configurati per l'utilizzo solo dell'autenticazione Kerberos

Se il client Outlook configurato per utilizzare solo l'autenticazione Kerberos non riesce a connettersi, attenersi alla seguente procedura di risoluzione dei problemi: 

1. Configurare Outlook in modo che utilizzi solo l'autenticazione NTLM, quindi controllare la connettività. Se la connessione non può essere eseguita, verificare la disponibilità dell'array di server Accesso client o la stabilità della connettività di rete.

   Se la connettività NTLM riesce, ma Kerberos no, verificare che i nomi principali del servizio non siano già registrati per qualche altro account diverso da quello del servizio alternativo. Assicurarsi che i nomi principali del servizio di Exchange siano registrati per l'account utilizzato dall'account del servizio alternativo condiviso utilizzando il comando di query setSPN come descritto in precedenza in questo argomento.

2. Assicurarsi che la password sia coordinata tra tutti i server Accesso client e Active Directory. Per effettuare questa operazione, eseguire lo script manualmente e creare una nuova password.

3. Verificare l'esecuzione del servizio Rubrica di Microsoft Exchange sui server Accesso client.

4. Se l'autenticazione ancora non riesce, assicurarsi che l'autenticazione integrata di Windows sia abilitata sulle directory virtuali per i servizi a cui si desidera accedere con Kerberos. Per verificare i metodi di autenticazione, è possibile utilizzare i cmdlet Get-VirtualDirectory. Per ulteriori informazioni sulle directory virtuali, vedere Informazioni sulle directory virtuali di Outlook Web App e Informazioni sulle directory virtuali di Servizi Web di Exchange.

Errori del servizio di individuazione automatica

Se si nota il seguente errore, probabilmente l'intestazione della richiesta per il servizio di individuazione automatica contiene un ticket dell'autenticazione Kerberos che ha superato il limite di dimensioni configurato dal server IIS (Internet Information Services). L'errore sarà simile a quello seguente.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Per correggere l'errore, aumentare le dimensioni massime per l'intestazione IIS. Per ulteriori informazioni, vedere Documentazione di IIS.

Manutenzione costante della credenziale ASA

Se la password locale per la credenziale ASA condivisa deve essere aggiornata periodicamente, vedere Utilizzo dello script RollAlternateserviceAccountCredential.ps1 in Shell per le istruzioni sull'impostazione di un'attività pianificata che esegua la manutenzione regolare della password. Controllare l'attività pianificata per garantire il rollover sistematico della password ed evitare possibili interruzioni dell'autenticazione.

Disattivazione dell'autenticazione Kerberos

Per ripristinare l'array di server Accesso client in modo che non utilizzi Kerberos, rimuovere i nomi principali del servizio dall'account di servizio condiviso. Se i nomi principali del servizio vengono rimossi, i client non potranno tentare l'autenticazione Kerberos e i quelli configurati per l'utilizzo dell'autenticazione Negotiate utilizzeranno NTLM. I client configurati per l'utilizzo solo di Kerberos non potranno eseguire la connessione. Una volta rimossi i nomi principali del servizio, è necessario eliminare anche l'account di servizio condiviso. È possibile utilizzare lo script di manutenzione per eliminare le credenziali da tutti i membri dell'array di server Accesso client utilizzando il parametro toEntireForest e utilizzando il parametro -copy from server per specificare un server che non dispone di alcuna credenziale Kerberos. Inoltre, tutti i computer client dovranno essere infine riavviati per cancellare la cache dei ticket Kerberos.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.