Autenticazione Kerberos per la connessione del client MAPI a un array di server di accesso client

Riepilogo

Per le distribuzioni di Microsoft Exchange Server 2010 con più server Accesso client in un sito di Active Directory, la topologia richiede spesso una matrice di server Accesso client e una soluzione di bilanciamento del carico per distribuire il traffico tra tutti i server Accesso client nel sito. A causa delle modifiche apportate a Exchange Server 2010, i client di posta elettronica MAPI non possono usare l'autenticazione Kerberos per connettersi a una cassetta postale quando viene usato un array del server Accesso client. Per ovviare a questo comportamento, Microsoft Exchange Server Service Pack 1 (SP1) include nuove funzionalità che consentono di configurare l'autenticazione Kerberos per i client di posta elettronica MAPI in un array del server Accesso client.

Per altre informazioni sul funzionamento dell'autenticazione Kerberos nelle versioni precedenti di Exchange Server e sulle modifiche apportate a Exchange Server 2010 che impediscono l'uso dell'autenticazione Kerberos con i client di posta elettronica MAPI, vedere il post di blog seguente nel blog del team di Exchange:

Raccomandazione: Abilitazione dell'autenticazione Kerberos per i client MAPI

Ulteriori informazioni

Il servizio host di Microsoft Exchange che viene eseguito nel ruolo del server di accesso client (CAS) è stato esteso in Exchange Server 2010 SP1 per utilizzare una credenziale di servizio alternativo condiviso (ASA) per l'autenticazione Kerberos. Questa estensione host del servizio monitora il computer locale. Quando le credenziali vengono aggiunte o rimosse, il pacchetto di autenticazione Kerberos nel sistema locale e il contesto del servizio di rete viene aggiornato. Non appena viene aggiunta una credenziale al pacchetto di autenticazione, tutti i servizi di accesso client possono usarla per l'autenticazione Kerberos. Il server Accesso Client sarà anche in grado di autenticare direttamente le richieste di servizio, oltre a poter usare le credenziali ASA. Questa estensione, nota come servicelet, viene eseguita per impostazione predefinita e non richiede alcuna configurazione o azione per l'esecuzione.

Potrebbe essere necessario usare l'autenticazione Kerberos per l'organizzazione di Exchange Server 2010 per i motivi seguenti:

• L'autenticazione Kerberos è necessaria per i criteri di sicurezza locali.

• Si verificano o si prevedono problemi di scalabilità NTLM, come ad esempio il fallimento intermittente di NTLM causato dalla connettività MAPI diretta al servizio di Accesso client RPC.

  Nelle distribuzioni dei clienti su larga scala, NTLM possono causare colli di bottiglia nei server Accesso Client. Ciò può causare errori di autenticazione intermittenti. I servizi che usano l'autenticazione NTLM sono più sensibili ai problemi di latenza di Active Directory. Questi comportano errori di autenticazione quando aumenta la frequenza delle richieste del server Accesso client.

Per configurare l'autenticazione Kerberos, è necessario avere familiarità con Active Directory e sapere come configurare gli array del server di Accesso Client. È anche necessario avere una conoscenza funzionante dell'autenticazione Kerberos.

Per distribuire le credenziali ASA per l'autenticazione Kerberos, seguire questa procedura.

Creare un account da usare come credenziale ASA

Tutti i computer nell'array del server Accesso client devono condividere lo stesso account di servizio. Sono inclusi tutti i server di accesso client che possono essere avviati come parte di un passaggio al data center. In genere, è sufficiente un account di servizio per foresta.

Creare un account computer anziché un account utente per l'account del servizio alternativo (ASA), perché un account computer non consente l'accesso interattivo. Pertanto, un account computer può avere criteri di sicurezza più semplici rispetto a un account utente ed è la soluzione preferita per le credenziali ASA.

Per altre informazioni su come creare un account computer, vedere Creare un nuovo account computer.

Annotazioni

Quando si crea un account computer, la password non scade. È tuttavia consigliabile aggiornare periodicamente la password. Il Criterio di gruppo locale può specificare un'età massima per gli account computer, e gli amministratori di rete possono pianificare script per eliminare periodicamente gli account computer che non soddisfano le politiche attuali. Per assicurarsi che gli account del computer non vengano eliminati se non soddisfano i criteri locali, aggiornare periodicamente le password degli account del computer. I criteri di sicurezza locali determineranno quando è necessario modificare la password.

Annotazioni

La password specificata quando si crea l'account non viene mai effettivamente usata. Lo script reimposta invece la password. Quando si crea l'account, è possibile usare qualsiasi password che soddisfi i requisiti delle password dell'organizzazione.

Non sono previsti requisiti specifici per il nome della credenziale asa. È possibile usare qualsiasi nome che segue lo schema di denominazione. Le credenziali asa non necessitano di privilegi di sicurezza speciali. Se si distribuisce un account computer per le credenziali ASA, significa che l'account deve essere semplicemente un membro del gruppo di sicurezza Computer del dominio. Se si distribuisce un account utente per le credenziali asa, significa che l'account deve essere solo un membro del gruppo di sicurezza Domain Users.

Determinare i nomi SPN da associare alla credenziale dell'account del servizio alternativo

Dopo aver creato l'account del servizio alternativo, è necessario determinare i nomi dell'entità servizio (SPNs) di Exchange che verranno associati alle credenziali ASA. I valori SPN devono essere configurati in modo che corrispondano al nome del servizio usato nel servizio di bilanciamento del carico di rete anziché in singoli server. L'elenco dei nomi SPN di Exchange può variare in base alla configurazione, ma l'elenco deve includere almeno quanto segue:

• http Utilizzare questo SPN per i servizi Web di Exchange, i download della Rubrica offline e il servizio di individuazione automatica.
• exchangeMDB Usare questo SPN per l'accesso client RPC.
• exchangeRFR Utilizzare questo SPN per il servizio Rubrica.
• exchangeAB Utilizzare questo SPN per il servizio Rubrica.

Per un'azienda di piccole dimensioni, probabilmente non si avrà nulla di più grande di un singolo sito di Active Directory. Ad esempio, il singolo sito di Active Directory può essere simile al diagramma seguente.

Per determinare i nomi SPN usati in questo esempio, è necessario esaminare i nomi di dominio completi (FQDN) utilizzati dai client di Outlook interni nella figura precedente. In questo esempio si distribuiscono i seguenti SPN nelle 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

Annotazioni

I client esterni o basati su Internet che usano Outlook Via Internet non useranno l'autenticazione Kerberos. Non è quindi necessario aggiungere i nomi di dominio completi usati da questi client come SPN alle credenziali ASA.

Se il sito è maggiore di un singolo sito di Active Directory, è possibile visualizzare altri esempi nell'argomento Configurazione dell'autenticazione Kerberos per i server di accesso client con carico bilanciato .

Convertire la directory virtuale dell'OAB in un'applicazione

La directory virtuale dell'indirizzo offline (OAB) non è un'applicazione web. Pertanto, non è controllato dal servizio host del servizio Microsoft Exchange. Di conseguenza, le credenziali ASA non possono decrittografare le richieste di autenticazione Kerberos alla directory virtuale dell'OAB.

Per convertire la directory virtuale OAB in un'applicazione Web IIS, eseguire lo script ConvertOABVDir.ps1 su ogni membro del server CAS. Lo script creerà anche un nuovo pool di applicazioni denominato MSExchangeOabAppPool per la directory virtuale della rubrica offline (OAB). Per scaricare lo script, passare alla pagina ConvertOABDir.ps1 in Microsoft Script Center.

Distribuire le credenziali ASA ai membri del CAS

Exchange Server 2010 SP1 include uno script per abilitare la distribuzione delle credenziali ASA. Lo script è denominato RollAlternateServiceAccountPassword.ps1 e si trova nella directory Scripts.

Per utilizzare lo script per trasmettere le credenziali a tutti i server di accesso client nella foresta di dominio per la configurazione iniziale, seguire questa procedura:

1. In Exchange Management Shell eseguire il comando seguente:

   .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose
   

2. Eseguire il comando seguente per pianificare un'attività programmata per il rollback automatico delle password una volta al mese denominata "Exchange-RollAsa". Questa attività pianificata dai comandi aggiornerà le credenziali ASA per tutti i server Accesso client nella foresta con una nuova password generata dallo script. L'attività pianificata viene creata, ma lo script non viene eseguito. Quando l'attività pianificata viene eseguita, lo script viene eseguito in modalità automatica.

   .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"
   

Per altre informazioni su come usare lo script RollAlternateserviceAccountPassword.ps1, vedere Uso dello script RollAlternateserviceAccountPassword.ps1 nella shell .

Verificare l'implementazione delle credenziali ASA

In Exchange Management Shell eseguire il comando seguente per controllare le impostazioni nei server Accesso client: Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Il risultato di questo comando sarà 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>

Associare gli SPN alla credenziale ASA

Prima di configurare gli SPN, assicurati che gli SPN di destinazione non siano già configurati su un account diverso nella foresta. Le credenziali ASA devono essere l'unico account nella foresta a cui sono associati questi SPN. È possibile verificare che nessun altro account nella foresta abbia gli SPN associati ad esso aprendo una finestra di comando ed eseguendo il comando setspn con i parametri –q e –f. Nell'esempio seguente viene illustrato come eseguire questo comando. Il comando non deve restituire nulla. Se restituisce un valore, un altro account è già associato al nome principale di servizio (SPN) che si vuole usare.

Annotazioni

È possibile usare solo il parametro wide della foresta di controllo duplicato (-f) insieme al comando setspn nei computer che eseguono Windows Server 2008.

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

In questo comando, exchangeMDB/outlook.domain.domain.domain_root è l'SPN per l'accesso client RPC, come exchangeMDB/outlook.corp.contoso.com.

Il comando seguente illustra come impostare gli SPN nelle credenziali ASA condivise. È necessario eseguire il comando setspn con questa sintassi una volta per ognuno SPN di destinazione identificato.

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

Dopo aver impostato i nomi SPN, verificare che siano stati aggiunti eseguendo il comando seguente.

Setspn -L contoso\newSharedServiceAccountName

Dopo aver configurato Kerberos e distribuito lo script RollAlternateServiceAccountPasswordl.ps1, verificare che i computer client possano eseguire correttamente l'autenticazione.

Verificare che il servizio host del servizio Microsoft Exchange sia in esecuzione

Assicurarsi di aver installato Exchange Server 2010 SP1 Rollup 3 o versione successiva in tutti i server Accesso client nell'ambiente. Il servizio Host di Microsoft Exchange nei server Accesso Client è responsabile della gestione delle credenziali ASA. Se questo servizio non è in esecuzione, l'autenticazione Kerberos non funzionerà. Per impostazione predefinita, il servizio viene configurato per l'avvio automatico all'avvio del computer. Per verificare che il servizio sia in esecuzione, seguire questa procedura:

1. Aprire Servizi sul CAS. Per aprire Servizi, fare clic su Start, fare clic su Pannello di controllo, fare doppio clic su Strumenti di amministrazione, quindi fare doppio clic su Servizi.
2. Nell'elenco dei servizi individuare il servizio host del servizio Microsoft Exchange.
3. Nella colonna Stato verificare che lo stato sia Avviato. Se il servizio non è avviato, fare clic con il pulsante destro del mouse sul servizio Host del servizio Microsoft Exchange e quindi scegliere Avvia. Per configurare il servizio per l'avvio automatico, fare clic con il pulsante destro del mouse sul servizio host del servizio Microsoft Exchange, scegliere Proprietà, fare clic su Automaticonell'elenco Tipo di avvio e quindi scegliere OK.
   Convalidare l'autenticazione da Outlook

Per verificare che Outlook possa usare l'autenticazione Kerberos per connettersi ai server Accesso client, seguire questa procedura:

1. Verificare che Outlook sia configurato in modo che punti alla matrice del server Accesso client con carico bilanciato corretto.
2. Configurare le impostazioni di sicurezza del server dell'account di posta elettronica per l'uso dell'autenticazione negoziata di rete di accesso. Nota È possibile configurare il client per l'uso dell'autenticazione con password Kerberos, ma se i nomi SPN vengono rimossi, i computer client non potranno autenticarsi fino a quando non si modifica nuovamente il meccanismo di autenticazione in Autenticazione negoziata.
3. Assicurarsi che Outlook Via Internet non sia abilitato per il computer client. Se Outlook non è in grado di eseguire l'autenticazione tramite password Kerberos, tenterà di effettuare il fallback su Outlook Anywhere, pertanto Outlook Anywhere deve essere disabilitato per questo test.
4. Riavvia Outlook.
5. Se il computer desktop esegue Windows 7, è possibile eseguire klist.exe per vedere quali ticket Kerberos vengono concessi e vengono usati. Se non si esegue Windows 7, è possibile ottenere klist.exe da Windows Server 2003 Resource Kit.

Risorse aggiuntive

Per informazioni dettagliate su questo problema e sulla relativa soluzione, vedere l'articolo technet seguente:

Uso di Kerberos con un array di server di accesso client o una soluzione per il bilanciamento del carico

Per altre informazioni su come usare l'autenticazione Kerberos nei server di accesso client con carico bilanciato, vedere l'articolo TechNet seguente:

Configurazione dell'autenticazione Kerberos per i server di accesso client con carico bilanciato