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 les organisations Exchange 2013 et Exchange Online. Si votre organisation 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 Exchange OAuth après l’exécution de l’Assistant Configuration hybride.

Important

  • Si votre organisation sur site utilise uniquement des serveurs Exchange 2013 avec la mise à jour cumulative 5 ou version ultérieure installée, exécutez l'assistant de déploiement hybride au lieu de suivre 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, consultez Office 365 géré par 21Vianet.

Ce qu'il faut savoir avant de commencer

Conseil

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

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

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

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é <your verified domain> dans la procédure suivante.

Exécutez la commande suivante dans Exchange Management Shell (Exchange PowerShell) dans votre organisation Exchange locale :

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"

Notes

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

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"

Notes

Le domaine de coexistence du locataire est sous la forme contoso.mail.onmicrosoft.com

É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 sur le serveur Exchange directement 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.

    $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 Azure Active Directory Access Control Service (ACS)

Ensuite, utilisez le module Azure Active Directory pour Windows PowerShell pour charger le certificat d’autorisation local que vous avez exporté à l’étape précédente vers Azure Active Directory 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 MSOnline

Effectuez les étapes suivantes une fois que la cmdlet Module Azure Active Directory pour Windows PowerShell est installée.

  1. Cliquez sur le raccourci Module Windows Azure Active Directory pour Windows PowerShell afin d'ouvrir un espace de travail Windows PowerShell pour lequel les cmdlets Azure AD sont installées. Dans cette étape, toutes les commandes seront exécutées à l'aide de la console Windows PowerShell pour Azure Active Directory.

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

    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. 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 de votre organisation Microsoft Online Azure AD. Après avoir exécuté le script, laissez la session Windows PowerShell pour Azure AD 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 internes et externes auprès d’Azure Active Directory

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, https://mail.contoso.com/ews/exchange.asmxutilisez le nom https://mail.contoso.comdu principal du 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 | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

Notes

Le script suivant exige que le Windows PowerShell pour Azure Active Directory 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. Cet exemple utilise un contoso.com. Remplacez https://mail.contoso.com/ et https://autodiscover.contoso.com/ utilisez l’autorité de nom d’hôte appropriée pour votre organisation Exchange locale.

    $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. Dans Windows PowerShell pour Azure Active Directory, 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 pour Azure Active Directory et recherchez https://namespace les entrées dans les résultats.

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

Étape 6 : Créer un IntraOrganizationConnector à partir de votre organisation locale 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 lorsque votre organisation Microsoft 365 ou Office 365 est créée. Par exemple, si le domaine de votre organisation hébergé dans Microsoft 365 ou Office 365 organisation 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 organisation Microsoft 365 ou Office 365 vers votre organisation Exchange locale

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 organisation 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>

Notes

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.

Après vous être connecté à Exchange Online PowerShell, remplacez <your on-premises Autodiscover endpoint> vos valeurs et <your on-premises SMTP domain> 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 d’anciennes organisations Exchange, 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 Accès client et 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 avons recommandé que tous les serveurs frontaux accessibles sur Internet soient des serveurs d’accès 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 client Exchange 2013. Cette exigence inclut les demandes de Microsoft 365 à votre organisation Exchange locale et les demandes de votre organisation Exchange locale à Microsoft 365. Il est important que vous ayez suffisamment de serveurs d’accès client Exchange 2013 pour gérer la charge de traitement et fournir une redondance de connexion. Le nombre de serveurs d’accès client dont vous avez besoin dépend de la quantité moyenne de demandes EWS et varie selon l’organisation.

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

  • Les serveurs hybrides frontaux 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 cloud de 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).

Notes

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 espace AvailabilityAddressSpace doit être configuré sur des serveurs d’accès client avant Exchange 2013 qui pointe vers le point de terminaison des services web Exchange de vos serveurs d’accès 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

Notes

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 affiche la version 15.0 (build 847.32) ou une version ultérieure pour le paramètre AdminDisplayVersion .

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 cmdlet vérifie que les points de terminaison Exchange et Exchange Online locaux peuvent authentifier correctement les demandes l'un de l'autre.

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 à 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

Par exemple,

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

Important

Vous pouvez ignorer « Aucune boîte aux lettres n’est associée à l’adresse SMTP ». Erreur. Il est uniquement important que le paramètre ResultTask retourne la valeur Success. Par exemple, la dernière section de la sortie de test doit lire :

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

Conseil

Vous rencontrez des problèmes ? Demandez de l’aide sur les forums Exchange. Accédez aux forums en cliquant sur le lien suivant : Exchange Server.