Configurazione dell'autenticazione OAuth tra organizzazioni Exchange ed Exchange Online

  • Articolo

Si applica a: Exchange Server 2013

La configurazione guidata ibrida configura automaticamente l'autenticazione OAuth tra Exchange 2013 e le organizzazioni Exchange Online. Se l'organizzazione di Exchange 2013 contiene server Exchange 2010 o Exchange 2007, la configurazione guidata ibrida non configura l'autenticazione OAuth tra le organizzazioni exchange locali e online. Tali distribuzioni continuano a utilizzare il processo di trust federativo per impostazione predefinita. Tuttavia, determinate funzionalità di Exchange 2013 sono completamente disponibili all'interno dell'organizzazione solo utilizzando il nuovo protocollo di autenticazione OAuth di Exchange.

Il nuovo processo di autenticazione OAuth di Exchange attualmente abilita le seguenti funzionalità di Exchange:

  • Gestione record di messaggi (MRM)
  • eDiscovery in locale di Exchange
  • Archiviazione in locale di Exchange

È consigliabile che tutte le organizzazioni miste di Exchange 2013 configurino l'autenticazione OAuth di Exchange dopo l'esecuzione della Configurazione guidata ibrida.

Importante

  • Se l'organizzazione locale esegue solo server Exchange 2013 con l'aggiornamento cumulativo 5 o versione successiva, eseguire la Distribuzione guidata ibrida anziché eseguire i passaggi descritti in questo argomento.

  • Questa funzionalità di Exchange Server 2013 non è completamente compatibile con Office 365 utilizzato da 21Vianet in Cina e potrebbe essere soggetta a limitazioni. Per altre informazioni, vedere Office 365 gestito da 21Vianet.

Che cosa è necessario sapere prima di iniziare?

Consiglio

Problemi? È possibile richiedere supporto nei forum di Exchange. Visitare i forum all'indirizzo Exchange Server.

Come si configura l'autenticazione OAuth tra l'organizzazione Exchange locale e quella Exchange Online?

Passaggio 1: Creare gli oggetti server di autorizzazione per l'organizzazione Exchange Online

Per eseguire questa procedura, è necessario specificare un dominio verificato per la propria organizzazione di Exchange Online. Deve essere lo stesso dominio usato come dominio SMTP primario usato per gli account di posta elettronica basati sul cloud. Questo dominio viene definito dominio<> verificato nella procedura seguente.

Eseguire il comando seguente in Exchange Management Shell (Exchange PowerShell) nell'organizzazione di Exchange locale:

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/<your tenant coexistence domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.windows.net/<your tenant coexistence domain>/federationmetadata/2007-06/federationmetadata.xml"

Nota

In GCC High o DoD è invece necessario usare i comandi seguenti:

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant coexistence domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant coexistence domain>/federationmetadata/2007-06/federationmetadata.xml"

Nota

Il dominio di coesistenza tenant è nel formato contoso.mail.onmicrosoft.com

Passaggio 2: abilitare l'applicazione partner per l'organizzazione di Exchange Online

Eseguire il comando seguente in Exchange PowerShell nella propria organizzazione Exchange locale.

Get-PartnerApplication |  ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true

Passaggio 3: esportare il certificato di autorizzazione in locale

In questo passaggio è necessario eseguire uno script di PowerShell nel server Exchange direttamente per esportare il certificato di autorizzazione locale, che viene quindi importato nell'organizzazione Exchange Online nel passaggio successivo.

  1. Salvare il testo seguente in un file di script di PowerShell denominato, ad esempio, ExportAuthCert.ps1.

    $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
   md $env:SYSTEMDRIVE\OAuthConfig
}
cd $env:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.Thumbprint -match $thumbprint}
$certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$certBytes = $oAuthCert.Export($certType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $certBytes)

  2. In Exchange PowerShell della propria organizzazione Exchange locale, eseguire lo script di PowerShell che è stato creato al passaggio precedente. Ad esempio:

    .\ExportAuthCert.ps1

Passaggio 4: Caricare il certificato di autorizzazione locale nel servizio Microsoft Entra Controllo di accesso (ACS)

Usare quindi Microsoft Graph PowerShell per caricare il certificato di autorizzazione locale esportato nel passaggio precedente in Microsoft Entra Controllo di accesso Services (ACS). Se il modulo non è installato, aprire una finestra di Windows PowerShell come amministratore ed eseguire il comando seguente:

Install-Module -Name Microsoft.Graph.Applications

Completare i passaggi seguenti dopo l'installazione di Microsoft Graph PowerShell.

  1. Aprire un'area di lavoro Windows PowerShell in cui sono installati i cmdlet di Microsoft Graph. Tutti i comandi in questo passaggio verranno eseguiti usando il Windows PowerShell connesso alla console di Microsoft Graph.

  2. Salvare il testo seguente in un file di script di PowerShell denominato, ad esempio, UploadAuthCert.ps1.

     Connect-MgGraph -Scopes Application.ReadWrite.All

 $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
 $objFSO = New-Object -ComObject Scripting.FileSystemObject
 $CertFile = $objFSO.GetAbsolutePathName($CertFile)
 $cer = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($CertFile)
 $binCert = $cer.GetRawCertData()
 $credValue = [System.Convert]::ToBase64String($binCert)
 $ServiceName = "00000002-0000-0ff1-ce00-000000000000"
 $p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
 $params = @{
 	keyCredentials = @{
 		type = "AsymmetricX509Cert"
 		usage = "Verify"
 		key = $credValue
 	}
 }
 Update-MgServicePrincipal -ServicePrincipalId $p.Id -BodyParameter $params

  3. Eseguire lo script di PowerShell creato nel passaggio precedente. Ad esempio:

    .\UploadAuthCert.ps1

  4. Dopo avere avviato lo script, viene visualizzata una finestra di dialogo relativa alle credenziali. Immettere le credenziali per l'account amministratore tenant nell'organizzazione di Microsoft Online Microsoft Entra. Dopo aver eseguito lo script, lasciare aperto il Windows PowerShell connesso alla sessione di Microsoft Graph. Questa verrà utilizzata per eseguire uno script di PowerShell nel prossimo passaggio.

Passaggio 5: Registrare tutte le autorità dei nomi host per gli endpoint HTTP di Exchange interni ed esterni con Microsoft Entra ID

È necessario eseguire lo script in questo passaggio per ogni endpoint accessibile pubblicamente nell'organizzazione di Exchange locale, inclusi gli URL interni ed esterni per l'autenticazione moderna ibrida. Ad esempio, se Exchange è disponibile esternamente in https://mail.contoso.com/ews/exchange.asmx, usare il nome https://mail.contoso.comdell'entità servizio . Non è presente un limite relativo alla registrazione di ulteriori autorità nome host esterne.

Per confermare gli endpoint di Exchange nell'organizzazione locale, eseguire i comandi seguenti in Exchange Management Shell:

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

Nota

Lo script seguente richiede che il Windows PowerShell connesso a Microsoft Graph sia connesso all'organizzazione di Microsoft 365, come illustrato nel passaggio 4 della sezione precedente.

  1. Salvare il testo seguente in un file di script di PowerShell denominato, ad esempio, RegisterEndpoints.ps1. In questo esempio viene usato un contoso.com. Sostituire https://mail.contoso.com/ e https://autodiscover.contoso.com/ con l'autorità del nome host appropriata per l'organizzazione di Exchange locale.

     $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
 $x = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
 $ServicePrincipalUpdate =@(
    "https://mail.contoso.com/","https://autodiscover.contoso.com/"
 )
 Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $ServicePrincipalUpdate

  2. In Windows PowerShell connesso a Microsoft Graph eseguire lo script Windows PowerShell creato nel passaggio precedente. Ad esempio:

    .\RegisterEndpoints.ps1

  3. Per verificare che siano stati aggiunti tutti i record, eseguire il comando seguente in Windows PowerShell connesso a Microsoft Graph e cercare https://namespace le voci nei risultati.

    Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" | select -ExpandProperty ServicePrincipalNames

Passaggio 6: Creare un IntraOrganizationConnector dall'organizzazione locale a Microsoft 365 o Office 365

È necessario definire un indirizzo di destinazione per le cassette postali ospitate in Exchange Online. Questo indirizzo di destinazione viene creato automaticamente quando viene creata l'organizzazione microsoft 365 o Office 365. Ad esempio, se il dominio dell'organizzazione ospitato in Microsoft 365 o Office 365 organizzazione è "contoso.com", l'indirizzo del servizio di destinazione sarà "contoso.mail.onmicrosoft.com".

Utilizzando Exchange PowerShell, eseguire il seguente cmdlet nell'organizzazione locale:

$ServiceDomain = Get-AcceptedDomain | where {$_.DomainName -like "*.mail.onmicrosoft.com"} | select -ExpandProperty Name
New-IntraOrganizationConnector -name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://outlook.office365.com/autodiscover/autodiscover.svc -TargetAddressDomains $ServiceDomain

Passaggio 7: Creare un'organizzazione IntraOrganizationConnector dall'organizzazione di Microsoft 365 o Office 365 all'organizzazione di Exchange locale

È necessario definire un indirizzo di destinazione per le cassette postali ospitate nell'organizzazione locale. Se l'indirizzo SMTP primario dell'organizzazione è in "contoso.com", gli indirizzi di destinazione saranno in "contoso.com".

Inoltre, è necessario definire l'endpoint di individuazione automatica esterno della propria organizzazione locale. Se l'azienda è "contoso.com", l'endpoint di individuazione automatica è in genere uno dei valori seguenti:

  • https://autodiscover.<your primary SMTP domain>/autodiscover/autodiscover.svc
  • https://<your primary SMTP domain>/autodiscover/autodiscover.svc>

Nota

È possibile usare il cmdlet Get-IntraOrganizationConfiguration sia nei tenant locali che in Microsoft 365 o Office 365 per determinare i valori degli endpoint necessari per il cmdlet New-IntraOrganizationConnector.

Dopo aver eseguito la connessione a Exchange Online PowerShell, sostituire <your on-premises Autodiscover endpoint> e <your on-premises SMTP domain> con i valori ed eseguire il comando seguente:

New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises Autodiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain>

Passaggio 8: Configurare uno AvailabilityAddressSpace per uno dei server precedenti a Exchange 2013 SP1

Quando si configura una distribuzione ibrida nelle organizzazioni exchange meno recenti, è necessario almeno un server Exchange 2013 che esegue Exchange 2013 SP1 o versione successiva. Il server Exchange 2013 richiede i ruoli del server Accesso client e Cassette postali. Il server Exchange 2013 coordina le comunicazioni tra l'organizzazione locale di Exchange esistente e l'organizzazione Exchange Online. È consigliabile installare più di un server Exchange 2013 nell'organizzazione locale per aumentare l'affidabilità e la disponibilità delle funzioni della distribuzione ibrida.

Nelle organizzazioni di Exchange 2013 con Exchange 2010 o Exchange 2007 è consigliabile che tutti i server front-end con connessione Internet siano server Accesso client di Exchange 2013 che eseguono SP1 o versioni successive. Tutte le richieste di Exchange Web Services (EWS) devono passare attraverso un server Accesso client di Exchange 2013. Questo requisito include richieste da Microsoft 365 all'organizzazione exchange locale e richieste dall'organizzazione exchange locale a Microsoft 365. È importante disporre di un numero sufficiente di server Accesso client di Exchange 2013 per gestire il carico di elaborazione e fornire ridondanza della connessione. Il numero di server accesso client necessari dipende dalla quantità media di richieste EWS e varia in base all'organizzazione.

Prima di completare il passaggio seguente, verificare quanto segue:

  • I server ibridi front-end sono Exchange 2013 SP1 o versione successiva.
  • Si dispone di un URL EWS esterno univoco per i server Exchange 2013. L'organizzazione di Microsoft 365 o Office 365 deve connettersi a questi server affinché le richieste basate sul cloud per le funzionalità ibride funzionino correttamente.
  • I server dispongono sia del ruolo Cassetta postale che del ruolo Accesso client
  • Eventuali server Cassetta postale e Accesso client Exchange 2010/2007 dispongono dell'aggiornamento cumulativo o del Service Pack.

Nota

I server Cassetta postale Exchange 2010/2007 possono continuare a utilizzare i server Accesso client Exchange per i server frontend per le connessioni alle funzionalità non ibrida2010/2007 Client Access servers for frontend servers for non-hybrid feature connections. Solo le richieste di funzionalità di distribuzione ibrida da parte dell'organizzazione di Microsoft 365 o Office 365 devono connettersi ai server exchange 2013.

È necessario configurare AvailabilityAddressSpace nei server accesso client pre-Exchange 2013 che puntano all'endpoint di Servizi Web Exchange dei server di accesso client di Exchange 2013 SP1 locali. Questo endpoint è lo stesso precedentemente delineato nel Passaggio 5 oppure può essere determinato eseguendo il seguente cmdlet sul server locale Accesso client di Exchange 2013 SP1.

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Nota

Se le informazioni di directory virtuale vengono restituite da più server, assicurarsi di utilizzare l'endpoint restituito per un server Accesso client di Exchange 2013 SP1. Verrà visualizzata la versione 15.0 (Build 847.32) o successiva per il parametro AdminDisplayVersion .

Per configurare AvailabilityAddressSpace, usare Exchange PowerShell ed eseguire il cmdlet seguente nell'organizzazione locale:

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises External Web Services URL> -ForestName <your Microsoft 365 or Office 365 service target address> -UseServiceAccount $True

Come verificare se l'operazione ha avuto esito positivo

È possibile verificare che la configurazione OAuth sia corretta utilizzando il cmdlet Test-OAuthConnectivity. Questo cmdlet verifica che gli endpoint di Exchange e Exchange Online locali possano autenticare correttamente le richieste l'una dall'altra.

Per verificare se la propria organizzazione Exchange può connettersi a Exchange Online ed eseguire il comando seguente in Exchange PowerShell della propria organizzazione locale:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List

Per verificare che l'organizzazione Exchange Online possa connettersi correttamente all'organizzazione di Exchange locale, connettersi a Exchange Online PowerShell ed eseguire il comando seguente:

Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List

Quindi, come esempio,

Test-OAuthConnectivity -Service EWS -TargetUri `https://mail.contoso.com/metadata/json/1` -Mailbox ExchangeOnlineBox1 -Verbose | Format-List

Importante

È possibile ignorare l'errore "All'indirizzo SMTP non è associata alcuna cassetta postale". È importante che il parametro ResultTask restituisca il valore Success. Ad esempio, l'ultima sezione dell'output del test deve essere letta:

ResultType: Success Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid: True ObjectState: New

Consiglio

Problemi? È possibile richiedere supporto nei forum di Exchange. Visitare i forum all'indirizzo Exchange Server.