Come configurare Exchange Server locale per utilizzare l'autenticazione moderna ibrida

Panoramica

L'autenticazione moderna ibrida (HMA) in Microsoft Exchange Server è una funzionalità che consente agli utenti di accedere alle cassette postali, ospitate in locale, usando i token di autorizzazione ottenuti dal cloud.

HMA consente a Outlook di ottenere i token OAuth di accesso e aggiornamento da Microsoft Entra ID, direttamente per la sincronizzazione dell'hash delle password o Pass-Through identità di autenticazione o dal proprio servizio token di sicurezza (STS) per le identità federate. Exchange locale accetta questi token e fornisce l'accesso alle cassette postali. Il metodo per ottenere questi token e le credenziali necessarie è determinato dalle funzionalità del provider di identità (iDP), che possono variare da semplici nomi utente e password a metodi più complessi, ad esempio certificati, autenticazione del telefono o metodi biometrici.

Per il funzionamento di HMA, l'identità dell'utente deve essere presente in Microsoft Entra ID ed è necessaria una configurazione gestita dalla Configurazione guidata ibrida di Exchange.

Rispetto ai metodi di autenticazione legacy, ad esempio NTLM, HMA offre diversi vantaggi. Offre un metodo di autenticazione più sicuro e flessibile, sfruttando la potenza dell'autenticazione basata sul cloud. A differenza di NTLM, che si basa su un meccanismo di risposta alle richieste e non supporta i protocolli di autenticazione moderni, HMA usa token OAuth, che sono più sicuri e offrono una migliore interoperabilità.

HMA è una potente funzionalità che migliora la flessibilità e la sicurezza dell'accesso alle applicazioni locali, sfruttando la potenza dell'autenticazione basata sul cloud. Rappresenta un miglioramento significativo rispetto ai metodi di autenticazione legacy, offrendo maggiore sicurezza, flessibilità e praticità dell'utente.

Procedura da seguire per configurare e abilitare l'autenticazione moderna ibrida

Per abilitare l'autenticazione moderna ibrida (HMA), è necessario assicurarsi che l'organizzazione soddisfi tutti i prerequisiti necessari. È inoltre necessario verificare che il client di Office sia compatibile con l'autenticazione moderna. Per altre informazioni, vedere la documentazione relativa al funzionamento dell'autenticazione moderna per le app client di Office 2013 e Office 2016.

1. Assicurarsi di soddisfare i prerequisiti prima di iniziare.

2. Aggiungere gli URL del servizio Web locale a Microsoft Entra ID. Gli URL devono essere aggiunti come Service Principal Names (SPNs). Nel caso in cui la configurazione Exchange Server sia ibrida con più tenant, questi URL del servizio Web locale devono essere aggiunti come NOMI SPN nella Microsoft Entra ID di tutti i tenant, che sono ibridi con Exchange Server locale.

3. Assicurarsi che tutte le directory virtuali siano abilitate per HMA. Se si vuole configurare l'autenticazione moderna ibrida per Outlook sul Web (OWA) ed Exchange Pannello di controllo (ECP), è importante verificare anche le rispettive directory.

4. Verificare la presenza dell'oggetto EvoSTS Auth Server.

5. Assicurarsi che il certificato OAuth Exchange Server sia valido. Lo script di script MonitorExchangeAuthCertificate può essere utilizzato per verificare la validità del certificato OAuth. In caso di scadenza, lo script facilita il processo di rinnovo.

6. Assicurarsi che tutte le identità utente siano sincronizzate con Microsoft Entra ID, in particolare tutti gli account, usati per l'amministrazione. In caso contrario, l'account di accesso smette di funzionare finché non viene sincronizzato. Gli account, ad esempio l'amministratore predefinito, non verranno mai sincronizzati con Microsoft Entra ID e, pertanto, non possono essere usati in alcun account di accesso OAuth dopo l'abilitazione di HMA. Questo comportamento è dovuto all'attributo isCriticalSystemObject , impostato su True per alcuni account, tra cui l'amministratore predefinito.

7. (Facoltativo) Se si vuole usare il client Outlook per iOS e Android, assicurarsi di consentire al servizio Rilevamento automatico di connettersi al Exchange Server.

8. Abilitare HMA in Exchange locale.

Prerequisiti per abilitare l'autenticazione moderna ibrida

In questa sezione vengono fornite informazioni e passaggi da eseguire per configurare e abilitare correttamente l'autenticazione moderna ibrida in Microsoft Exchange Server.

Exchange Server prerequisiti specifici

I server Exchange devono soddisfare i requisiti seguenti prima di poter configurare e abilitare l'autenticazione moderna ibrida. Se si dispone di una configurazione ibrida, è necessario eseguire l'aggiornamento cumulativo (CU) più recente per essere in uno stato supportato. È possibile trovare le versioni di Exchange Server supportate e compilare nella matrice di supporto Exchange Server. L'autenticazione moderna ibrida deve essere configurata in modo uniforme in tutti i server Exchange all'interno dell'organizzazione. L'implementazione parziale, in cui HMA è abilitata solo in un subset di server, non è supportata.

• Assicurarsi che non siano presenti server Exchange end-of-life nell'organizzazione.
• Exchange Server 2016 deve essere in esecuzione CU8 o versione successiva.
• Exchange Server 2019 deve essere in esecuzione CU1 o versione successiva.
• Assicurarsi che tutti i server possano connettersi a Internet. Se è necessario un proxy, configurare Exchange Server per usarlo.
• Se si dispone già di una configurazione ibrida, assicurarsi che si tratti di una distribuzione ibrida classica in quanto l'ambiente ibrido moderno non supporta HMA.
• Assicurarsi che l'offload SSL non venga usato (non supportato). Il bridging SSL, tuttavia, può essere usato ed è supportato.

Altre informazioni sono disponibili anche nella panoramica dell'autenticazione moderna ibrida e nei prerequisiti per usarla con Skype for Business locali e la documentazione dei server Exchange.

Protocolli che funzionano con l'autenticazione moderna ibrida

L'autenticazione moderna ibrida funziona per i protocolli di Exchange Server seguenti:

Protocollo	Autenticazione moderna ibrida supportata
MAPI su HTTP (MAPI/HTTP)	Sì
Outlook Via Internet (RPC/HTTP)	No
Exchange Active Sync (EAS)	Sì
Servizi Web Exchange (EWS)	Sì
Outlook sul Web (OWA)	Sì
Exchange Amministrazione Center (ECP)	Sì
Rubrica offline (Rubrica offline)	Sì
IMAP	No
POP	No

Aggiungere URL del servizio Web locale come NOMI SPN in Microsoft Entra ID

Eseguire i comandi che assegnano gli URL del servizio Web locale come nomi SPN Microsoft Entra. I nomi SPN vengono usati dai computer client e dai dispositivi durante l'autenticazione e l'autorizzazione. Tutti gli URL che possono essere usati per connettersi da locale a Microsoft Entra ID devono essere registrati in Microsoft Entra ID (inclusi gli spazi dei nomi interni ed esterni).

1. Eseguire prima di tutto i comandi seguenti nel Microsoft Exchange Server:

   Get-MapiVirtualDirectory -ADPropertiesOnly | fl server,*url*
   Get-WebServicesVirtualDirectory -ADPropertiesOnly | fl server,*url*
   Get-ClientAccessService | fl Name, AutodiscoverServiceInternalUri
   Get-OABVirtualDirectory -ADPropertiesOnly | fl server,*url*
   Get-AutodiscoverVirtualDirectory -ADPropertiesOnly | fl server,*url*
   Get-ActiveSyncVirtualDirectory -ADPropertiesOnly | fl server,*url*
   

   Verificare che gli URL a cui i client possono connettersi siano elencati come nomi di entità servizio HTTPS in Microsoft Entra ID. Nel caso in cui Exchange locale sia ibrido con più tenant, questi NOMI SPN HTTPS devono essere aggiunti nel Microsoft Entra ID di tutti i tenant in ambiente ibrido con Exchange locale.

2. Installare il modulo PowerShell di Microsoft Graph:

   Install-Module Microsoft.Graph -Scope AllUsers
   

3. Connettersi quindi a Microsoft Entra ID seguendo queste istruzioni. Per concedere il consenso alle autorizzazioni necessarie, eseguire il comando seguente:

   Connect-MgGraph -Scopes Application.Read.All, Application.ReadWrite.All
   

4. Per gli URL correlati a Exchange, digitare il comando seguente:

   Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'" | select -ExpandProperty ServicePrincipalNames
   

   Prendere nota dell'output di questo comando, che deve includere un https://*autodiscover.yourdomain.com* URL e https://*mail.yourdomain.com* , ma principalmente costituito da nomi SPN che iniziano con 00000002-0000-0ff1-ce00-000000000000/. Se sono https:// presenti URL dell'ambiente locale mancanti, questi record specifici devono essere aggiunti a questo elenco.

5. Se non vengono visualizzati i record interni ed esterni MAPI/HTTP, , EWSActiveSync, OABe AutoDiscover in questo elenco, è necessario aggiungerli. Usare il comando seguente per aggiungere tutti gli URL mancanti. Nell'esempio gli URL aggiunti sono mail.corp.contoso.com e owa.contoso.com. Assicurarsi che siano sostituiti dagli URL configurati nell'ambiente.

   $x = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
   $x.ServicePrincipalNames += "https://mail.corp.contoso.com/"
   $x.ServicePrincipalNames += "https://owa.contoso.com/"
   Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $x.ServicePrincipalNames
   

6. Verificare che i nuovi record siano stati aggiunti eseguendo di nuovo il Get-MgServicePrincipal comando dal passaggio 4 e convalidare l'output. Confrontare l'elenco precedente con il nuovo elenco di nomi SPN. È anche possibile annotare il nuovo elenco per i record. In caso di esito positivo, verranno visualizzati i due nuovi URL nell'elenco. In base all'esempio, l'elenco di nomi SPN include ora gli URL https://mail.corp.contoso.com specifici e https://owa.contoso.com.

Verificare che le directory virtuali siano configurate correttamente

Verificare ora che OAuth sia abilitato correttamente in Exchange in tutte le directory virtuali che Outlook potrebbe usare eseguendo i comandi seguenti:

Get-MapiVirtualDirectory | fl server,*url*,*auth*
Get-WebServicesVirtualDirectory | fl server,*url*,*oauth*
Get-OABVirtualDirectory | fl server,*url*,*oauth*
Get-AutoDiscoverVirtualDirectory | fl server,*oauth*
Get-ActiveSyncVirtualDirectory | fl server,*url*,*auth*

Controllare l'output per assicurarsi che OAuth sia abilitato per ognuna di queste directory virtuali, l'aspetto è simile al seguente (e l'aspetto chiave da esaminare è OAuth come indicato in precedenza):

Get-MapiVirtualDirectory | fl server,*url*,*auth*

Server                        : EX1
InternalUrl                   : https://mail.contoso.com/mapi
ExternalUrl                   : https://mail.contoso.com/mapi
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

Se OAuth non è presente in un server e in una qualsiasi delle cinque directory virtuali, è necessario aggiungerlo usando i comandi pertinenti prima di procedere (Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OABVirtualDirectory, Set-AutodiscoverVirtualDirectory) e Set-ActiveSyncVirtualDirectory.

Verificare che l'oggetto server di autenticazione EvoSTS sia presente

A questo punto, nel Exchange Server Management Shell (EMS) locale eseguire questo ultimo comando. È possibile verificare che il Exchange Server locale restituisca una voce per il provider di autenticazione evoSTS:

Get-AuthServer | where {$_.Name -like "EvoSts*"} | ft name,enabled

L'output deve mostrare un AuthServer del nome EvoSts - <GUID> e lo Enabled stato deve essere True. In caso contrario, è necessario scaricare ed eseguire la versione più recente della Configurazione guidata ibrida.

Se Exchange Server locale esegue una configurazione ibrida con più tenant, l'output mostra un AuthServer con il nome EvoSts - <GUID> per ogni tenant in ambiente ibrido con Exchange Server locale e lo Enabled stato deve essere True per tutti questi oggetti AuthServer. Prendere nota dell'identificatore EvoSts - <GUID>, perché sarà necessario nel passaggio successivo.

Abilitare HMA

Eseguire i comandi seguenti nella Exchange Server Management Shell (EMS) locale e sostituire <GUID> nella riga di comando con il GUID dell'output dell'ultimo comando eseguito. Nelle versioni precedenti della Configurazione guidata ibrida il nome EvoSTS di EvoSts AuthServer era senza un GUID collegato. Non è necessario eseguire alcuna azione, è sufficiente modificare la riga di comando precedente rimuovendo la parte GUID del comando.

Set-AuthServer -Identity "EvoSTS - <GUID>" -IsDefaultAuthorizationEndpoint $true
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Se la versione Exchange Server locale è Exchange Server 2016 (CU18 o versione successiva) o Exchange Server 2019 (CU7 o versione successiva) e l'ambiente ibrido è stato configurato con l'aiuto di HCW scaricato dopo settembre 2020, eseguire il comando seguente nella Exchange Server Management Shell (EMS) locale. Per il DomainName parametro , usare il valore del dominio tenant, che in genere è nel formato contoso.onmicrosoft.com:

Set-AuthServer -Identity "EvoSTS - <GUID>" -DomainName "Tenant Domain" -IsDefaultAuthorizationEndpoint $true
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Nel caso in cui Exchange Server locale sia ibrido con più tenant, sono presenti più oggetti AuthServer nel Exchange Server organizzazioni locali con domini corrispondenti a ogni tenant. Il IsDefaultAuthorizationEndpoint flag deve essere impostato su True per uno qualsiasi di questi oggetti AuthServer. Il flag non può essere impostato su true per tutti gli oggetti AuthServer e HMA verrebbe abilitato anche se uno di questi flag di oggetto IsDefaultAuthorizationEndpoint AuthServer è impostato su true.

Importante

Quando si usano più tenant , devono trovarsi tutti nello stesso ambiente cloud, ad esempio tutti in Global o tutti in GCC. Non possono esistere in ambienti di combinazione, ad esempio un tenant in Global e un altro in GCC.

Verificare

Dopo aver abilitato HMA, l'accesso successivo di un client userà il nuovo flusso di autenticazione. L'attivazione di HMA non attiverà una riautenticazione per alcun client e potrebbe essere necessario del tempo prima che Exchange Server selezioni le nuove impostazioni. Questo processo non richiede la creazione di un nuovo profilo.

È anche necessario tenere premuto il CTRL tasto nello stesso momento in cui si fa clic con il pulsante destro del mouse sull'icona per il client Outlook (anche nella barra delle notifiche di Windows) e selezionare Connection Status. Cercare l'indirizzo SMTP del client rispetto a un AuthN tipo di Bearer\*, che rappresenta il token di connessione usato in OAuth.

Abilitare l'autenticazione moderna ibrida per OWA ed ECP

L'autenticazione moderna ibrida può ora essere abilitata anche per OWA e ECP. Assicurarsi che i prerequisiti siano soddisfatti prima di continuare.

Dopo aver abilitato l'autenticazione moderna ibrida per OWA e ECP, ogni utente finale e amministratore che tenta di accedere OWA o ECP verrà reindirizzato prima alla pagina di autenticazione Microsoft Entra ID. Una volta completata l'autenticazione, l'utente verrà reindirizzato a OWA o ECP.

Prerequisiti per abilitare l'autenticazione moderna ibrida per OWA ed ECP

Importante

Tutti i server devono avere installato almeno l'aggiornamento CU14 Exchange Server 2019. Devono anche eseguire l'interfaccia utente Exchange Server 2019 CU14 aprile 2024 o un aggiornamento successivo.

Per abilitare l'autenticazione moderna ibrida per OWA e ECP, tutte le identità utente devono essere sincronizzate con Microsoft Entra ID. Oltre a questo, è importante che la configurazione di OAuth tra Exchange Server locale e Exchange Online sia stata stabilita prima di poter eseguire ulteriori passaggi di configurazione.

I clienti che hanno già eseguito la Configurazione guidata ibrida (HCW) per configurare l'ambiente ibrido dispongono di una configurazione OAuth. Se OAuth non è stato configurato in precedenza, è possibile eseguirlo eseguendo HCW o seguendo i passaggi descritti nella documentazione Configurare l'autenticazione OAuth tra Exchange e Exchange Online organizzazioni.

È consigliabile documentare le OwaVirtualDirectory impostazioni e EcpVirtualDirectory prima di apportare modifiche. Questa documentazione consente di ripristinare le impostazioni originali se si verificano problemi dopo la configurazione della funzionalità.

Passaggi per abilitare l'autenticazione moderna ibrida per OWA ed ECP

Avviso

La pubblicazione di Outlook Web App (OWA) ed Exchange Pannello di controllo (ECP) tramite Microsoft Entra proxy di applicazione non è supportata.

1. Eseguire query sugli OWA URL e ECP configurati nel Exchange Server locale. Questo è importante perché devono essere aggiunti come URL di risposta a Microsoft Entra ID:

   Get-OwaVirtualDirectory -ADPropertiesOnly | fl name, *url*
   Get-EcpVirtualDirectory -ADPropertiesOnly | fl name, *url*
   

2. Installare il modulo PowerShell di Microsoft Graph se non è ancora stato installato:

   Install-Module Microsoft.Graph -Scope AllUsers
   

3. Connettersi a Microsoft Entra ID con queste istruzioni. Per concedere il consenso alle autorizzazioni necessarie, eseguire il comando seguente:

   Connect-Graph -Scopes User.Read, Application.ReadWrite.All
   

4. OWA Specificare gli URL e ECP e aggiornare l'applicazione con gli URL di risposta:

   $servicePrincipal = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
   $servicePrincipal.ReplyUrls += "https://YourDomain.contoso.com/owa"
   $servicePrincipal.ReplyUrls += "https://YourDomain.contoso.com/ecp"
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -AppId "00000002-0000-0ff1-ce00-000000000000" -ReplyUrls $servicePrincipal.ReplyUrls
   

5. Verificare che gli URL di risposta siano stati aggiunti correttamente:

   (Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'").ReplyUrls
   

6. Per abilitare Exchange Server capacità locale di eseguire l'autenticazione moderna ibrida, seguire i passaggi descritti nella sezione Abilita HMA.

7. (Facoltativo) Obbligatorio solo se vengono usati i domini di download :

   Creare una nuova sostituzione dell'impostazione globale eseguendo i comandi seguenti da Exchange Management Shell (EMS) con privilegi elevati. Eseguire questi comandi in un Exchange Server:

   New-SettingOverride -Name "OWA HMA Download Domain Support" -Component "OAuth" -Section "OAuthIdentityCacheFixForDownloadDomains" -Parameters ("Enabled=true") -Reason "Enable support for OWA HMA when Download Domains are in use"
   Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
   Restart-Service -Name W3SVC, WAS -Force
   

8. (Facoltativo) Obbligatorio solo negli scenari di topologia della foresta di risorse di Exchange :

   Aggiungere le chiavi seguenti al <appSettings> nodo del <ExchangeInstallPath>\ClientAccess\Owa\web.config file. Eseguire questa operazione in ogni Exchange Server:

   <add key="OAuthHttpModule.ConvertToSidBasedIdentity" value="true"/>
   <add key="OAuthHttpModule.UseMasterAccountSid" value="true"/>
   

   Creare una nuova sostituzione dell'impostazione globale eseguendo i comandi seguenti da Exchange Management Shell (EMS) con privilegi elevati. Eseguire questi comandi in un Exchange Server:

   New-SettingOverride -Name "OWA HMA AFRF Support" -Component "OAuth" -Section "OwaHMAFixForAfRfScenarios" -Parameters ("Enabled=true") -Reason "Enable support for OWA HMA in AFRF scenarios"
   Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
   Restart-Service -Name W3SVC, WAS -Force
   

9. Per abilitare l'autenticazione moderna ibrida per OWA e ECP, è innanzitutto necessario disabilitare qualsiasi altro metodo di autenticazione in queste directory virtuali. È importante eseguire la configurazione nell'ordine specificato. Se non si esegue questa operazione, potrebbe verificarsi un messaggio di errore durante l'esecuzione del comando.
   
   Eseguire questi comandi per ogni OWA directory virtuale e ECP in ogni Exchange Server per disabilitare tutti gli altri metodi di autenticazione:

   Get-OwaVirtualDirectory -Server <computername> | Set-OwaVirtualDirectory -AdfsAuthentication $false –BasicAuthentication $false –FormsAuthentication $false –DigestAuthentication $false
   Get-EcpVirtualDirectory -Server <computername> | Set-EcpVirtualDirectory -AdfsAuthentication $false –BasicAuthentication $false –FormsAuthentication $false –DigestAuthentication $false
   

   Importante

   Assicurarsi che tutti gli account siano sincronizzati con Microsoft Entra ID, in particolare tutti gli account usati per l'amministrazione. In caso contrario, l'account di accesso smette di funzionare finché non viene sincronizzato. Gli account, ad esempio l'amministratore predefinito, non verranno sincronizzati con Microsoft Entra ID e, pertanto, non possono essere usati per l'amministrazione dopo l'abilitazione di HMA per OWA ed ECP. Questo comportamento è dovuto all'attributo isCriticalSystemObject , impostato su True per alcuni account.

10. Abilitare OAuth per la OWA directory virtuale e ECP . È importante eseguire la configurazione nell'ordine specificato. Se non si esegue questa operazione, potrebbe verificarsi un messaggio di errore durante l'esecuzione del comando. Per ogni OWA directory virtuale e ECP per ogni Exchange Server, è necessario eseguire questi comandi:

    Get-EcpVirtualDirectory -Server <computername> | Set-EcpVirtualDirectory -OAuthAuthentication $true
    Get-OwaVirtualDirectory -Server <computername> | Set-OwaVirtualDirectory -OAuthAuthentication $true
    

Uso dell'autenticazione moderna ibrida con Outlook per iOS e Android

Se si vuole usare il client Outlook per iOS e Android insieme all'autenticazione moderna ibrida, assicurarsi di consentire al servizio Rilevamento automatico di connettersi al Exchange Server in TCP 443 (HTTPS):

<email_domain>.outlookmobile.com
<email_domain>.outlookmobile.us
52.125.128.0/20
52.127.96.0/23

Gli intervalli di indirizzi IP sono disponibili anche nella documentazione relativa agli endpoint aggiuntivi non inclusi nella documentazione relativa all'indirizzo IP e al servizio Web URL Office 365.

Articoli correlati

Requisiti di configurazione dell'autenticazione moderna per la transizione da Office 365 dedicato/ITAR a vNext