Configurazione dell'autenticazione OAuth tra organizzazioni Exchange ed Exchange Online

Articolo
08/26/2024

La configurazione guidata ibrida configura automaticamente l'autenticazione OAuth tra le organizzazioni di Exchange Server locale ed Exchange Online. Se l'organizzazione di Exchange 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, alcune funzionalità sono completamente disponibili solo nell'intera organizzazione usando 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 aggiornamento cumulativo 5 o versione successiva, Exchange 2016 o Exchange 2019, eseguire la Configurazione 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?

Tempo stimato per il completamento di questa attività: 15 minuti.
Devi disporre delle autorizzazioni per poter eseguire queste procedure. Per visualizzare le autorizzazioni necessarie, vedere la voce "Federazione e certificati" per le autorizzazioni nell'argomento Autorizzazioni per l'infrastruttura di Exchange e Shell .
Configurazione completata della distribuzione ibrida tramite la Configurazione guidata ibrida. Per altre informazioni, vedere Distribuzioni ibride di Exchange Server.
Per informazioni sui tasti di scelta rapida che è possibile utilizzare con le procedure in questo argomento, vedere Tasti di scelta rapida nell'interfaccia di amministrazione di Exchange.

Consiglio

Problemi? È possibile richiedere supporto nei forum di Exchange. Visitare i forum in Exchange Server.

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

Glossario

Dominio iniziale: il primo dominio di cui è stato effettuato il provisioning nel tenant. Ad esempio, contoso.onmicrosoft.com. In questa documentazione viene definito <dominio> iniziale del tenant.

Dominio di routing ibrido: il dominio di routing ibrido negli ambienti ibridi di Exchange, ad esempio contoso.mail.onmicrosoft.com, viene usato per gestire il flusso di posta tra i server Exchange locali ed Exchange Online. Garantisce la comunicazione e il recapito dei messaggi senza problemi in entrambi gli ambienti. In questa documentazione viene definito dominio> di< routing ibrido.

Microsoft Online Email Routing Address (MOERA): l'indirizzo costruito dal prefisso dell'utente userPrincipalName , più il suffisso di dominio iniziale, che viene aggiunto automaticamente a proxyAddress in Microsoft Entra ID. Ad esempio, smtp:john.doe@contoso.onmicrosoft.com. Non viene usato MOERA in questa documentazione, ma è riportato qui per motivi di completezza.

Dominio SMTP primario: il dominio SMTP primario in Microsoft Exchange Server è il dominio principale usato per gli indirizzi di posta elettronica all'interno dell'organizzazione. In questa documentazione viene definito <dominio> SMTP primario.

Endpoint di individuazione automatica: l'endpoint di individuazione automatica è un URL del servizio Web che fornisce informazioni di configurazione di Exchange Server. Consente alle applicazioni di individuare e connettersi automaticamente ai servizi di Exchange. Se la società usa, ad esempio, contoso.com come dominio SMTP primario, l'endpoint di individuazione automatica è in genere https://autodiscover.contoso.com/autodiscover/autodiscover.svc o https://contoso.com/autodiscover/autodiscover.svc. In questa documentazione viene definito <endpoint> di individuazione automatica locale.

Exchange Web Services (EWS):Exchange Web Services (EWS) è un'API multipiattaforma che consente alle applicazioni di accedere agli elementi delle cassette postali, ad esempio messaggi di posta elettronica, riunioni e contatti. In questa documentazione viene definito <URL> di Servizi Web Exchange esterno locale.

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

Eseguire il comando seguente in Exchange Management Shell (Exchange PowerShell) nell'organizzazione di Exchange locale. Assicurarsi di sostituire i segnaposto con i valori prima di eseguire il comando:

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

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

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

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

Eseguire il comando seguente in Exchange PowerShell nell'organizzazione di Exchange locale:

Get-PartnerApplication |  Where-Object {$_.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 sul server Exchange direttamente per esportare il certificato di autorizzazione locale, che viene quindi importato nell'organizzazione Exchange Online nel passaggio successivo.

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

Nota

Se si vuole caricare il certificato configurato per diventare il nuovo certificato di autenticazione in futuro, sostituire $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint con $thumbprint = (Get-AuthConfig).NewCertificateThumbprint.

$thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
if((Test-Path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
   New-Item -Path $env:SYSTEMDRIVE\OAuthConfig -Type Directory
}
Set-Location -Path $env:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | Where-Object {$_.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)

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 in Microsoft Entra Access Control Service (ACS)

Usare quindi Microsoft Graph PowerShell per caricare il certificato di autorizzazione locale esportato nel passaggio precedente in Microsoft Entra Access Control 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.

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

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"
Write-Host "[+] Trying to query the service principals for service: $ServiceName" -ForegroundColor Cyan
$p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
Write-Host "[+] Trying to query the keyCredentials for service: $ServiceName" -ForegroundColor Cyan
$servicePrincipalKeyInformation = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" -Select "keyCredentials"

$keyCredentialsLength = $servicePrincipalKeyInformation.KeyCredentials.Length
if ($keyCredentialsLength -gt 0) {
   Write-Host "[+] $keyCredentialsLength existing key(s) found - we keep them if they have not expired" -ForegroundColor Cyan

   $newCertAlreadyExists = $false
   $servicePrincipalObj = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphServicePrincipal
   $keyCredentialsArray = @()

   foreach ($cred in $servicePrincipalKeyInformation.KeyCredentials) {
      $thumbprint = [System.Convert]::ToBase64String($cred.CustomKeyIdentifier)

      Write-Host "[+] Processing existing key: $($cred.DisplayName) thumbprint: $thumbprint" -ForegroundColor Cyan

      if ($newCertAlreadyExists -ne $true) {
         $newCertAlreadyExists = ($cer.Thumbprint).Equals($thumbprint, [System.StringComparison]::OrdinalIgnoreCase)
      }

      if ($cred.EndDateTime -lt (Get-Date)) {
         Write-Host "[+] This key has expired on $($cred.EndDateTime) and will not be retained" -ForegroundColor Yellow
         continue
      }

      $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
      $keyCredential.Type = "AsymmetricX509Cert"
      $keyCredential.Usage = "Verify"
      $keyCredential.Key = $cred.Key

      $keyCredentialsArray += $keyCredential
   }


   if ($newCertAlreadyExists -eq $false) {
      Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) will be added" -ForegroundColor Cyan
      $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
      $keyCredential.Type = "AsymmetricX509Cert"
      $keyCredential.Usage = "Verify"
      $keyCredential.Key = [System.Text.Encoding]::ASCII.GetBytes($credValue)

      $keyCredentialsArray += $keyCredential

      $servicePrincipalObj.KeyCredentials = $keyCredentialsArray
      Update-MgServicePrincipal -ServicePrincipalId $p.Id -BodyParameter $servicePrincipalObj
   } else {
      Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) already exists and will not be uploaded again" -ForegroundColor Yellow
   }
} else {
   $params = @{
      type = "AsymmetricX509Cert"
      usage = "Verify"
      key = [System.Text.Encoding]::ASCII.GetBytes($credValue)
   }

   Write-Host "[+] This is the first key which will be added to this service principal" -ForegroundColor Cyan
   Update-MgServicePrincipal -ServicePrincipalId $p.Id -KeyCredentials $params
}

Eseguire lo script di PowerShell creato nel passaggio precedente. Ad esempio:
```
.\UploadAuthCert.ps1
```
Dopo avere avviato lo script, viene visualizzata una finestra di dialogo relativa alle credenziali. Immettere le credenziali per l'account amministratore tenant nell'organizzazione Microsoft Entra di Microsoft Online. Dopo aver eseguito lo script, lasciare aperto 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à del nome host per gli endpoint HTTP di Exchange interni ed esterni con l'ID Microsoft Entra

È 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 | Format-List server,*url*
Get-WebServicesVirtualDirectory | Format-List server,*url*
Get-OABVirtualDirectory | Format-List server,*url*

Nota

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

Salvare il testo seguente in un file di script di PowerShell denominato, ad esempio, RegisterEndpoints.ps1. 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'"
 $x.ServicePrincipalNames += "https://mail.contoso.com/"
 $x.ServicePrincipalNames += "https://autodiscover.contoso.com/"
 Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $x.ServicePrincipalNames

In Windows PowerShell connesso a Microsoft Graph eseguire lo script di Windows PowerShell creato nel passaggio precedente. Ad esempio:
```
.\RegisterEndpoints.ps1
```
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-Object -ExpandProperty ServicePrincipalNames | Sort-Object
```

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

In questo passaggio viene configurato un che IntraOrganizationConnector consente a Exchange Server locale di raggiungere l'organizzazione di Exchange Online. Questo connettore consente la disponibilità delle funzionalità e la connettività del servizio tra le organizzazioni. È possibile usare il cmdlet Get-IntraOrganizationConfiguration sia nei tenant locali che nei tenant di Microsoft 365 o Office 365 per determinare i valori degli endpoint necessari per il cmdlet New-IntraOrganizationConnector .

Il dominio di routing ibrido viene configurato come indirizzo di destinazione. Il dominio di routing ibrido viene creato automaticamente quando viene creata l'organizzazione di Microsoft 365 o Office 365. Ad esempio, se il primo dominio aggiunto e convalidato nell'organizzazione di Microsoft 365 o Office 365 è contoso.com, l'indirizzo di destinazione sarà contoso.mail.onmicrosoft.com.

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

$ServiceDomain = (Get-AcceptedDomain | Where-Object {$_.DomainName -like "*.mail.onmicrosoft.com"}).DomainName.Address
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

In questo passaggio viene configurato un che IntraOrganizationConnector consente a Exchange Online di raggiungere l'organizzazione di Exchange locale. Questo connettore consente la disponibilità delle funzionalità e la connettività del servizio tra le organizzazioni. È possibile usare il cmdlet Get-IntraOrganizationConfiguration sia nei tenant locali che nei tenant di Microsoft 365 o Office 365 per determinare i valori degli endpoint necessari per il cmdlet New-IntraOrganizationConnector .

È consigliabile aggiungere tutti i domini SMTP usati nell'organizzazione locale di Exchange (ad eccezione di initial domain e hybrid routing domain) come TargetAddressDomains. Se si dispone di più domini SMTP, aggiungerli come elenco delimitato da virgole ,contoso.comtailspintoys.com. È anche necessario specificare l'endpoint di individuazione automatica locale come DiscoveryEndpoint.

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

New-IntraOrganizationConnector -Name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises AutoDiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain(s)>

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

Avviso

Exchange Server 2007, Exchange Server 2010 ed Exchange Server 2013 hanno raggiunto la fine del supporto.

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 exchange locale 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.

Un AvailabilityAddressSpace deve essere configurato nei server Accesso client di 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à visualizzato 15.0 (Build 847.32) o superiore per il AdminDisplayVersion parametro .

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

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises external Exchange Web Services URL> -ForestName <your hybrid routing domain> -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 ed 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 di Exchange Online possa connettersi correttamente all'organizzazione di Exchange locale, connettersi a PowerShell di Exchange Online 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

Esempio:

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

Importante

È possibile ignorare l'errore The SMTP address has no mailbox associated with it. . È importante che il ResultTask parametro restituisca un valore di 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

Condividi tramite

Configurazione dell'autenticazione OAuth tra organizzazioni Exchange ed Exchange Online

Che cosa è necessario sapere prima di iniziare?

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

Glossario

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

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

Passaggio 3: esportare il certificato di autorizzazione in locale

Passaggio 4: Caricare il certificato di autorizzazione locale in Microsoft Entra Access Control Service (ACS)

Passaggio 5: Registrare tutte le autorità del nome host per gli endpoint HTTP di Exchange interni ed esterni con l'ID Microsoft Entra

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

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

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

Come verificare se l'operazione ha avuto esito positivo

Risorse aggiuntive