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?
Geschätzte Zeit bis zum Abschließen dieser Aufgabe: 15 Minuten.
Bevor Sie diese Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Informationen zu den von Ihnen benötigten Berechtigungen finden Sie unter "Verbund- und Zertifikatberechtigungen" im Thema Exchange- und Shellinfrastrukturberechtigungen.
Abgeschlossene Konfiguration Ihrer Hybridbereitstellung mit dem Hybridbereitstellungs-Assistenten. Weitere Informationen finden Sie unter Exchange Server Hybridbereitstellungen.
Informationen zu Tastenkombinationen für die Verfahren in diesem Thema finden Sie unter Tastenkombinationen in der Exchange-Verwaltungskonsole.
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.
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)
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.
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.
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
Führen Sie das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Beispiel:
.\UploadAuthCert.ps1
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.asmx
verfü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.
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/
undhttps://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;
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
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.