Topologies pour Azure AD Connect

Cet article décrit diverses topologies locales et Azure Active Directory (Azure AD) qui utilisent Azure AD Connect Sync comme solution d’intégration clé. Cet article inclut les configurations prises en charge et celles qui ne le sont pas.

Voici la légende des images de l’article :

Description Symbole
Forêt Active Directory locale Forêt Active Directory locale
Active Directory local avec importation filtrée Active Directory avec importation filtrée
Serveur Azure AD Connect Sync Serveur Azure AD Connect Sync
« Mode intermédiaire » du serveur Azure AD Connect Sync « Mode intermédiaire » du serveur Azure AD Connect Sync
GALSync avec Forefront Identity Manager (FIM) 2010 ou Microsoft Identity Manager (MIM) 2016 GALSync avec FIM 2010 ou MIM 2016
Serveur Azure AD Connect Sync, détaillé Serveur Azure AD Connect Sync, détaillé
Azure AD Azure Active Directory
Scénario non pris en charge Scénario non pris en charge

Important

Microsoft ne prend pas en charge la modification ou l’utilisation de la synchronisation Azure AD Connect en dehors des configurations ou des actions documentées de façon formelle. Ces configurations ou actions peuvent entraîner un état de synchronisation Azure AD Connect incohérent ou non pris en charge. Par conséquent, Microsoft ne peut pas fournir de support technique pour ces déploiements.

Une seule forêt, un seul client Azure AD

Topologie pour une forêt unique et un locataire unique

La topologie la plus courante est une forêt locale unique, avec un ou plusieurs domaines, et un locataire Azure AD unique. L’authentification Azure AD est effectuée avec la synchronisation du hachage de mot de passe. Il s’agit de la seule topologie prise en charge par l’installation rapide d’Azure AD Connect.

Une seule forêt, plusieurs serveurs de synchronisation connectés à un client Azure AD

Topologie filtrée pour une forêt unique non prise en charge

Le fait de disposer de plusieurs serveurs Azure AD Connect Sync connectés à un même locataire Azure AD n’est pas pris en charge (à l’exception d’un serveur intermédiaire). Ceci n’est pas pris en charge, même si ces serveurs sont configurés pour se synchroniser avec un ensemble d’objets mutuellement exclusifs. Vous avez peut-être considéré cette topologie si vous ne parvenez pas à atteindre l’ensemble des domaines d’une forêt à partir d’un seul serveur ou si vous souhaitez répartir une charge entre plusieurs serveurs. (Aucune erreur ne se produit lorsqu’un nouveau serveur Azure AD Sync est configuré pour une nouvelle forêt Azure AD et un nouveau domaine enfant vérifié.)

Plusieurs forêts, un seul client Azure AD

Topologie pour plusieurs forêts et un locataire unique

De nombreuses organisations possèdent des environnements comportant plusieurs forêts Active Directory locales. Il existe plusieurs raisons de déployer plus d’une forêt Active Directory locale. Par exemple : des modèles avec des forêts de ressources de comptes et la conséquence d’une fusion ou d’une acquisition.

Lorsque vous avez plusieurs forêts, toutes les forêts doivent être accessibles par un même serveur Azure AD Connect Sync. Le serveur doit être joint à un domaine. Si nécessaire pour atteindre toutes les forêts, vous pouvez placer le serveur dans un réseau de périmètre (également appelé DMZ, zone démilitarisée et sous-réseau filtré).

L’Assistant d’installation d’Azure AD Connect offre plusieurs options différentes pour consolider les utilisateurs qui sont représentés dans plusieurs forêts. L’objectif est de représenter un utilisateur une seule fois dans Azure AD. Il existe certaines topologies courantes que vous pouvez configurer dans le chemin d’installation personnalisé de l’Assistant d’installation. Sur la page Identification unique de vos utilisateurs, sélectionnez l’option correspondante qui représente votre topologie. La consolidation est configurée uniquement pour les utilisateurs. Les groupes en doublon ne sont pas consolidés avec la configuration par défaut.

Des topologies courantes sont présentées dans les sections sur les topologies distinctes, le maillage complet et la topologie de ressources de comptes.

La configuration par défaut d’Azure AD Connect Sync suppose que :

  • Chaque utilisateur n’a qu’un seul compte activé et la forêt où se trouve ce compte est utilisée pour authentifier l’utilisateur. Cette hypothèse s’applique à la synchronisation du hachage de mot de passe, l’authentification directe et la fédération. UserPrincipalName et sourceAnchor/immutableID proviennent de cette forêt.
  • Chaque utilisateur n’a qu’une seule boîte aux lettres.
  • la forêt qui héberge la boîte aux lettres d’un utilisateur a la meilleure qualité de données pour les attributs visibles dans la liste d’adresses globale Exchange. Si aucune boîte aux lettres n’est associée à l’utilisateur, n’importe quelle forêt peut être utilisée pour fournir ces valeurs d’attributs.
  • Si vous avez une boîte aux lettres liée, il existe également un compte dans une forêt différente de celle utilisée pour la connexion.

Si votre environnement ne correspond pas à ces hypothèses, voici ce qui se produit :

  • Si vous avez plusieurs comptes actifs ou plusieurs boîtes aux lettres, le moteur de synchronisation en choisit un et ignore les autres.
  • Une boîte aux lettres liée sans aucun autre compte actif n’est pas exportée vers Azure AD. Le compte d’utilisateur n’est pas représenté en tant que membre d’un groupe quelconque. Dans DirSync, une boîte aux lettres liée est toujours représentée comme une boîte aux lettres normale. Il s’agit d’un comportement intentionnellement différent pour mieux prendre en charge les scénarios avec plusieurs forêts.

Pour plus de détails, consultez la page Présentation de la configuration par défaut.

Plusieurs forêts, plusieurs serveurs de synchronisation connectés à un client Azure AD

Topologie non prise en charge pour plusieurs forêts et plusieurs serveurs de synchronisation

Le fait de disposer de plusieurs serveurs Azure AD Connect Sync à un locataire Azure AD unique n’est pas pris en charge. L’exception est l’utilisation d’un serveur intermédiaire.

Cette topologie diffère de celle ci-dessous par le fait qu’elle ne permet pas de connecter plusieurs serveurs de synchronisation à un locataire Azure AD unique. (Bien que non pris en charge, cela fonctionne toujours.)

Plusieurs forêts, un seul serveur de synchronisation et des utilisateurs sont représentés dans un seul annuaire

Option pour ne représenter les utilisateurs qu’une seule fois à travers tous les annuaires

Représentation de plusieurs forêts et de topologies distinctes

Dans cet environnement, toutes les forêts locales sont traitées comme des entités distinctes. Aucun utilisateur n’est présent dans une autre forêt. Chaque forêt a sa propre organisation Exchange et il n’existe pas de GALSync entre les forêts. Cette topologie peut se présenter suite à une fusion/acquisition ou dans une organisation où chaque division fonctionne indépendamment. Dans Azure AD, ces forêts sont dans la même organisation et s’affichent avec une liste d’adresses globale unifiée. Dans l’image précédente, chaque objet de chaque forêt est représenté une seule fois dans le métaverse et agrégé dans le locataire Azure AD cible.

Plusieurs forêts : utilisateurs en correspondance

Dans tous ces scénarios figurent des groupes de distribution et de sécurité, qui peuvent contenir une combinaison d’utilisateurs, de contacts et d’entités de sécurité externes. Les entités de sécurité externes sont utilisées dans Active Directory Domain Services (AD DS) pour représenter des membres d’autres forêts dans un groupe de sécurité. Toutes les entités de sécurité externes sont résolues en leur objet réel dans Azure AD.

Plusieurs forêts : maillage complet avec GALSync facultative

Option d’utilisation de l’attribut de messagerie pour la correspondance lorsqu’il existe des identités utilisateur sur plusieurs annuaires

Topologie de maillage complet pour plusieurs forêts

Une topologie de maillage complet permet aux utilisateurs et aux ressources de se trouver dans n’importe quelle forêt. En général, il existe des approbations bidirectionnelles entre les forêts.

Si Exchange est présent dans plusieurs forêts, il peut (éventuellement) y avoir une solution GALSync locale. Chaque utilisateur est ensuite représenté en tant que contact dans toutes les autres forêts. GALSync est fréquemment implémentée via FIM 2010 ou MIM 2016. Azure AD Connect ne peut pas être utilisé pour une GALSync locale.

Dans ce scénario, les objets d’identité sont joints via l’attribut de messagerie. Un utilisateur qui a une boîte aux lettres dans une forêt est joint aux contacts dans les autres forêts.

Plusieurs forêts : forêt de ressources de comptes

Option d’utilisation des attributs ObjectSID et msExchMasterAccountSID pour la correspondance lorsqu’il existe des identités sur plusieurs annuaires

Topologie de forêt de ressources de comptes pour plusieurs forêts

Dans une topologie de forêt de ressources de comptes, vous avez une ou plusieurs forêts de comptes avec des comptes d’utilisateurs actifs. Une ou plusieurs forêts de ressources comportent également des comptes désactivés.

Dans ce scénario, une (ou plusieurs) forêt de ressources approuve toutes les forêts de comptes. Cette forêt de ressources a généralement un schéma Active Directory étendu avec Exchange et Lync. Tous les services Exchange et Lync, et d’autres services partagés, sont situés dans cette forêt. Les utilisateurs ont un compte d’utilisateur désactivé dans cette forêt et la boîte aux lettres est liée à la forêt de comptes.

Considérations sur Microsoft 365 et la topologie

Certaines charges de travail Microsoft 365 imposent des restrictions aux topologies prises en charge :

Charge de travail Restrictions
Exchange Online Pour plus d’informations sur les topologies hybrides prises en charge par Exchange Online, consultez Déploiements hybrides avec plusieurs forêts Active Directory.
Skype Entreprise Lorsque vous utilisez plusieurs forêts locales, seule la topologie de forêt de ressources de comptes est prise en charge. Pour plus d’informations, consultez la rubrique Configuration environnementale pour Skype for Business Server 2015.

Si vous êtes une plus grande organisation, vous devez envisager d’utiliser la fonctionnalité Microsoft 365 PreferredDataLocation. Elle vous permet de définir la région de centre de données dans laquelle se trouvent les ressources de l’utilisateur.

Serveur de test

Serveur intermédiaire dans une topologie

Azure AD Connect prend en charge l’installation d’un second serveur en mode intermédiaire. Un serveur dans ce mode lit les données de tous les annuaires connectés, sans rien y écrire. Il utilise le cycle de synchronisation normale et possède donc une copie des données d’identité à jour.

En cas d’échec du serveur principal (lors d’un sinistre), vous pouvez basculer sur le serveur intermédiaire. Pour cela, utilisez l’Assistant Azure AD Connect. Ce second serveur peut se trouver dans un autre centre de données, car aucune infrastructure n’est partagée avec le serveur principal. Toute modification de configuration apportée au serveur principal doit être copiée manuellement sur le second serveur.

Vous pouvez utiliser un serveur intermédiaire pour tester une nouvelle configuration personnalisée et l’effet qu’elle aura sur vos données. Vous pouvez prévisualiser les modifications et ajuster la configuration. Lorsque vous êtes satisfait de la nouvelle configuration, vous pouvez faire du serveur intermédiaire le serveur actif et placer l’ancien serveur actif en mode intermédiaire.

Vous pouvez également utiliser cette méthode pour remplacer le serveur de synchronisation actif. Préparez le nouveau serveur et configurez-le en mode intermédiaire. Assurez-vous qu’il est en bon état, désactivez le mode intermédiaire (rendant ainsi le serveur actif), puis arrêtez le serveur actif actuel.

Il est possible d’avoir plusieurs serveurs intermédiaires si vous voulez disposer de plusieurs sauvegardes dans différents centres de données.

Plusieurs clients Azure AD

Nous recommandons d’avoir un seul locataire dans Azure AD pour une organisation. Avant d’envisager d’utiliser plusieurs clients Azure AD, consultez l’article Gestion des unités administratives dans Azure AD. Il couvre les scénarios courants dans lesquels vous pouvez utiliser un locataire unique.

Synchroniser des objets AD avec plusieurs locataires Azure AD

Diagramme montrant une topologie de plusieurs locataires Azure AD.

Cette topologie implémente les cas d’usage suivants :

  • AADConnect peut synchroniser les utilisateurs, groupes et contacts d’une même instance Active Directory avec plusieurs locataires Azure AD. Ces locataires peuvent se trouver dans différents environnements Azure, tels que l’environnement Azure China ou l’environnement Azure Government, mais ils peuvent également se trouver dans le même environnement Azure, par exemple deux locataires dans Azure Commercial. Pour plus d’informations sur les options, consultez https://docs.microsoft.com/azure/azure-government/documentation-government-plan-identity.
  • Le même Source Anchor peut être utilisé pour un seul objet dans des locataires distincts (mais pas pour plusieurs objets dans le même locataire). (Le domaine vérifié ne peut pas être le même dans deux locataires. Plus de détails sont nécessaires pour permettre au même objet d’avoir deux UPN.)
  • Vous devez déployer un serveur AADConnect pour chaque locataire Azure AD avec lequel vous souhaitez synchroniser. Un serveur AADConnect ne peut pas se synchroniser avec plusieurs locataires Azure AD.
  • Différentes étendues de synchronisation et différentes règles de synchronisation sont possibles pour différents locataires.
  • Une seule synchronisation de locataire Azure AD peut être configurée pour réécrire sur Active Directory pour le même objet. Cela comprend la réécriture des appareils et des groupes ainsi que des configurations Exchange hybrides - ces fonctionnalités ne peuvent être configurées que dans un seul locataire. La seule exception ici est la réécriture du mot de passe, voir ci-dessous.
  • Il est possible de configurer la synchronisation du hachage de mot de passe depuis Active Directory avec plusieurs locataires Azure AD pour le même objet utilisateur. Si la synchronisation du hachage de mot de passe est activée pour un locataire, la réécriture du mot de passe peut également être activée, ce qui peut être fait sur plusieurs locataires : si le mot de passe est modifié sur un locataire, la réécriture du mot de passe est mise à jour dans Active Directory, et la synchronisation du hachage de mot de passe met à jour le mot de passe dans les autres locataires.
  • Il n’est pas possible d’ajouter et de vérifier le même nom de domaine personnalisé dans plusieurs locataires Azure AD, même si ces locataires se trouvent dans des environnements Azure différents.
  • La configuration d’expériences hybrides utilisant la configuration au niveau de la forêt dans Active Directory n’est pas prise en charge, par exemple, l’authentification unique fluide et la jonction Azure AD Hybride (approche non ciblée), avec plusieurs locataires. Cela aurait pour effet de remplacer la configuration de l’autre locataire et de la rendre inutilisable. Vous trouverez des informations supplémentaires dans Planifier le déploiement de la jonction hybride d’Azure Active Directory.
  • Vous pouvez synchroniser des objets d’appareil avec plusieurs locataires, mais un appareil peut être la jointure hybride Azure AD à un seul locataire.
  • Chaque instance Azure AD Connect doit être exécutée sur une machine jointe à un domaine.

Notes

La synchronisation de la liste d’adresses globale (GalSync) n’est pas effectuée automatiquement dans cette topologie et nécessite une implémentation MIM personnalisée supplémentaire pour vérifier que chaque locataire dispose d’une liste d’adresses globale (LAG) complète dans Exchange Online et Skype Entreprise Online.

GALSync à l’aide de l’écriture différée

Topologie non prise en charge pour plusieurs forêts et plusieurs annuaires, avec GALSync se concentrant sur Azure ADTopologie non prise en charge pour plusieurs forêts et plusieurs annuaires, avec GALSync se concentrant sur Azure AD

GALSync avec le serveur de synchronisation local

GALSync dans une topologie pour plusieurs forêts et plusieurs annuaires

Vous pouvez utiliser FIM 2010 ou MIM 2016 local pour synchroniser les utilisateurs (via GALSync) entre deux organisations Exchange. Les utilisateurs d’une organisation apparaissent alors comme des utilisateurs/contacts externes dans l’autre organisation. Ces différentes instances Active Directory locales peuvent ensuite être synchronisées vers leurs propres locataires Azure AD.

Utilisation de clients non autorisés pour accéder au serveur principal d’Azure AD Connect

Utilisation de clients non autorisés pour accéder au serveur principal d’Azure AD Connect

Le serveur Azure Active Directory Connect communique avec Azure Active Directory via le serveur principal d’Azure Active Directory Connect. Azure Active Directory Connect est le seul logiciel qui peut être utilisé pour communiquer avec ce serveur principal. Il n’est pas possible de communiquer avec le serveur principal d’Azure Active Directory Connect en utilisant un autre logiciel ou une autre méthode.

Étapes suivantes

Pour savoir comment installer Azure AD Connect pour ces scénarios, consultez Installation personnalisée d’Azure AD Connect.

En savoir plus sur la configuration de la synchronisation Azure AD Connect .

En savoir plus sur l’intégration de vos identités locales avec Azure Active Directory.