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

Gilt für: Exchange Server 2013

In reinen Exchange 2013-Hybridbereitstellungen wird bei Verwendung des Assistenten für die Hybridkonfiguration die OAuth-Authentifizierung konfiguriert. Für gemischte Exchange 2013/2010- und Exchange 2013/2007-Hybridbereitstellungen wird die neue OAuth-basierte Hybridbereitstellungs-Authentifizierungsverbindung zwischen Microsoft 365 oder Office 365 und lokalen Exchange Organisationen nicht vom Assistenten für die Hybridkonfiguration konfiguriert. 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:

  • Nachrichtendatensätzeverwaltung (MESSAGE Records Management, MRM)
  • Compliance-eDiscovery-Suche unter Exchange
  • Compliance-Archivierung in Exchange

Sie sollten in allen gemischten Exchange-Organisationen, in denen eine Hybridbereitstellung mit Exchange 2013 und Exchange Online implementiert wird, die Exchange-OAuth-Authentifizierung konfigurieren, nachdem Sie die Hybridbereitstellung mit dem Assistenten für die Hybridkonfiguration konfiguriert haben.

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 werden, und einige Featurebeschränkungen können gelten. Weitere Informationen finden Sie unter Office 365 betrieben von 21Vianet.

Was sollten Sie wissen, bevor Sie beginnen?

Tipp

Sie haben Probleme? Bitten Sie in den Exchange-Foren um Hilfe. Sie finden die Foren unter folgenden Links: 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 Organisation

Bei diesem Verfahren müssen Sie eine verifizierte Domäne für Ihre Exchange-Online-Organisation angeben. Es sollte dieselbe Domäne sein, die für die cloudbasierten E-Mail-Konten verwendet wird, wie die primäre SMTP-Domäne. Diese Domäne wird wie <your verified domain> im folgenden Verfahren bezeichnet.

Führen Sie den folgenden Befehl in der Exchange-Verwaltungsshell (Exchange PowerShell) in Ihrer lokalen Exchange Organisation 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

Wenn Sie sich in der GCC High- oder DOD-Instanz befinden, müssen Sie Folgendes 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 Koexistenzdomäne des Mandanten hat das Format 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 auf dem Exchange Server direkt ausführen, um das lokale Autorisierungszertifikat zu exportieren, das dann im nächsten Schritt in Ihre Exchange Online Organisation 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. Beispiel:

    .\ExportAuthCert.ps1
    

Schritt 4: Hochladen des lokalen Autorisierungszertifikats an Azure Active Directory Access Control Service (ACS)

Als Nächstes müssen Sie Windows PowerShell verwenden, um das lokale Autorisierungszertifikat hochzuladen, das Sie im vorhergehenden Schritt an Azure Active Directory-Zugriffssteuerungsdienste (Access Control Services, ACS) exportiert haben. Dafür müssen Sie die Azure Active Directory-Modul für Windows PowerShell-Cmdlets installieren. Wenn es nicht installiert ist, führen Sie den folgenden Befehl in einer Powershell aus, die als Adminsitrator ausgeführt wird, um das Azure Active Directory-Modul für Windows PowerShell zu installieren.

Install-Module -Name MSOnline

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

  1. Klicken Sie auf die Verknüpfung Azure Active Directory-Modul für Windows PowerShell, um einen Windows PowerShell-Arbeitsbereich zu öffnen, in dem die Azure AD-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden unter Verwendung der Windows PowerShell für die Azure Active Directory-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 Ihrer Microsoft Online Azure AD-Organisation ein. Lassen Sie Windows PowerShell nach der Ausführung des Skripts für die Azure AD-Sitzung geöffnet. Sie werden diese zum Ausführen eines PowerShell-Skripts im nächsten Schritt erneut nutzen.

Schritt 5: Registrieren aller Hostnamen-Behörden für Ihre internen und externen lokalen Exchange HTTP-Endpunkte mit Azure Active Directory

Sie müssen das Skript in diesem Schritt für jeden Endpunkt in Ihrer lokalen Exchange Organisation ausführen, auf den öffentlich zugegriffen werden kann (interne und externe URLs, wenn Sie die moderne Hybridauthentifizierung einrichten). Nehmen Sie beispielsweise an, dass Exchange von außerhalb unter https://mail.contoso.com/ews/exchange.asmx verfügbar ist. In diesem Fall wird der Dienstprinzipalname von: https://mail.contoso.com verwendet. Bei der Registrierung zusätzlicher externer Hostnamen-Berechtigungen besteht keine Begrenzung.

Wenn Sie sich der Exchange Endpunkte in Ihrer lokalen Exchange Organisation nicht sicher sind, können Sie eine Liste der extern konfigurierten Webdienstendpunkte abrufen, indem Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange Organisation ausführen:

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

Hinweis

Für eine erfolgreiche Ausführung des folgenden Skripts ist eine Verbindung der Windows PowerShell für Azure Active Directory mit Ihrem Microsoft Online Azure AD-Mandanten erforderlich, wie unter 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/ & https://autodiscover.contoso.com/ sie durch die entsprechende Hostnamen-Autorität für Ihre lokale Exchange Organisation.

    $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 in Windows PowerShell für Azure Active Directory das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Beispiel:

    .\RegisterEndpoints.ps1
    
  3. Um zu überprüfen, ob alle Datensätze hinzugefügt wurden, müssen wir Folgendes ausführen. Wir suchen https://namespace nach Einträgen für alle URLs, nicht für 000000002-0000-0ff1-ce00-00000000000/namespace-Einträge.

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

Schritt 6: Erstellen eines IntraOrganizationConnector von Ihrer lokalen Organisation zum 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 Organisation erstellt wird. Wenn beispielsweise die Domäne Ihrer Organisation, die in der Microsoft 365 oder Office 365 Organisation 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 Ihrer Microsoft 365 oder Office 365 Organisation zu Ihrer lokalen Exchange Organisation

Sie müssen eine Zieladresse für die Postfächer definieren, die in Ihrer lokalen Organisation gehostet werden. Wenn die primäre SMTP-Adresse Ihrer Organisation "contoso.com" lautet, so ist dies "contoso.com". Sie müssen außerdem den externen Autodiscover-Endpunkt für Ihre lokale Organisation definieren. Wenn Ihr Unternehmen "contoso.com" ist, so ist dies in der Regel einer der folgenden:

  • 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 Lokalen als auch in Microsoft 365- oder Office 365-Mandanten verwenden, um die Endpunktwerte zu ermitteln, die für das Cmdlet New-IntraOrganizationConnector erforderlich sind.

Nachdem Sie eine Verbindung mit Exchange Online PowerShell hergestellt haben, ersetzen <your on-premises Autodiscover endpoint> Sie Ihre Werte und <your on-premises SMTP domain> 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 einer Organisation mit Exchange vor Version 2013 konfigurieren, müssen Sie mindestens einen Server mit Exchange 2013 SP1 oder höher mit den Clientzugriffs- und Postfachserverrollen in Ihrer vorhandenen Exchange-Organisation installieren. Die Exchange 2013-Clientzugriffs- und -Postfachserver fungieren als Front-End-Server und koordinieren die Kommunikation zwischen Ihrer vorhandenen lokalen Exchange-Organisation und der Exchange Online-Organisation. Diese Kommunikation beinhaltet auch den Nachrichtentransport zwischen der lokalen und der Exchange Online-Organisation sowie Messagingfunktionen. Für eine bessere Zuverlässigkeit und höhere Verfügbarkeit der Funktionen der Hybridbereitstellung sollten Sie mehrere Exchange 2013-Server in der lokalen Organisation installieren.

In einer gemischten Bereitstellung mit Exchange 2013/2010 oder Exchange 2013/2007 wird empfohlen, dass alle mit dem Internet verbundenen Front-End-Server für Ihre lokale Organisation Clientzugriffsserver sind, auf denen Exchange 2013 SP1 oder höher ausgeführt wird. Alle EWS-Anforderungen (Exchange Web Services), die von Microsoft 365 oder Office 365 und Exchange Online stammen, müssen eine Verbindung mit einem(n) Exchange 2013-Clientzugriffsserver(n) in Ihrer lokalen Bereitstellung herstellen. Darüber hinaus müssen alle Exchange-Webdienste-Anforderungen für Exchange Online, die von Ihren lokalen Exchange-Organisationen stammen, mittels Proxy über einen Clientzugriffsserver weitergeleitet werden, auf dem Exchange 2013 SP1 oder höher ausgeführt wird. Da diese Exchange 2013-Clientzugriffsserver diese zusätzlichen eingehenden und ausgehenden Exchange-Webdienste-Anforderungen verarbeiten müssen, ist es wichtig, eine ausreichende Anzahl von Exchange 2013-Clientzugriffsservern verfügbar zu haben, um die Verarbeitungslast handhaben und Verbindungsredundanz bereitstellen zu können. Die Anzahl der erforderlichen Clientzugriffsserver hängt von der durchschnittlichen Menge von Exchange-Webdienste-Anforderungen ab und ist je nach Organisation unterschiedlich.

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

  • Auf den Front-End-Hybridservern wird Exchange 2013 SP1 oder höher ausgeführt.

  • Sie verfügen über eine eindeutige externe Exchange-Webdienste-URL für die Exchange 2013-Server. Die Microsoft 365 oder Office 365 Organisation muss 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 Anforderungen an Hybridbereitstellungsfeatures von der Microsoft 365 oder Office 365 Organisation müssen eine Verbindung mit Exchange 2013-Servern herstellen.

Ein AvailabilityAddressSpace muss auf Clientzugriffsservern vor Exchange 2013 konfiguriert werden, die auf den Exchange Webdienste-Endpunkt Ihrer lokalen Exchange 2013 SP1-Clientzugriffsserver zeigen. 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 Ihre Exchange Online Organisation erfolgreich eine Verbindung mit Ihrer lokalen Exchange Organisation 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 "Der SMTP-Adresse ist kein Postfach zugeordnet" ignorieren. zurück. Es ist nur wichtig, dass der Parameter "ResultTask " den Wert " Success" zurückgibt. Der letzte Abschnitt der Testausgabe sollte beispielsweise Folgendes lauten:
ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New

Tipp

Sie haben Probleme? Bitten Sie in den Exchange-Foren um Hilfe. Sie finden die Foren unter folgenden Links: Exchange Server.