Konfigurieren der OAuth-Authentifizierung zwischen Exchange- und Exchange Online-Organisationen

Gilt für: Exchange Server 2013

Der Hybridkonfigurations-Assistent konfiguriert automatisch die OAuth-Authentifizierung zwischen Exchange 2013 und Exchange Online Organisationen. Wenn Ihre Exchange 2013-organization Exchange 2010- oder Exchange 2007-Server enthält, konfiguriert der Hybridkonfigurations-Assistent keine OAuth-Authentifizierung zwischen der lokalen und der Exchange Online-Organisation. In diesen Bereitstellungen wird standardmäßig weiterhin der Verbundvertrauensstellungsprozess verwendet. Bestimmte Exchange 2013-Funktionen sind jedoch nur vollständig in Ihrer gesamten Organisation verfügbar, wenn das neue Exchange OAuth-Authentifizierungsprotokoll benutzt wird.

Mit dem neuen Exchange OAuth-Authentifizierungsprozess werden derzeit die folgenden Exchange-Funktionen aktiviert:

  • Nachrichtendatensatzverwaltung (Message Records Management, MRM)
  • Compliance-eDiscovery-Suche unter Exchange
  • Compliance-Archivierung in Exchange

Es wird empfohlen, dass alle gemischten Exchange 2013-Organisationen die Exchange OAuth-Authentifizierung konfigurieren, nachdem der Hybridkonfigurations-Assistent ausgeführt wurde.

Wichtig

  • Wenn in Ihrer lokalen Organisation nur Exchange 2013-Server mit installiertem kumulativen Update 5 oder höher ausgeführt werden, führen Sie den Assistenten für die Hybridbereitstellung anstelle der Schritte in diesem Thema aus.

  • Dieses Feature von Exchange Server 2013 ist nicht vollständig kompatibel mit Office 365, die von 21Vianet in China betrieben wird, und es gelten möglicherweise einige Featurebeschränkungen. Weitere Informationen finden Sie unter Office 365 betrieben von 21Vianet.

Was sollten Sie wissen, bevor Sie beginnen?

Tipp

Liegt ein Problem vor? Bitten Sie in den Exchange-Foren um Hilfe. Besuchen Sie die Foren auf Exchange Server.

Wie konfigurieren Sie die OAuth-Authentifizierung zwischen Ihren lokalen Exchange- und den Exchange-Online-Organisationen?

Schritt 1: Erstellen der Autorisierungsserverobjekte für Ihre Exchange Online organization

Bei diesem Verfahren müssen Sie eine verifizierte Domäne für Ihre Exchange-Online-Organisation angeben. Dabei sollte es sich um dieselbe Domäne handeln, die wie die primäre SMTP-Domäne verwendet wird, die für die cloudbasierten E-Mail-Konten verwendet wird. Diese Domäne wird im folgenden Verfahren als <Ihre überprüfte Domäne> bezeichnet.

Führen Sie den folgenden Befehl in der Exchange-Verwaltungsshell (Exchange PowerShell) in Ihrer lokalen Exchange-organization aus:

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"

Hinweis

In GCC High oder DoD müssen Sie stattdessen die folgenden Befehle verwenden:

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"

Hinweis

Die Mandantenkoexistenzdomäne hat die Form contoso.mail.onmicrosoft.com

Schritt 2: Aktivieren der Partneranwendung für Ihre Exchange-Online-Organisation

Führen Sie den folgenden Befehl in der Exchange PowerShell in Ihrer lokalen Exchange-Organisation aus.

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

Schritt 3: Exportieren des lokalen Autorisierungszertifikats

In diesem Schritt müssen Sie ein PowerShell-Skript direkt auf dem Exchange-Server ausführen, um das lokale Autorisierungszertifikat zu exportieren, das dann im nächsten Schritt in Ihre Exchange Online organization importiert wird.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa ExportAuthCert.ps1 benannt werden kann.

    $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. Führen Sie unter Exchange PowerShell in Ihrer lokalen Exchange-Organisation das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Zum Beispiel:

    .\ExportAuthCert.ps1
    

Schritt 4: Hochladen des lokalen Autorisierungszertifikats in Microsoft Entra Access Control Service (ACS)

Verwenden Sie als Nächstes das Azure Active Directory-Modul für Windows PowerShell, um das im vorherigen Schritt exportierte lokale Autorisierungszertifikat in Microsoft Entra Access Control Services (ACS) hochzuladen. Wenn Sie das Modul nicht installiert haben, öffnen Sie ein Windows PowerShell Fenster als Administrator, und führen Sie den folgenden Befehl aus:

Install-Module -Name MSOnline

Führen Sie die folgenden Schritte aus, nachdem das Azure Active Directory-Modul für Windows PowerShell installiert wurde.

  1. Klicken Sie auf das Azure Active Directory-Modul für Windows PowerShell Verknüpfung, um einen Windows PowerShell Arbeitsbereich zu öffnen, in dem die Microsoft Entra-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden mithilfe der Windows PowerShell für Microsoft Entra ID-Konsole ausgeführt.

  2. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa UploadAuthCert.ps1 benannt werden kann.

    Connect-MsolService
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    $objFSO = New-Object -ComObject Scripting.FileSystemObject
    $CertFile = $objFSO.GetAbsolutePathName($CertFile)
    $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    $cer.Import($CertFile)
    $binCert = $cer.GetRawCertData()
    $credValue = [System.Convert]::ToBase64String($binCert)
    $ServiceName = "00000002-0000-0ff1-ce00-000000000000"
    $p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
    New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue
    
  3. Führen Sie das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Beispiel:

    .\UploadAuthCert.ps1
    
  4. Nachdem Sie das Skript gestartet haben, wird ein Dialogfeld für Anmeldeinformationen angezeigt. Geben Sie die Anmeldeinformationen für das Mandantenadministratorkonto in Ihrem Microsoft Online-Microsoft Entra organization ein. Lassen Sie nach dem Ausführen des Skripts die Windows PowerShell für Microsoft Entra Sitzung geöffnet. Sie werden diese zum Ausführen eines PowerShell-Skripts im nächsten Schritt erneut nutzen.

Schritt 5: Registrieren aller Hostnamenautoritäten für Ihre internen und externen lokalen Exchange-HTTP-Endpunkte mit Microsoft Entra ID

Sie müssen das Skript in diesem Schritt für jeden öffentlich zugänglichen Endpunkt in Ihrer lokalen Exchange-organization ausführen, einschließlich interner und externer URLs für die moderne Hybridauthentifizierung). Wenn Exchange beispielsweise extern unter https://mail.contoso.com/ews/exchange.asmxverfügbar ist, verwenden Sie den Dienstprinzipalnamen https://mail.contoso.com. Bei der Registrierung zusätzlicher externer Hostnamen-Berechtigungen besteht keine Begrenzung.

Führen Sie die folgenden Befehle in der Exchange-Verwaltungsshell aus, um die Exchange-Endpunkte in Ihrer lokalen organization zu bestätigen:

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

Hinweis

Das folgende Skript erfordert, dass die Windows PowerShell für Microsoft Entra-ID mit Ihrem Microsoft 365-organization verbunden ist, wie in Schritt 4 im vorherigen Abschnitt erläutert.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa RegisterEndpoints.ps1 benannt werden kann. In diesem Beispiel wird eine contoso.com verwendet. Ersetzen Sie https://mail.contoso.com/ und https://autodiscover.contoso.com/ durch die entsprechende Hostnamenautorität für Ihre lokale Exchange-organization.

    $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
    $x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
    $x.ServicePrincipalnames.Add("https://mail.contoso.com/");
    $x.ServicePrincipalnames.Add("https://autodiscover.contoso.com/");
    Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;
    
  2. Führen Sie Windows PowerShell für Microsoft Entra-ID das Windows PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Zum Beispiel:

    .\RegisterEndpoints.ps1
    
  3. Um zu überprüfen, ob alle Datensätze hinzugefügt wurden, führen Sie den folgenden Befehl in Windows PowerShell für Microsoft Entra-ID aus, und suchen https://namespace Sie in den Ergebnissen nach Einträgen.

    Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
    

Schritt 6: Erstellen eines IntraOrganizationConnector aus Ihrem lokalen organization zu Microsoft 365 oder Office 365

Sie müssen eine Zieladresse für Ihre Postfächer definieren, die in Exchange Online gehostet werden. Diese Zieladresse wird automatisch erstellt, wenn Ihre Microsoft 365- oder Office 365 organization erstellt wird. Wenn beispielsweise die Domäne Ihres organization, die in Microsoft 365 oder Office 365 organization gehostet wird, "contoso.com" lautet, lautet Ihre Zieldienstadresse "contoso.mail.onmicrosoft.com".

Führen Sie unter Verwendung der Exchange PowerShell das folgende Cmdlet in Ihrer lokalen Organisation aus:

$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

Schritt 7: Erstellen eines IntraOrganizationConnector von Ihrem Microsoft 365- oder Office 365 organization zu Ihrem lokalen Exchange-organization

Sie müssen eine Zieladresse für die Postfächer definieren, die in Ihrer lokalen Organisation gehostet werden. Wenn sie organization primäre SMTP-Adresse in "contoso.com" befindet, befinden sich die Zieladressen in "contoso.com".

Sie müssen außerdem den externen Autodiscover-Endpunkt für Ihre lokale Organisation definieren. Wenn Ihr Unternehmen "contoso.com" ist, weist der AutoErmittlungsendpunkt in der Regel einen der folgenden Werte auf:

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

Hinweis

Sie können das Cmdlet Get-IntraOrganizationConfiguration sowohl in Ihren lokalen Mandanten als auch in Microsoft 365 oder Office 365 Mandanten verwenden, um die Endpunktwerte zu bestimmen, die für das New-IntraOrganizationConnector-Cmdlet erforderlich sind.

Nachdem Sie eine Verbindung mit Exchange Online PowerShell hergestellt haben, ersetzen <your on-premises Autodiscover endpoint> Sie und <your on-premises SMTP domain> durch Ihre Werte, und führen Sie den folgenden Befehl aus:

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

Schritt 8: Konfigurieren eines AvailabilityAddressSpace für alle Exchange-Server vor Version 2013 SP1

Wenn Sie eine Hybridbereitstellung in älteren Exchange-Organisationen konfigurieren, benötigen Sie mindestens einen Exchange 2013-Server, auf dem Exchange 2013 SP1 oder höher ausgeführt wird. Der Exchange 2013-Server erfordert die Serverrollen Clientzugriff und Postfach. Der Exchange 2013-Server koordiniert die Kommunikation zwischen Ihrem vorhandenen lokalen Exchange-organization und dem Exchange Online organization. Um die Zuverlässigkeit und die Verfügbarkeit der Funktionen der hybriden Bereitstellung zu verbessern, wird dringend empfohlen, mehrere Exchange 2013-Server in der lokalen Organisation zu installieren.

In Exchange 2013-Organisationen mit Exchange 2010 oder Exchange 2007 wird empfohlen, dass alle Front-End-Server mit Internetzugriff Exchange 2013-Clientzugriffsserver mit SP1 oder höher sind. Alle Exchange-Webdienste (EWS)-Anforderungen müssen einen Exchange 2013-Clientzugriffsserver durchlaufen. Diese Anforderung umfasst Anforderungen von Microsoft 365 an Ihre lokale Exchange-organization und Anforderungen von Ihrem lokalen Exchange-organization an Microsoft 365. Es ist wichtig, dass Sie über genügend Exchange 2013-Clientzugriffsserver verfügen, um die Verarbeitungslast zu bewältigen und Verbindungsredundanz bereitzustellen. Die Anzahl der benötigten Clientzugriffsserver hängt von der durchschnittlichen Anzahl der EWS-Anforderungen ab und variiert je nach organization.

Bevor Sie den folgenden Schritt ausführen, stellen Sie Folgendes sicher:

  • Die Front-End-Hybridserver sind Exchange 2013 SP1 oder höher.
  • Sie verfügen über eine eindeutige externe Exchange-Webdienste-URL für die Exchange 2013-Server. Die Microsoft 365- oder Office 365 organization müssen eine Verbindung mit diesen Servern herstellen, damit cloudbasierte Anforderungen für Hybridfeatures ordnungsgemäß funktionieren.
  • Die Server verfügen sowohl über die Postfach- als auch die Clientzugriffsrolle.
  • Für alle vorhandenen Exchange 2010/2007-Postfach- und -Clientzugriffsserver wurde das neueste kumulative Update oder Service Pack (SP) angewendet.

Hinweis

Vorhandene Exchange 2010/2007-Postfachserver können weiterhin Exchange 2010/2007-Clientzugriffsserver als Front-End-Server für Verbindungen mit nicht hybriden Funktionen verwenden. Nur Hybridbereitstellungsfeatureanforderungen von Microsoft 365 oder Office 365 organization müssen eine Verbindung mit Exchange 2013-Servern herstellen.

Ein AvailabilityAddressSpace muss auf Clientzugriffsservern vor Exchange 2013 konfiguriert werden, die auf den Exchange-Webdienstendpunkt Ihrer lokalen Exchange 2013 SP1-Clientzugriffsserver verweist. Dieser Endpunkt ist derselbe Endpunkt, der zuvor in Schritt 5 dargelegt wurde, oder kann durch das Ausführen des folgenden Cmdlets auf Ihrem lokalen Exchange 2013 SP1-Clientzugriffsserver festgelegt werden.

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Hinweis

Wenn virtuelle Verzeichnisinformationen von mehreren Servern zurückgegeben werden, vergewissern Sie sich, dass Sie den für einen Exchange 2013 SP1-Clientzugriffsserver zurückgegebenen Endpunkt verwenden. Für den Parameter AdminDisplayVersion wird 15.0 (Build 847.32) oder höher angezeigt.

Um den AvailabilityAddressSpace zu konfigurieren, verwenden Sie Exchange PowerShell und starten Sie das folgende Cmdlet in Ihrer lokalen Organisation:

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

Woher wissen Sie, dass dieses Verfahren erfolgreich war?

Sie können die Korrektheit der OAuth-Konfiguration verifizieren, indem Sie das Test-OAuthConnectivity-Cmdlet verwenden. Mit diesem Cmdlet kann überprüft werden, ob die lokalen Exchange- und Exchange Online-Endpunkte erfolgreich gegenseitige Anforderungen authentifizieren können.

Wenn Sie überprüfen möchten, ob Ihre lokale Exchange-Organisation erfolgreich eine Verbindung mit Exchange Online herstellen kann, müssen Sie den folgenden Befehl in der Exchange PowerShell in Ihrer lokalen Organisation ausführen:

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

Um zu überprüfen, ob Ihr Exchange Online organization erfolgreich eine Verbindung mit Ihrem lokalen Exchange-organization herstellen kann, stellen Sie eine Verbindung mit Exchange Online PowerShell her, und führen Sie den folgenden Befehl aus:

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

Beispiel:

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

Wichtig

Sie können den Fehler "Der SMTP-Adresse ist kein Postfach zugeordnet." ignorieren. Es ist nur wichtig, dass der ResultTask-Parameter den Wert Success zurückgibt. Der letzte Abschnitt der Testausgabe sollte z. B.:

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

Tipp

Liegt ein Problem vor? Bitten Sie in den Exchange-Foren um Hilfe. Besuchen Sie die Foren auf Exchange Server.