Configurer l’authentification OAuth entre des organisations Exchange et Exchange Online

S’applique à : Exchange Server 2013

L’Assistant Configuration hybride configure automatiquement l’authentification OAuth entre Exchange 2013 et Exchange Online organisations. Si votre organization Exchange 2013 contient des serveurs Exchange 2010 ou Exchange 2007, l’Assistant Configuration hybride ne configure pas l’authentification OAuth entre les organisations Exchange locales et en ligne. Ces déploiements continuent à utiliser le processus d'approbation de fédération par défaut. Toutefois, certaines fonctionnalités d'Exchange 2013 sont totalement disponibles dans votre organisation uniquement en utilisant le nouveau protocole d'authentification OAuth d'Exchange.

Le nouveau processus d'authentification OAuth d'Exchange permet actuellement d'activer les fonctionnalités Exchange suivantes :

• Gestion des enregistrements de messages (MRM)
• Découverte électronique locale Exchange
• Archivage local Exchange

Nous recommandons que toutes les organisations Exchange 2013 mixtes configurent l’authentification OAuth Exchange après avoir exécuté l’Assistant Configuration hybride.

Ce qu'il faut savoir avant de commencer

• Durée d'exécution estimée de cette tâche : 15 minutes.

• Des autorisations doivent vous être attribuées avant de pouvoir exécuter cette procédure. Pour voir les autorisations qui vous sont nécessaires, consultez l'entrée d'autorisations « Fédération et certificats » dans la rubrique Autorisations d'infrastructure Exchange et Shell.

• La configuration de votre déploiement hybride à l'aide de l'Assistant Déploiement hybride est terminée. Pour plus d’informations, consultez Exchange Server déploiements hybrides.

• Pour des informations sur les raccourcis clavier applicables aux procédures de cette rubrique, voir Raccourcis clavier dans Exchange 2013Raccourcis clavier dans le Centre d'administration Exchange.

Comment configurer l’authentification OAuth entre vos organisations Exchange Online et Exchange locale ?

Étape 1 : Créer les objets serveur d’autorisation pour votre Exchange Online organization

Pour cette procédure, vous devez spécifier un domaine vérifié pour votre organisation Exchange Online. Il doit s’agir du même domaine que le domaine SMTP principal utilisé pour les comptes de messagerie cloud. Ce domaine est appelé <votre domaine> vérifié dans la procédure suivante.

Exécutez la commande suivante dans Exchange Management Shell (Exchange PowerShell) dans votre organization Exchange local :

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"

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"

Étape 2 : activer l’application partenaire pour votre organisation Exchange Online

Exécutez la commande suivante dans Exchange PowerShell dans votre organisation Exchange locale.

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

Étape 3 : exporter le certificat d’autorisation local

Dans cette étape, vous devez exécuter un script PowerShell directement sur le serveur Exchange pour exporter le certificat d’autorisation local, qui est ensuite importé dans votre Exchange Online organization à l’étape suivante.

1. Enregistrez le texte suivant dans un fichier de script PowerShell nommé, par exemple, 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. Dans Exchange PowerShell dans votre organisation Exchange locale, exécutez le script PowerShell que vous avez créé à l'étape précédente. Par exemple :

   .\ExportAuthCert.ps1
   

Étape 4 : Charger le certificat d’autorisation local sur Microsoft Entra Access Control Service (ACS)

Ensuite, utilisez Microsoft Graph PowerShell pour charger le certificat d’autorisation local que vous avez exporté à l’étape précédente vers Microsoft Entra Access Control Services (ACS). Si le module n’est pas installé, ouvrez une fenêtre Windows PowerShell en tant qu’administrateur et exécutez la commande suivante :

Install-Module -Name Microsoft.Graph.Applications

Effectuez les étapes suivantes après l’installation de Microsoft Graph PowerShell.

1. Ouvrez un espace de travail Windows PowerShell sur lequel les applets de commande Microsoft Graph sont installées. Toutes les commandes de cette étape seront exécutées à l’aide du Windows PowerShell connecté à la console Microsoft Graph.

2. Enregistrez le texte suivant dans un fichier de script PowerShell nommé, par exemple, 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. Exécutez le script PowerShell que vous avez créé à l'étape précédente. Par exemple :

   .\UploadAuthCert.ps1
   

4. Une fois le script lancé, une boîte de dialogue d'informations d'identification s'affiche. Entrez les informations d’identification du compte d’administrateur client dans votre Microsoft Entra organization Microsoft Online. Après avoir exécuté le script, laissez le Windows PowerShell connecté à la session Microsoft Graph ouvert. Vous l'utiliserez pour exécuter un script PowerShell à l'étape suivante.

Étape 5 : Inscrire toutes les autorités de nom d’hôte pour vos points de terminaison HTTP Exchange locaux internes et externes avec Microsoft Entra ID

Vous devez exécuter le script dans cette étape pour chaque point de terminaison accessible publiquement dans votre organization Exchange local, y compris les URL internes et externes pour l’authentification moderne hybride). Par exemple, si Exchange est disponible en externe sur https://mail.contoso.com/ews/exchange.asmx, utilisez le nom https://mail.contoso.comdu principal de service . Il n'y a pas de limite concernant l'enregistrement d'autorités de nom d'hôte externes supplémentaires.

Pour confirmer les points de terminaison Exchange dans votre organization local, exécutez les commandes suivantes dans Exchange Management Shell :

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

1. Enregistrez le texte suivant dans un fichier de script PowerShell nommé, par exemple, RegisterEndpoints.ps1. Cet exemple utilise un contoso.com. Remplacez et https://autodiscover.contoso.com/ par https://mail.contoso.com/ l’autorité de nom d’hôte appropriée pour votre organization Exchange local.

    $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. Dans Windows PowerShell connecté à Microsoft Graph, exécutez le script Windows PowerShell que vous avez créé à l’étape précédente. Par exemple :

   .\RegisterEndpoints.ps1
   

3. Pour vérifier que tous les enregistrements ont été ajoutés, exécutez la commande suivante dans Windows PowerShell connecté à Microsoft Graph et recherchez https://namespace les entrées dans les résultats.

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

Étape 6 : Créer un IntraOrganizationConnector à partir de votre organization local vers Microsoft 365 ou Office 365

Vous devez définir une adresse cible pour vos boîtes aux lettres hébergées dans Exchange Online. Cette adresse cible est créée automatiquement lors de la création de votre microsoft 365 ou Office 365 organization. Par exemple, si le domaine de votre organization hébergé dans Microsoft 365 ou Office 365 organization est « contoso.com », votre adresse de service cible est « contoso.mail.onmicrosoft.com ».

Avec Exchange PowerShell, exécutez la cmdlet suivante dans votre organisation 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

Étape 7 : Créer un IntraOrganizationConnector à partir de votre Microsoft 365 ou Office 365 organization vers votre organization Exchange local

Vous devez définir une adresse cible pour vos boîtes aux lettres hébergées dans votre organisation locale. Si l’adresse SMTP principale de votre organization se trouve dans « contoso.com », les adresses cibles se trouveraient dans « contoso.com ».

Vous devez également définir le point de terminaison de découverte automatique externe de votre organisation locale. Si votre entreprise est « contoso.com », le point de terminaison de découverte automatique est généralement l’une des valeurs suivantes :

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

Après vous être connecté à Exchange Online PowerShell, remplacez et par <your on-premises Autodiscover endpoint><your on-premises SMTP domain> vos valeurs et exécutez la commande suivante :

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

Étape 8 : configurer un objet AvailabilityAddressSpace pour tous les serveurs Exchange de version antérieure à 2013 SP1

Lorsque vous configurez un déploiement hybride dans des organisations Exchange plus anciennes, vous avez besoin d’au moins un serveur Exchange 2013 exécutant Exchange 2013 SP1 ou version ultérieure. Le serveur Exchange 2013 nécessite les rôles serveur d’accès au client et de serveur de boîte aux lettres. Le serveur Exchange 2013 coordonne les communications entre votre organization Exchange local existant et le Exchange Online organization. Nous vous recommandons vivement d'installer plusieurs serveurs Exchange 2013 dans votre organisation sur site pour renforcer la fiabilité et la disponibilité des fonctionnalités de déploiement hybride.

Dans les organisations Exchange 2013 avec Exchange 2010 ou Exchange 2007, nous recommandons que tous les serveurs frontaux accessibles sur Internet soient des serveurs d’accès au client Exchange 2013 exécutant SP1 ou version ultérieure. Toutes les demandes de services Web Exchange (EWS) doivent passer par un serveur d’accès au client Exchange 2013. Cette exigence inclut les demandes de Microsoft 365 vers votre organization Exchange local et les demandes de votre organization Exchange local vers Microsoft 365. Il est important que vous disposiez de suffisamment de serveurs d’accès au client Exchange 2013 pour gérer la charge de traitement et fournir une redondance de connexion. Le nombre de serveurs d’accès au client dont vous avez besoin dépend de la quantité moyenne de demandes EWS et varie selon organization.

Avant d'effectuer l'étape suivante, vérifiez que :

• Les serveurs hybrides front-end sont Exchange 2013 SP1 ou version ultérieure.
• Vous disposez d'une URL EWS externe unique pour les serveurs Exchange 2013. Microsoft 365 ou Office 365 organization doit se connecter à ces serveurs pour que les demandes basées sur le cloud pour que les fonctionnalités hybrides fonctionnent correctement.
• Les serveurs ont les rôles serveur de boîtes aux lettres et serveur d'accès au client
• Tout serveur de boîtes aux lettres et d'accès au client Exchange 2010/2007 existant dispose de la dernière mise à jour cumulative ou du dernier Service Pack (SP).

Un availabilityAddressSpace doit être configuré sur des serveurs d’accès au client antérieurs à Exchange 2013 qui pointe vers le point de terminaison des services Web Exchange de vos serveurs d’accès au client Exchange 2013 SP1 locaux. Ce point de terminaison est le même que celui précédemment décrit à l'étape 5 ou peut être déterminé par l'exécution de la cmdlet suivante sur votre serveur d'accès au client Exchange 2013 SP1 local :

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Pour configurer l’objet AvailabilityAddressSpace, utilisez Exchange PowerShell et exécutez l’applet de commande suivante dans votre organisation 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

Comment savoir si cela a fonctionné ?

Vous pouvez vérifier que l'authentification OAuth est correcte à l'aide de la cmdlet Test-OAuthConnectivity. Cette applet de commande vérifie que les points de terminaison Exchange et Exchange Online locaux peuvent authentifier correctement les demandes les uns des autres.

Pour vérifier que votre organisation Exchange locale peut se connecter correctement à Exchange Online, exécutez la commande suivante dans Exchange PowerShell dans votre organisation locale :

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

Pour vérifier que votre Exchange Online organization peut se connecter correctement à votre organization Exchange local, connectez-vous à Exchange Online PowerShell et exécutez la commande suivante :

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

Ainsi, à titre d’exemple,

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