Autenticazione Kerberos per la connessione client MAPI a una matrice di server Accesso client

Riepilogo

Per le distribuzioni Microsoft Exchange Server 2010 con più di un server Accesso client in un sito di Active Directory, la topologia richiede spesso un array 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 usata una matrice di server Accesso client. Per risolvere 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 una matrice di 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 del servizio Microsoft Exchange eseguito nel ruolo server Accesso client (CAS) viene esteso in Exchange Server 2010 SP1 per usare credenziali asa (Shared Alternate Service Account) per l'autenticazione Kerberos. Questa estensione host del servizio monitora il computer locale. Quando le credenziali vengono aggiunte o rimosse, vengono aggiornati il pacchetto di autenticazione Kerberos sul sistema locale e il contesto del servizio di rete. Non appena viene aggiunta al pacchetto di autenticazione, tutti i servizi Accesso client possono utilizzare la credenziale per l'autenticazione Kerberos. Il server Accesso client sarà anche in grado di autenticare le richieste di servizio indirizzate direttamente oltre a poter usare le credenziali asa. Questa estensione, nota come servicelet, viene eseguita per impostazione predefinita e non richiede alcuna configurazione o azione.

Potrebbe essere necessario usare l'autenticazione Kerberos per l'organizzazione 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, ad esempio la connettività MAPI diretta al servizio Accesso client RPC che causa errori NTLM intermittenti.

    Nelle distribuzioni di clienti su larga scala, NTLM può 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. Si verificano 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 come configurare gli array del server Accesso client. È inoltre necessario avere una conoscenza pratica 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 nella matrice del server Accesso client devono condividere lo stesso account del servizio. Sono inclusi tutti i server Accesso client che possono essere avviati come parte di un passaggio di data center. In genere, è sufficiente un account del servizio per foresta.

Creare un account computer anziché un account utente per l'account del servizio alternativo, 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.

Nota

Quando si crea un account computer, la password non scade. Tuttavia, è consigliabile aggiornare periodicamente la password. Il Criteri di gruppo locale può specificare una validità massima dell'account per gli account computer e gli amministratori di rete possono pianificare script per eliminare periodicamente gli account computer che non soddisfano i criteri correnti. Per assicurarsi che gli account computer non vengano eliminati se non soddisfano i criteri locali, aggiornare periodicamente la password per gli account computer. I criteri di sicurezza locali determineranno quando è necessario modificare la password.

Nota

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 della password dell'organizzazione.

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

Determinare i nomi SPN da associare alle credenziali dell'account del servizio alternativo

Dopo aver creato l'account del servizio alternativo, è necessario determinare i nomi dell'entità servizio di Exchange (SPN) 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é nei singoli server. L'elenco dei nomi SPN di Exchange può variare in base alla configurazione, ma l'elenco deve includere almeno quanto segue:

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

Per una piccola azienda, probabilmente non si avrà nulla di più grande di un singolo sito di Active Directory. Ad esempio, il singolo sito di Active Directory potrebbe essere simile al diagramma seguente.

Screenshot di una piccola azienda che contiene un singolo sito di Active Directory.

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

Nota

I client esterni o basati su Internet che usano Outlook Via Internet non useranno l'autenticazione Kerberos. Pertanto, non è necessario aggiungere i nomi FQDN usati da questi client come nomi SPN alle credenziali asa.

Se il sito è più grande di un singolo sito di Active Directory, è possibile visualizzare altri esempi nell'argomento Configurazione dell'autenticazione Kerberos per Load-Balanced server di accesso client .

Convertire la directory virtuale della rubrica offline in un'applicazione

La directory virtuale della Rubrica offline 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 della rubrica offline.

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

Distribuire le credenziali ASA ai membri 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 usare lo script per eseguire il push delle credenziali in tutti i server Accesso client nella foresta per la prima installazione, 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à pianificata di rollback automatico delle password una volta al mese denominata "Exchange-RollAsa". Questa attività pianificata dal comando aggiornerà le credenziali asa per tutti i server Accesso client nella foresta con una nuova password generata tramite script. L'attività pianificata viene creata, ma lo script non viene eseguito. Quando viene eseguita l'attività pianificata, 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 la distribuzione della credenziale 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 i nomi SPN alle credenziali asa

Prima di configurare i nomi SPN, assicurarsi che i nomi SPN di destinazione non siano già configurati in un account diverso nella foresta. Le credenziali asa devono essere l'unico account nella foresta a cui sono associati questi nomi SPN. È possibile verificare che nessun altro account nella foresta abbia i nomi SPN associati aprendo un prompt dei comandi ed eseguendo il comando setspn con i parametri –q e –f . Nell'esempio seguente viene illustrato come eseguire questo comando. Il comando non dovrebbe restituire nulla. Se restituisce un valore, un altro account è già associato al nome SPN che si vuole usare.

Nota

È 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 è il nome SPN del nome SPN per l'accesso client RPC, ad esempio exchangeMDB/outlook.corp.contoso.com.

Il comando seguente illustra come impostare i nomi SPN nelle credenziali asa condivise. È necessario eseguire il comando setspn con questa sintassi una volta per ogni 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 correttamente Kerberos e distribuito lo script RollAlternateServiceAccountPasswordl.ps1, verificare che i computer client possano eseguire correttamente l'autenticazione.

Verificare che Microsoft Exchange Service Host 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 del servizio Microsoft Exchange nei server Accesso client è responsabile della gestione delle credenziali asa. Se il servizio non è in esecuzione, l'autenticazione Kerberos non funzionerà. Per impostazione predefinita, il servizio è configurato per l'avvio automatico all'avvio del computer. Per verificare che il servizio sia in esecuzione, seguire questa procedura:

  1. Aprire Servizi nel server di amministrazione centrale. Per aprire Servizi, fare clic sul pulsante Start, scegliere Pannello di controllo, fare doppio clic su Strumenti di amministrazione e quindi 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 l'avvio automatico del servizio, 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 per puntare all'array di server Accesso client con bilanciamento del carico corretto.
  2. Configurare le impostazioni di sicurezza del server dell'account di posta elettronica per usare la sicurezza di rete di accesso Negotiate Authentication. NotaÈ possibile configurare il client per l'uso dell'autenticazione password Kerberos, ma se i nomi SPN vengono rimossi, i computer client non saranno in grado di eseguire l'autenticazione fino a quando non si modifica nuovamente il meccanismo di autenticazione in Negoziazione autenticazione.
  3. Assicurarsi che Outlook Via Internet non sia abilitato per il computer client. Se Outlook non è in grado di eseguire l'autenticazione tramite l'autenticazione password Kerberos, tenterà di tornare a Outlook Via Internet, quindi Outlook Via Internet deve essere disabilitato per questo test.
  4. Riavviare Outlook.
  5. Se il computer desktop esegue Windows 7, è possibile eseguire klist.exe per visualizzare quali ticket Kerberos vengono concessi e 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 sul relativo funzionamento, vedere l'articolo TechNet seguente:

Utilizzo di Kerberos con un array Accesso client o una soluzione con carico bilanciato

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 Load-Balanced server accesso client