Partager via


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

L’Assistant Configuration hybride configure automatiquement l’authentification OAuth entre les organisations Exchange Server locales et Exchange Online. Si votre organisation Exchange 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 sont uniquement entièrement disponibles dans votre organisation à l’aide du nouveau protocole d’authentification OAuth 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.

Importante

  • Si votre organisation locale exécute uniquement des serveurs Exchange 2013 avec la mise à jour cumulative 5 ou ultérieure, Exchange 2016 ou Exchange 2019, exécutez l’Assistant Configuration hybride au lieu d’effectuer les étapes décrites dans cette rubrique.

  • Cette fonctionnalité d'Exchange Server 2013 n'est pas entièrement compatible avec les systèmes Office 365 exécutés par 21Vianet en Chine et certaines limitations de fonctionnalités peuvent s'appliquer. Pour plus d’informations, voir Office 365 géré par 21Vianet.

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 Entrée d'autorisations de « Fédération et certificats » dans la rubrique Autorisations d'infrastructure Exchange et Shell.

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

  • 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.

Conseil

Vous rencontrez des difficultés ? Demandez de l’aide en participant aux forums Exchange. Visitez les forums sur Exchange Server.

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

Glossaire

Domaine initial : premier domaine approvisionné dans le locataire. Par exemple : contoso.onmicrosoft.com. Il est appelé <domaine> initial de votre locataire dans cette documentation.

Domaine de routage hybride : le domaine de routage hybride dans les environnements Hybrides Exchange, comme contoso.mail.onmicrosoft.com, est utilisé pour gérer le flux de messagerie entre les serveurs Exchange locaux et Exchange Online. Il garantit une communication et une remise de messages transparentes dans les deux environnements. Il est appelé <votre domaine> de routage hybride dans cette documentation.

Microsoft Online Email Routing Address (MOERA) : adresse construite à partir du préfixe de userPrincipalName l’utilisateur, plus le suffixe de domaine initial, qui est automatiquement ajouté à dans l’ID proxyAddress Microsoft Entra. Par exemple : smtp:john.doe@contoso.onmicrosoft.com. Nous n’utilisons pas le MOERA dans cette documentation, mais nous le listons ici par souci d’exhaustivité.

Domaine SMTP principal : le domaine SMTP principal dans Microsoft Exchange Server est le domaine principal utilisé pour les adresses e-mail au sein de l’organisation. Il est appelé <votre domaine> SMTP principal dans cette documentation.

Point de terminaison de découverte automatique : le point de terminaison de découverte automatique est une URL de service web qui fournit des informations de configuration Exchange Server. Il permet aux applications de découvrir et de se connecter automatiquement aux services Exchange. Si votre entreprise utilise, par exemple, contoso.com comme domaine SMTP principal, le point de terminaison de découverte automatique est généralement https://autodiscover.contoso.com/autodiscover/autodiscover.svc ou https://contoso.com/autodiscover/autodiscover.svc. Il est appelé <point de terminaison> de découverte automatique local dans cette documentation.

Services Web Exchange (EWS) : Les services web Exchange (EWS) sont une API multiplateforme qui permet aux applications d’accéder aux éléments de boîte aux lettres tels que les messages électroniques, les réunions et les contacts. Elle est appelée <URL> des services web Exchange externes locaux dans cette documentation.

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

Exécutez la commande suivante dans l’environnement de ligne de commande Exchange Management Shell (Exchange PowerShell) dans votre organisation Exchange locale. Veillez à remplacer les espaces réservés par vos valeurs avant d’exécuter la commande :

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"

Dans GCC High ou DoD, vous devez utiliser les commandes suivantes à la place :

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"

É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 |  Where-Object {$_.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 organisation Exchange Online à l’étape suivante.

  1. Enregistrez le texte suivant dans un fichier de script PowerShell nommé, par exemple, ExportAuthCert.ps1.

    Remarque

    Si vous souhaitez charger le certificat configuré pour devenir le nouveau certificat d’authentification à l’avenir, remplacez par $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint$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)
    
  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 le service de contrôle d’accès Microsoft Entra (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 de 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"
    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
    }
    
  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 de locataire dans votre organisation Microsoft Online Microsoft Entra. Après avoir exécuté le script, laissez Windows PowerShell connecté à la session Microsoft Graph ouverte. 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 l’ID Microsoft Entra

Vous devez exécuter le script dans cette étape pour chaque point de terminaison accessible publiquement dans votre organisation Exchange locale, 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 organisation locale, exécutez les commandes suivantes dans Exchange Management Shell :

Get-MapiVirtualDirectory | Format-List server,*url*
Get-WebServicesVirtualDirectory | Format-List server,*url*
Get-OABVirtualDirectory | Format-List server,*url*

Remarque

Le script suivant exige que windows PowerShell connecté à Microsoft Graph soit connecté à votre organisation Microsoft 365, comme expliqué à l’étape 4 de la section précédente.

  1. Enregistrez le texte suivant dans un fichier de script PowerShell nommé, par exemple, RegisterEndpoints.ps1. Remplacez et https://autodiscover.contoso.com/ par https://mail.contoso.com/ l’autorité de nom d’hôte appropriée pour votre organisation 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
    
  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-Object -ExpandProperty ServicePrincipalNames | Sort-Object
    

Étape 6 : Créer un IntraOrganizationConnector de votre organisation locale vers Microsoft 365 ou Office 365

Dans cette étape, nous configurons un IntraOrganizationConnector qui permet à Exchange Server local d’atteindre votre organisation Exchange Online. Ce connecteur permet la disponibilité des fonctionnalités et la connectivité de service entre les organisations. Vous pouvez utiliser l’applet de commande Get-IntraOrganizationConfiguration dans vos locataires locaux et Microsoft 365 ou Office 365 pour déterminer les valeurs de point de terminaison nécessaires à l’applet de commande New-IntraOrganizationConnector .

Nous configurons le domaine de routage hybride comme adresse cible. Le domaine de routage hybride est créé automatiquement lors de la création de votre organisation Microsoft 365 ou Office 365. Par exemple, si le premier domaine ajouté et validé dans l’organisation Microsoft 365 ou Office 365 est contoso.com, votre adresse cible est contoso.mail.onmicrosoft.com.

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

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

Dans cette étape, nous configurons un IntraOrganizationConnector qui permet à Exchange Online d’atteindre votre organisation Exchange locale. Ce connecteur permet la disponibilité des fonctionnalités et la connectivité de service entre les organisations. Vous pouvez utiliser l’applet de commande Get-IntraOrganizationConfiguration dans vos locataires locaux et Microsoft 365 ou Office 365 pour déterminer les valeurs de point de terminaison nécessaires à l’applet de commande New-IntraOrganizationConnector .

Vous devez ajouter tous les domaines SMTP utilisés dans votre organisation Exchange locale (à l’exception de votre initial domain et hybrid routing domain) en tant que TargetAddressDomains. Si vous avez plusieurs domaines SMTP, ajoutez-les en tant que liste séparée par des virgules (par exemple, contoso.com,tailspintoys.com ). Vous devez également fournir votre point de terminaison de découverte automatique local en tant que DiscoveryEndpoint.

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

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

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

Avertissement

Exchange Server 2007, Exchange Server 2010 et Exchange Server 2013 ont atteint la fin du support.

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 organisation Exchange locale existante et l’organisation Exchange Online. 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 à votre organisation Exchange locale et les demandes de votre organisation Exchange locale 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 du nombre moyen de demandes EWS et varie selon l’organisation.

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. L’organisation Microsoft 365 ou Office 365 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).

Remarque

Les serveurs de boîtes aux lettres Exchange 2010/2007 peuvent continuer à utiliser des serveurs d'accès au client Exchange 2010/2007 pour les serveurs frontaux pour des connexions de fonctionnalités non hybrides. Seules les demandes de fonctionnalités de déploiement hybride de l’organisation Microsoft 365 ou Office 365 doivent se connecter aux serveurs Exchange 2013.

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

Remarque

Si des informations de répertoire virtuel sont renvoyées par plusieurs serveurs, assurez-vous que vous utilisez le point de terminaison renvoyé pour le serveur d'accès au client Exchange 2013 SP1. Il s’affiche 15.0 (Build 847.32) ou une valeur supérieure pour le AdminDisplayVersion paramètre .

Pour configurer , AvailabilityAddressSpaceutilisez Exchange PowerShell et exécutez l’applet de commande suivante dans votre organisation locale :

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises external Exchange Web Services URL> -ForestName <your hybrid routing domain> -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 organisation Exchange Online peut se connecter correctement à votre organisation Exchange locale, 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

Exemple :

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

Importante

Vous pouvez ignorer l’erreur The SMTP address has no mailbox associated with it. . Il est seulement important que le ResultTask paramètre retourne une valeur de Success. Par exemple, la dernière section de la sortie de test doit se lire comme suit :

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