Partager via

Fédération

  • Article

S’applique à : Exchange Server 2013

Les professionnels de l'information ont souvent besoin de collaborer avec des destinataires, fournisseurs, partenaires et clients externes et de partager leurs informations de disponibilité (également appelées disponibilités de calendrier). La fédération dans Microsoft Exchange Server 2013 facilite ces efforts de collaboration. Le terme fédération désigne l’infrastructure d’approbation sous-jacente qui prend en charge le partage fédéré, un moyen facile pour les utilisateurs de partager des informations de calendrier avec les destinataires d’autres organisations fédérées externes. Pour en savoir plus sur le partage fédéré, voir Partage.

Importante

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 exploité par 21Vianet.

Terminologie clé

La liste suivante définit les principaux composants associés à la fédération dans Exchange 2013.

  • identificateur d’application (AppID) : numéro unique généré par le système d’authentification Microsoft Entra pour identifier les organisations Exchange. L’AppID est généré automatiquement lorsque vous créez une approbation de fédération avec le système d’authentification Microsoft Entra.

  • jeton de délégation : jeton SAML (Security Assertion Markup Language) émis par le système d’authentification Microsoft Entra qui permet aux utilisateurs d’une organization fédérée d’être approuvés par un autre organization fédéré. Un jeton de délégation contient l'adresse de messagerie de l'utilisateur, un identificateur immuable et des informations associées à l'offre pour laquelle le jeton est émis.

  • external federated organization : organization Exchange externe qui a établi une approbation de fédération avec le système d’authentification Microsoft Entra.

  • partage fédéré : groupe de fonctionnalités Exchange qui tirent parti d’une approbation de fédération avec le système d’authentification Microsoft Entra pour fonctionner dans les organisations Exchange, y compris les déploiements Exchange intersite. Ensemble, ces fonctionnalités sont utilisées pour créer des demandes authentifiées entre les serveurs pour le compte d'utilisateurs de multiples organisations Exchange.

  • domaine fédéré : domaine faisant autorité accepté qui est ajouté à l’identificateur de organization (OrgID) pour un organization Exchange.

  • chaîne de chiffrement de preuve de domaine : chaîne sécurisée par chiffrement utilisée par un organization Exchange pour fournir la preuve que le organization possède le domaine utilisé avec le système d’authentification Microsoft Entra. La chaîne est automatiquement générée lorsque vous utilisez l'Assistant Activer l'approbation de fédération ou peut être générée à l'aide de la cmdlet Get-FederatedDomainProof.

  • stratégie de partage fédéré : stratégie de niveau organization qui permet et contrôle le partage de personne à personne établi par l’utilisateur des informations de calendrier.

  • federation : un accord basé sur l’approbation entre deux organisations Exchange pour atteindre un objectif commun. Dans la fédération, les deux organisations veulent que les assertions d'authentification d'une organisation soient reconnues par l'autre.

  • approbation de fédération : relation avec le système d’authentification Microsoft Entra qui définit les composants suivants pour votre organization Exchange :

    • Espace de noms de compte

    • Identificateur d'application (AppID)

    • Identificateur d'organisation (OrgID)

    • Domaines fédérés

    Pour configurer le partage fédéré avec d’autres organisations Exchange fédérées, une approbation de fédération doit être établie avec le système d’authentification Microsoft Entra.

  • organization non fédérés : organisations qui n’ont pas d’approbation de fédération établie avec le système d’authentification Microsoft Entra.

  • identificateur organization (OrgID) : définit les domaines acceptés faisant autorité configurés dans un organization sont activés pour la fédération. Seuls les destinataires qui ont des adresses de messagerie avec des domaines fédérés configurés dans OrgID sont reconnus par le système d’authentification Microsoft Entra et peuvent utiliser des fonctionnalités de partage fédéré. L'OrgID est constitué d'une chaîne prédéfinie et du premier domaine accepté qui est sélectionné pour la fédération dans l'Assistant Activer l'approbation de fédération. Par exemple, si vous spécifiez le domaine fédéré contoso.com comme domaine SMTP principal de votre organisation, l'espace de noms de compte FYDIBOHF25SPDLT.contoso.com sera créé automatiquement comme OrgID pour l'approbation de fédération.

  • organization relation : relation un-à-un entre deux organisations Exchange fédérées qui permet aux destinataires de partager des informations de disponibilité (disponibilité du calendrier). Une relation organization nécessite une approbation de fédération avec le système d’authentification Microsoft Entra et remplace la nécessité d’utiliser des approbations de forêt ou de domaine Active Directory entre les organisations Exchange.

  • Microsoft Entra système d’authentification : un service d’identité gratuit basé sur le cloud qui joue le rôle de répartiteur d’approbation entre les organisations Microsoft Exchange fédérées. Il est responsable de l'envoi de jetons de délégation aux destinataires Exchange qui demandent des informations aux destinataires d'autres organisations Exchange fédérées. Pour plus d’informations, consultez ID Microsoft Entra.

système d’authentification Microsoft Entra

Le système d’authentification Microsoft Entra, un service cloud gratuit proposé par Microsoft, fait office de répartiteur d’approbation entre votre organization Exchange 2013 local et d’autres organisations Exchange 2010 et Exchange 2013 fédérées. Si vous souhaitez configurer la fédération dans votre organization Exchange, vous devez établir une approbation de fédération à usage unique avec le système d’authentification Microsoft Entra, afin qu’il puisse devenir un partenaire de fédération avec votre organization. Une fois cette approbation en place, les utilisateurs authentifiés par Active Directory (appelés fournisseurs d’identité) reçoivent des jetons de délégation SAML (Security Assertion Markup Language) par le système d’authentification Microsoft Entra. Ces jetons permettent aux utilisateurs d'une organisation Exchange fédérée d'être approuvés par une autre organisation Exchange fédérée. Avec le système d’authentification Microsoft Entra agissant en tant que répartiteur d’approbation, les organisations ne sont pas tenues d’établir plusieurs relations d’approbation individuelles avec d’autres organisations, et les utilisateurs peuvent accéder à des ressources externes à l’aide d’une expérience d’authentification unique (SSO). Pour plus d’informations, consultez ID Microsoft Entra.

Approbation de fédération

Pour utiliser les fonctionnalités de partage fédéré Exchange 2013, vous devez établir une approbation de fédération entre votre organization Exchange 2013 et le système d’authentification Microsoft Entra. L’établissement d’une approbation de fédération avec le système d’authentification Microsoft Entra échange le certificat de sécurité numérique de votre organization avec le système d’authentification Microsoft Entra et récupère le certificat système d’authentification Microsoft Entra et les métadonnées de fédération. Vous pouvez établir une approbation de fédération à l’aide de l’Assistant Activer l’approbation de fédération dans le Centre d’administration Exchange (EAC) ou de l’applet de commande New-FederationTrust dans l’environnement de ligne de commande Exchange Management Shell. Un certificat auto-signé est automatiquement créé par l’Assistant Activer l’approbation de fédération et est utilisé pour signer et chiffrer des jetons de délégation à partir du système d’authentification Microsoft Entra qui permettent aux utilisateurs d’être approuvés par des organisations fédérées externes. Pour plus d’informations sur la configuration requise des certificats, voir Certificate Requirements for Federation plus loin dans cette rubrique.

Lorsque vous créez une approbation de fédération avec le système d’authentification Microsoft Entra, un identificateur d’application (AppID) est automatiquement généré pour votre organization Exchange et fourni dans la sortie de l’applet de commande Get-FederationTrust. L’AppID est utilisé par le système d’authentification Microsoft Entra pour identifier de manière unique votre organization Exchange. Il est également utilisé par le organization Exchange pour fournir la preuve que votre organization possède le domaine à utiliser avec le système d’authentification Microsoft Entra. Cette opération est effectuée en créant un enregistrement de texte (TXT) dans la zone DNS (Domain Name System) publique pour chaque domaine fédéré.

Identificateur d’organisation fédérée

L’identificateur d’organisation fédérée détermine, parmi les domaines acceptés faisant autorité configurés dans votre organisation, quels sont ceux qui sont activés pour la fédération. Seuls les destinataires qui ont des adresses de messagerie avec des domaines acceptés configurés dans l’Id d’organisation sont reconnus par le système d’authentification Microsoft Entra et peuvent utiliser des fonctionnalités de partage fédéré. Lorsque vous créez une approbation de fédération, un OrgID est automatiquement créé avec le système d’authentification Microsoft Entra. Cet OrgID est constitué d'une chaîne prédéfinie et du domaine accepté qui est sélectionné comme domaine partagé principal dans l'Assistant. Par exemple, dans l'Assistant Modifier les domaines activés pour le partage, si vous spécifiez le domaine fédéré contoso.com comme domaine partagé principal de votre organisation, l'espace de noms de compte FYDIBOHF25SPDLT.contoso.com sera créé automatiquement comme OrgID pour l'approbation de fédération de votre organisation Exchange.

Bien qu'il s'agisse généralement du domaine SMTP principal de l'organisation Exchange, ce domaine n'est pas obligatoirement un domaine accepté dans votre organisation Exchange et ne requiert pas d'enregistrement TXT de preuve d'appartenance du DNS. La seule exigence est la limitation des domaines acceptés qui sont sélectionnés pour être fédérés à un nombre maximal de 32 caractères. Le seul objectif de ce sous-domaine est de servir d’espace de noms fédéré pour le système d’authentification Microsoft Entra afin de conserver des identificateurs uniques pour les destinataires qui demandent des jetons de délégation SAML. Pour de plus amples informations sur les jetons SAML, consultez la rubrique Jetons SAML et revendications

Vous pouvez à tout moment ajouter des domaines acceptés à l'approbation de fédération ou en supprimer. Si vous souhaitez activer ou désactiver toutes les fonctionnalités de partage de fédération dans votre organisation, il vous suffit d'activer ou de désactiver l'OrgID pour l'approbation de fédération.

Importante

Si vous modifiez l'OrgID, les domaines acceptés ou l'identificateur d'application pour l'approbation de fédération, toutes les fonctionnalités de partage de fédération sont affectées dans votre organisation. Toute organisation Exchange fédérée externe, notamment Exchange Online et les configurations de déploiement hybride, est également affectée. Nous vous recommandons d'informer tous vos partenaires fédérés externes si vous modifiez ces paramètres de configuration de l'approbation de fédération.

Exemple de fédération

Deux organisations Exchange, Contoso, Ltd. et Fabrikam, Inc., souhaitent que leurs utilisateurs puissent partager les informations de disponibilité du calendrier entre eux. Chaque organization crée une approbation de fédération avec le système d’authentification Microsoft Entra et configure son espace de noms de compte pour inclure le domaine utilisé pour le domaine d’adresse de messagerie de son utilisateur.

Les employés de Contoso utilisent l'un des domaines d'adresse de messagerie suivants : contoso.com, contoso.co.uk ou contoso.ca. Les employés de Fabrikam utilisent l'un des domaines d'adresse de messagerie suivants : fabrikam.com, fabrikam.org ou fabrikam.net. Les deux organisations s’assurent que tous les domaines de messagerie acceptés sont inclus dans l’espace de noms de compte pour leur approbation de fédération avec le système d’authentification Microsoft Entra. Au lieu d'exiger une configuration d'approbation de forêt ou de domaine Active Directory complexe entre elles, les deux organisations configurent une relation organisationnelle afin de permettre le partage des disponibilités de calendrier.

La figure suivante illustre la configuration de la fédération entre Contoso, Ltd. et Fabrikam, Inc.

Exemple de partage fédéré

Approbations de fédération et partage fédéré.

Configuration requise pour les certificats en vue de la fédération

Pour établir une approbation de fédération avec le système d’authentification Microsoft Entra, un certificat auto-signé ou un certificat X.509 signé par une autorité de certification doit être créé et installé sur le serveur Exchange 2013 utilisé pour créer l’approbation. Il est vivement conseillé d'utiliser un certificat auto-signé, que vous pouvez créer et installer automatiquement à l'aide de l'Assistant Activer l'approbation de fédération dans le Centre d'administration Exchange. Ce certificat sert uniquement à signer et chiffrer les jetons de délégation utilisés pour le partage fédéré ; un seul certificat est nécessaire pour l'approbation de fédération. Exchange 2013 distribue automatiquement le certificat à tous les autres serveurs Exchange 2013 de l'organisation.

Si vous souhaitez utiliser un certificat X.509 signé par une Autorité de certification externe, il doit réunir les conditions suivantes :

  • Autorité de certification approuvée : si possible, le certificat SSL (Secure Sockets Layer) X.509 doit être émis à partir d’une autorité de certification approuvée par Windows Live. Cependant, vous pouvez utiliser les certificats utilisés par des autorités de certification qui ne sont pas actuellement certifiées par Microsoft. Pour obtenir une liste actualisée des autorités de certification approuvées, voir Autorités de certification racine de confiance pour les approbations de fédération.

  • Identificateur de clé d’objet : le certificat doit avoir un champ identificateur de clé d’objet. La plupart des certificats X.509 émis par des autorités de certification commerciales comportent cet identificateur.

  • Fournisseur de services de chiffrement (CSP) CryptoAPI : le certificat doit utiliser un fournisseur de services de chiffrement CryptoAPI. Certificats utilisant un API de cryptographie : les fournisseurs CNG (Cryptography Next Generation) ne sont pas pris en charge pour la fédération. Si vous vous servez d'Exchange pour créer une demande de certificat, un fournisseur CryptoAPI est utilisé. Pour de plus amples informations, consultez la page API Cryptography : Next Generation.

  • Algorithme de signature RSA : le certificat doit utiliser RSA comme algorithme de signature.

  • Clé privée exportable : la clé privée utilisée pour générer le certificat doit être exportable. Vous pouvez demander à ce que la clé privée soit exportable lors de la création de la demande de certificat à l'aide de l'Assistant Nouveau certificat Exchange dans le Centre d'administration Exchange ou de la cmdlet New-ExchangeCertificate dans l'environnement Exchange Management Shell.

  • Certificat actuel : le certificat doit être à jour. Vous ne pouvez pas utiliser de certificat expiré ou révoqué pour créer une approbation de fédération.

  • Utilisation améliorée des clés : le certificat doit inclure le type d’utilisation améliorée de la clé (EKU) Authentification client (1.3.6.1.5.5.7.3.2) . Ce type d'utilisation permet de prouver votre identité sur un ordinateur distant. Si vous utilisez le Centre d'administration Exchange ou l'environnement Exchange Management Shell pour générer une demande de certificat, ce type d'utilisation est inclus par défaut.

Remarque

Étant donné que le certificat n'est pas utilisé pour l'authentification, il n'y a aucune exigence en matière de nom d'objet ou d'autre nom d'objet. Vous pouvez utiliser un certificat dont le nom d'objet est identique au nom d'hôte, au nom de domaine ou à tout autre nom.

Transition vers un nouveau certificat

Le certificat utilisé pour créer l’approbation de fédération est désigné comme certificat actuel. Cependant, vous devrez peut-être installer et utiliser régulièrement un nouveau certificat pour l'approbation de fédération. Par exemple, vous devrez éventuellement utiliser un nouveau certificat si le certificat actuel expire ou pour répondre à un nouveau besoin de l'entreprise ou à un impératif de sécurité. Pour assurer une transition transparente vers un nouveau certificat, vous devez installer le nouveau certificat sur votre serveur Exchange 2013 et configurer l'approbation de fédération pour le désigner comme nouveau certificat. Exchange 2013 distribue automatiquement le nouveau certificat à tous les autres serveurs Exchange 2013 de l'organisation. Selon votre topologie Active Directory, la distribution du certificat peut prendre un certain temps. Vous pouvez vérifier l'état du certificat à l'aide de la cmdlet Test-FederationTrustCertificate dans l'environnement Exchange Management Shell.

Une fois l'état de distribution du certificat vérifié, vous pouvez configurer l'approbation afin qu'elle utilise le nouveau certificat. Après avoir changé de certificat, le certificat actuel est désigné comme certificat précédent, et le nouveau certificat comme certificat actuel. Le nouveau certificat est publié sur le système d’authentification Microsoft Entra, et tous les nouveaux jetons échangés avec le système d’authentification Microsoft Entra sont chiffrés à l’aide du nouveau certificat.

Remarque

Ce processus de transition de certificat est uniquement utilisé par la fédération. Si vous utilisez le même certificat pour d'autres fonctions d'Exchange 2013 exigeant des certificats, vous devez prendre en compte les fonctionnalités requises lorsque vous envisagez d'obtenir, d'installer ou d'adopter un nouveau certificat.

Considérations relatives au pare-feu pour la fédération

Les fonctionnalités de fédération exigent que les serveurs d'accès au client et de boîtes aux lettres de votre organisation aient un accès sortant à Internet via HTTPS. Vous devez autoriser un accès HTTPS sortant (port 443 pour TCP) à tous les serveurs d'accès au client et de boîtes aux lettres Exchange 2013 de l'organisation.

Pour qu'une organisation externe ait accès aux informations de disponibilité de votre organisation, vous devez publier un serveur d'accès au client sur Internet. Un accès HTTPS entrant depuis Internet vers le serveur d'accès au client est nécessaire. Les serveurs d'accès au client dans les sites Active Directory n'ayant pas de serveur d'accès au client publié sur Internet peuvent utiliser les serveurs d'accès au client dans d'autres sites Active Directory accessibles depuis Internet. Les serveurs d'accès au client qui ne sont pas publiés sur Internet doivent avoir l'URL externe du répertoire virtuel des services web définie avec l'URL accessible aux organisations externes.