Planifier, concevoir et implémenter des Azure Active Directory Connect (AADC)

Effectué

Azure AD Connect est une solution qui fait un pont entre une Active Directory locale et votre Azure Active Directory basée sur le Cloud. Cela permet au service informatique de synchroniser les identités locales dans Azure et garantit une identité cohérente sur les deux plateformes. Cette connexion active des services tels que la synchronisation de hachage de mot de passe, l’authentification directe et l’authentification unique transparente.

L’outil Microsoft Azure AD Connect a été conçu pour vous permettre d’atteindre et de remplir vos objectifs en matière d’identité hybride. Il offre les fonctionnalités suivantes :

  • Synchronisation : ce composant est chargé de créer des utilisateurs, des groupes et d’autres objets, et également de s’assurer que les informations d’identité relatives aux utilisateurs et aux groupes dans votre environnement local correspondent à celles qui se trouvent dans le cloud. Cette synchronisation inclut également des hachages de mot de passe.

  • Synchronisation de hachage de mot de passe : méthode d’authentification qui synchronise un hachage du mot de passe AD local d’un utilisateur avec Azure AD.

  • Authentification directe : méthode d’authentification qui permet aux utilisateurs d’utiliser le même mot de passe localement et dans le cloud, mais sans nécessiter l’infrastructure supplémentaire d’un environnement fédéré.

  • Intégration de fédération : la fédération est une partie facultative d’Azure AD Connect qui peut servir à configurer un environnement hybride à l’aide d’une infrastructure AD FS locale. Elle offre également des fonctionnalités de gestion AD FS telles que le renouvellement de certificat et les déploiements de serveurs AD FS supplémentaires.

  • Surveillance de l’intégrité-Azure AD Connect Health fournit une surveillance robuste.

    Qu’est-ce qu’Azure AD Connect ?

Pourquoi utiliser Azure AD Connect ?

L’intégration de vos annuaires locaux avec Azure AD améliore la productivité de vos utilisateurs en leur fournissant une identité commune pour accéder aux ressources cloud et locales. Avec Azure AD Connect, les utilisateurs peuvent se servir de la même identité pour accéder à la fois aux applications locales et aux services cloud, comme Microsoft 365. En outre, les organisations peuvent fournir une expérience de déploiement simple pour la synchronisation et la connexion à l’aide d’un seul outil. Azure AD Connect remplace les versions antérieures des outils d’intégration d’identité tels que DirSync et Azure AD Sync et est inclus dans votre abonnement Azure AD.

Sélectionnez une méthode d'authentification

L’identité constitue le nouveau plan de contrôle en matière de sécurité informatique et, dès lors, l’authentification permet aux organisations de gérer les accès au cloud. Les organisations ont besoin d’un plan de contrôle d’identité qui renforce leur sécurité et protège leurs applications cloud contre les intrus. En choisissant la solution d’identité hybride Azure AD comme nouveau plan de contrôle, l’authentification constitue la base de l’accès au cloud. Le choix de la méthode d’authentification est une première décision essentielle dans la configuration d’une solution d’identité hybride Azure AD. Pour choisir une méthode d’authentification, vous devez prendre en compte l’infrastructure existante, le temps nécessaire à l’implémentation, sa complexité et les coûts associés. Ces facteurs sont différents pour chaque organisation et peuvent varier au fil du temps.

Authentification cloud

Quand vous choisissez cette méthode d’authentification, Azure AD gère le processus de connexion des utilisateurs. Si vous l’associez à une authentification unique (SSO) fluide, les utilisateurs peuvent se connecter aux applications cloud sans avoir à retaper leurs informations d’identification. L’authentification cloud propose deux options :

Synchronisation de hachage du mot de passe Azure AD. Il s’agit du moyen le plus simple d’activer l’authentification pour les objets d’annuaire locaux dans Azure AD. Elle permet aux utilisateurs d’utiliser les mêmes nom d’utilisateur et mot de passe qu’ils utilisent localement sans avoir à déployer une infrastructure supplémentaire.

  • Effort. La synchronisation de hachage du mot de passe nécessite le moins d’effort en matière de déploiement, de maintenance et d’infrastructure. Ce niveau d’effort s’applique généralement aux organisations dont les utilisateurs se connectent uniquement à Microsoft 365, à des applications SaaS et à d’autres ressources Azure AD basées sur Active Directory. Une fois activée, la synchronisation de hachage du mot de passe fait partie du processus de synchronisation Azure AD Connect et s’exécute toutes les deux minutes.

  • Expérience utilisateur. Pour améliorer l’expérience de connexion des utilisateurs, déployez l’authentification unique transparente avec synchronisation de hachage du mot de passe. L’authentification unique transparente élimine les invites inutiles quand les utilisateurs sont connectés.

  • Scénarios avancés. Les organisations peuvent choisir d’utiliser les insights des identités avec les rapports Azure AD Identity Protection avec Azure AD Premium P2, par exemple le rapport sur les informations d’identification divulguées. Windows Hello Entreprise a des exigences spécifiques quand vous utilisez la synchronisation de hachage du mot de passe. Azure Active Directory Domain Services nécessite la synchronisation de hachage de mot de passe pour fournir aux utilisateurs leurs informations d’identification dans le domaine managé.

  • Continuité des activités. La synchronisation de hachage du mot de passe avec authentification cloud est un service cloud hautement disponible qui s’adapte à tous les centres de données Microsoft. Pour vous assurer que la synchronisation de hachage du mot de passe ne baisse pas pendant de longues périodes, déployez un second serveur Azure AD Connect en mode préproduction dans une configuration de secours.

  • Considérations. À l’heure actuelle, la synchronisation de hachage du mot de passe n’applique pas immédiatement les changements aux états des comptes locaux. Cela signifie qu’un utilisateur a accès aux applications cloud jusqu’à ce que l’état du compte utilisateur soit synchronisé avec Azure AD. Pour contourner cette limitation, les organisations peuvent exécuter un nouveau cycle de synchronisation après les mises à jour en bloc effectuées par les administrateurs sur les états des comptes locaux, par exemple la désactivation de comptes.

Authentification directe Azure AD. Fournit une validation de mot de passe simple pour les services d’authentification Azure AD à l’aide d’un agent logiciel qui s’exécute sur un ou plusieurs serveurs locaux. Les serveurs valident les utilisateurs directement avec votre Active Directory local, ce qui garantit que la validation du mot de passe ne se produit pas dans le cloud. Cette méthode d’authentification convient pour les entreprises qui, pour des raisons de sécurité, requièrent l’application immédiate d’heures d’ouverture de session, de stratégies de mot de passe et d’états des comptes d’utilisateur locaux.

  • Effort. L’authentification directe nécessite l’installation d’un ou plusieurs agents légers (trois sont recommandés) sur des serveurs existants. Ces agents doivent avoir accès à vos services AD DS (Active Directory Domain Services) locaux et à vos contrôleurs de domaine AD locaux. Ils doivent disposer d’un accès sortant à Internet et à vos contrôleurs de domaine. Le déploiement des agents dans un réseau de périmètre n’est donc pas pris en charge.

  • Expérience utilisateur. Pour améliorer l’expérience de connexion des utilisateurs, déployez l’authentification unique transparente avec l’authentification directe. L’authentification unique transparente élimine les invites inutiles quand les utilisateurs sont connectés.

  • Scénarios avancés. L’authentification directe applique la stratégie de compte local au moment de la connexion. Par exemple, l’accès est refusé lorsque l’état d’un compte d’utilisateur local indique que le compte est désactivé, verrouillé, que le mot de passe a expiré ou que les heures de connexion associées au compte ne correspondent pas aux heures d’ouverture de session autorisées de l’utilisateur.

  • Continuité des activités. Nous vous recommandons de déployer deux agents d’authentification directe supplémentaires. Ces agents complètent le premier agent sur le serveur Azure AD Connect. Ce déploiement supplémentaire garantit la haute disponibilité des demandes d’authentification. Quand trois agents sont déployés et que l’un d’eux est hors service pour maintenance, l’échec d’un agent n’a aucune incidence.

  • Considérations. Vous pouvez utiliser la synchronisation de hachage de mot de passe comme une méthode d’authentification de secours pour l’authentification directe, et les agents ne peuvent pas valider les informations d’identification d’un utilisateur en raison d’un incident local. Le basculement vers la synchronisation de hachage du mot de passe ne se produit pas automatiquement et vous devez utiliser Azure AD Connect pour basculer manuellement la méthode de connexion.

Authentification fédérée

Quand vous choisissez cette méthode d’authentification, Azure AD délègue le processus d’authentification à un système d’authentification approuvée distinct, par exemple les services de fédération Active Directory (AD FS), pour valider le mot de passe de l’utilisateur. Le système d’authentification peut fournir des conditions d’authentification supplémentaires, comme l’authentification par carte à puce ou une authentification multifacteur tierce.

  • Effort. L’utilisation d’un système d’authentification fédérée s’appuie sur un système externe de confiance pour authentifier les utilisateurs. Certaines entreprises souhaitent rentabiliser leur investissement et réutiliser leur système fédéré existant avec leur solution d’identité hybride Azure AD. La maintenance et la gestion du système fédéré ne relèvent pas d’Azure AD. Il appartient à l’organisation d’utiliser le système fédéré pour vérifier qu’il est déployé de manière sécurisée et qu’il peut gérer la charge de l’authentification.

  • Expérience utilisateur. L’expérience utilisateur de l’authentification fédérée dépend de l’implémentation de fonctionnalités, de la topologie et de la configuration de la batterie de serveurs de fédération. Certaines organisations ont besoin de cette souplesse pour configurer l’accès à la batterie de serveurs de fédération en fonction de leurs exigences en matière de sécurité. Par exemple, il est possible de configurer en interne des utilisateurs connectés et des appareils capables de connecter automatiquement les utilisateurs. Aucune information d’identification n’est donc demandée aux utilisateurs. Cette configuration fonctionne, car ils sont déjà connectés à leurs appareils. Si nécessaire, certaines fonctionnalités de sécurité avancées compliquent le processus de connexion des utilisateurs.

  • Scénarios avancés. Une solution d’authentification fédérée est requise lorsque les clients ont une exigence d’authentification non prise en charge par Azure AD en mode natif.

    • Authentification nécessitant des cartes à puce ou des certificats.

    • Les serveurs MFA locaux ou fournisseurs d’authentification multifacteur tiers nécessitent un fournisseur d’identité fédéré.

    • Authentification à l’aide de solutions d’authentification tierces.

    • Connexion nécessitant un sAMAccountName, par exemple DOMAINE\nomutilisateur, et non avec un nom d’utilisateur principal (UPN) comme user@domain.com.

  • Continuité des activités. Les systèmes fédérés nécessitent généralement un groupe de serveurs à charge équilibrée, également appelé « batterie de serveurs ». Cette batterie est configurée dans une topologie de réseau interne et de réseau de périmètre pour garantir la haute disponibilité des demandes d’authentification.

  • Considérations. Les systèmes fédérés nécessitent généralement un investissement plus important dans l’infrastructure locale. La plupart des organisations choisissent cette option si elles disposent déjà d’une solution de fédération locale et qu’elles sont contraintes d’utiliser un fournisseur d’identité unique pour des raisons commerciales. La fédération est plus difficile à utiliser et à dépanner que les solutions d’authentification cloud.

Diagrammes d’architecture

Les diagrammes suivants présentent les composants architecturaux de haut niveau nécessaires pour chaque méthode d’authentification que vous pouvez utiliser avec votre solution d’identité hybride Azure AD. Ils vous offrent une vue d’ensemble pour vous aider à comparer les différences entre les solutions.

  • Simplicité d’une solution de synchronisation de hachage du mot de passe :

    Identité hybride Azure AD avec synchronisation de hachage de mot de passe

  • Configuration requise de l’agent d’authentification directe, à l’aide de deux agents pour la redondance :

    Identité hybride Azure AD avec authentification directe

  • Composants obligatoires pour la fédération dans le réseau interne et le réseau de périmètre de votre organisation :

    Identité hybride Azure AD avec authentification fédérée

Recommandations

Votre système d’identité garantit à vos utilisateurs l’accès aux applications cloud et aux applications métier que vous migrez et rendez accessibles dans le cloud. Pour assurer la productivité des utilisateurs autorisés et protéger les données sensibles de votre organisation contre les intrus, k’authentification contrôle l’accès aux applications.

Utilisez ou activez la synchronisation de hachage du mot de passe, quelle que soit la méthode d’authentification choisie, et ce pour les raisons suivantes :

  1. Haute disponibilité et récupération d’urgence. L’authentification directe et la fédération s’appuient sur une infrastructure locale. Pour l’authentification directe, l’empreinte locale inclut le matériel de serveur et la mise en réseau requis par les agents d’authentification directe. Pour la fédération, l’empreinte locale est encore plus importante. Elle nécessite des serveurs dans votre réseau de périmètre pour rediriger par l’intermédiaire d’un proxy les demandes d’authentification et les serveurs de fédération interne.

    Pour éviter des points de défaillance uniques, déployez des serveurs redondants. Cette méthode garantit le traitement des requêtes d’authentification en cas d’échec d’un composant. Du point de vue de l’authentification directe comme de la fédération, il est aussi attendu que les contrôleurs de domaine répondent aux demandes d’authentification, qui peuvent également échouer. L’intégrité de nombreux composants passe par des opérations de maintenance. Si celles-ci ne sont pas planifiées et implémentées correctement, le risque de panne est plus élevé. La synchronisation de hachage du mot de passe permet d’éviter les pannes, car le service d’authentification cloud Azure AD de Microsoft est mis à l’échelle globalement et toujours disponible.

  2. Survie à une panne locale. Les conséquences d’une panne locale à la suite d’une cyberattaque ou d’un sinistre peuvent être considérables, de l’atteinte à l’image de marque à la paralysie de l’organisation si celle-ci ne parvient pas à gérer l’attaque. Récemment, de nombreuses organisations ont été victimes d’attaques menées par des programmes malveillants, notamment des ransomwares (rançongiciels), qui ont provoqué la mise hors service de leurs serveurs locaux. Lorsque Microsoft aide les clients à gérer ces types d’attaques, deux catégories d’organisations se dégagent :

    • Les organisations qui utilisaient précédemment la synchronisation de hachage de mot de passe en plus de l’authentification fédérée ou directe ont modifié leur méthode d’authentification principale pour utiliser la synchronisation de hachage de mot de passe. Ils étaient de nouveau en ligne après quelques heures. En accédant aux e-mails par le biais de Microsoft 365, elles ont pu résoudre les problèmes et accéder à d’autres charges de travail sur le cloud.

    • Les organisations n’ayant pas auparavant activé la synchronisation de hachage du mot de passe ont dû faire appel à des systèmes de messagerie externes non fiables pour la communication et la résolution des problèmes. Dans ce cas, il leur a fallu des semaines pour restaurer leur infrastructure d’identité locale, avant que les utilisateurs ne puissent se connecter à nouveau aux applications basées sur le Cloud.

  3. Protection des identités. Azure AD Identity Protection avec Azure AD Premium P2 est un des meilleurs moyens de protéger les utilisateurs dans le cloud. Microsoft analyse en permanence Internet à la recherche de listes d’utilisateurs et de mots de passe vendues et mises à disposition sur le « dark web » par des utilisateurs malveillants. Azure AD peut utiliser ces informations pour vérifier si les noms d’utilisateur et les mots de passe de votre organisation sont compromis. Dès lors, il est primordial d’activer la synchronisation de hachage du mot de passe, et ce quelle que soit la méthode d’authentification vous utilisez (fédérée ou directe). Les informations d’identification divulguées sont présentées sous forme de rapport. Utilisez ces informations pour bloquer ou forcer les utilisateurs à modifier leurs mots de passe lorsqu’ils tentent de se connecter avec des mots de passe divulgués.

Principes de conception Azure AD Connect

Cette section décrit les domaines qui doivent être envisagés lors de la conception de l’implémentation d’Azure AD Connect. Il s’agit d’une exploration approfondie de certains aspects. Ces concepts sont également décrits brièvement dans d’autres documents.

sourceAnchor

L’attribut sourceAnchor est défini en tant qu’ attribut immuable pendant la durée de vie d’un objet. Il identifie de façon univoque un objet comme étant le même objet local et dans Azure AD. L’attribut est également appelé immutableId et les deux noms sont interchangeables. L’attribut est utilisé pour les scénarios suivants :

  • Quand un nouveau serveur de moteur de synchronisation est créé ou recréé après un scénario de récupération d’urgence, cet attribut lie les objets existants dans Azure AD à des objets locaux.

  • Si vous passez d’une identité de cloud uniquement à un modèle d’identité synchronisé, alors cet attribut permet une correspondance exacte et concrète des objets existants dans Azure AD avec des objets locaux.

  • Si vous utilisez la fédération, alors cet attribut est utilisé avec userPrincipalName dans la revendication pour identifier un utilisateur de façon univoque.

La valeur de l’attribut doit respecter les règles suivantes :

  • sa longueur doit être inférieure à 60 caractères

    • les caractères autres que a-z, A-Z ou 0-9 sont codés et comptabilisés comme 3 caractères
  • Ne contient pas de caractère spécial : \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _

  • elle doit être globalement unique

  • elle doit être une chaîne, un entier ou une valeur binaire

  • elle ne doit pas être basée sur le nom de l’utilisateur, car celui-ci est susceptible de changer

  • elle ne doit pas respecter la casse et doit éviter les valeurs qui peuvent varier selon la casse

  • elle doit être assignée lorsque l’objet est créé.

Si vous avez une seule forêt locale, alors l’attribut que vous devez utiliser est ms-DS-ConsistencyGuid. C’est également l’attribut utilisé quand vous utilisez la configuration rapide dans Azure AD Connect, ainsi que l’attribut utilisé par DirSync. Si vous avez plusieurs forêts et que vous ne déplacez pas d’utilisateurs entre les forêts et les domaines, ms-DS-ConsistencyGUID est un attribut approprié. Une autre solution consiste à choisir un attribut existant, dont vous êtes sûr qu’il ne changera pas. employeeID est un des attributs couramment utilisés. Si vous envisagez d’opter pour un attribut contenant des lettres, assurez-vous qu’il n’y a aucun risque de changement de la casse (majuscule ou minuscule) pour la valeur de l’attribut. Des attributs inappropriés qui ne doivent pas être utilisés sont notamment ceux qui ont le nom de l’utilisateur. Une fois l’attribut sourceAnchor choisi, l’Assistant stocke les informations dans votre client Azure AD. Les informations seront utilisées dans le cadre d’une installation future d’Azure AD Connect.

Authentification dans Azure AD

Lors de l’intégration de votre annuaire local à Azure AD, les paramètres de synchronisation peuvent affecter la façon dont l’utilisateur s’authentifie. Azure AD utilise userPrincipalName (UPN) pour authentifier l’utilisateur. Toutefois, lorsque vous synchronisez vos utilisateurs, vous devez choisir avec soin l’attribut à utiliser pour la valeur de userPrincipalName. Lorsque vous sélectionnez l’attribut fournissant la valeur d’UPN à utiliser dans Azure, vous devez vous assurer que :

  • Les valeurs de l’attribut sont conformes à la syntaxe UPN (RFC 822), c’est-à-dire au format username@domain

  • Le suffixe des valeurs correspond à l’un des domaines personnalisés vérifiés dans Azure AD

Dans la configuration rapide, le choix supposé de l’attribut est userPrincipalName. Si l’attribut userPrincipalName ne contient pas la valeur que vous souhaitez que vos utilisateurs utilisent pour se connecter à Azure, alors choisissez Installation personnalisée.

État du domaine personnalisé et nom d’utilisateur principal

Assurez-vous qu’il existe un domaine vérifié pour le suffixe UPN (user principal name). John est un utilisateur de contoso.com. Vous souhaitez que John utilise l’UPN local john@contoso.com pour se connecter à Azure une fois que vous avez synchronisé les utilisateurs sur votre répertoire Azure AD contoso.onmicrosoft.com. Pour ce faire, vous devez ajouter et vérifier contoso.com comme domaine personnalisé dans Azure AD avant de commencer la synchronisation des utilisateurs. Si le suffixe UPN de John, par exemple contoso.com, ne correspond pas à un domaine vérifié dans Azure AD, alors Azure AD remplace le suffixe UPN par contoso.onmicrosoft.com.

Certaines organisations ont des domaines non routables, comme contoso.local, ou de simples domaines à étiquette unique, comme contoso. Dans Azure AD, vous n’êtes pas en mesure de vérifier un domaine non routable. Azure AD Connect peut uniquement se synchroniser sur un domaine vérifié dans Azure AD. Lorsque vous créez un répertoire Azure AD, il crée un domaine routable qui devient le domaine par défaut de votre Azure AD, par exemple contoso.onmicrosoft.com. Par conséquent, il devient nécessaire de vérifier tous les autres domaines routables dans un scénario de ce type, si vous ne souhaitez pas effectuer de synchronisation avec le domaine par défaut onmicrosoft.com.

Azure AD Connect détecte si vous exécutez un environnement de domaine non routable et vous avertit en temps utile si vous tentez de poursuivre la configuration rapide. Si votre domaine n’est pas routable, il est probable que les UPN des utilisateurs aient également des suffixes non routables. Par exemple, si vous exécutez sous contoso.local, Azure AD Connect suggère que vous utilisez des paramètres personnalisés plutôt que d’utiliser les paramètres Express. Avec les paramètres personnalisés, vous êtes en mesure de spécifier l’attribut à utiliser comme UPN pour la connexion à Azure une fois les utilisateurs synchronisés avec Azure AD.

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é ; il comprend les configurations prises en charge et non prises en charge.

Topologie commune Description
Une seule forêt, un seul client Azure AD 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.
Plusieurs forêts, un seul client Azure AD 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é).
Plusieurs forêts, un seul serveur de synchronisation et des utilisateurs sont représentés dans un seul annuaire 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 : maillage complet avec GALSync facultative 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.
Plusieurs forêts : forêt de ressources de comptes 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.
Serveur de test 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.
Plusieurs clients Azure AD Il existe une relation 1:1 entre un serveur Azure AD Connect Sync et un locataire Azure AD. Pour chaque client Azure AD, vous avez besoin d’une installation d’un serveur de synchronisation Azure AD Connect. De par leur conception, les instances de locataire Azure AD sont isolées. Ainsi, les utilisateurs dans un locataire ne peuvent pas voir les utilisateurs dans l’autre locataire. Si vous souhaitez cette séparation, cette configuration est prise en charge. Dans le cas contraire, vous devez utiliser le modèle de locataire Azure AD unique.
Chaque objet une seule fois dans un client Azure AD Dans cette topologie, un seul serveur de synchronisation Azure AD Connect est connecté à chaque client Azure AD. Les serveurs Azure AD Connect Sync doivent être configurés pour le filtrage afin d’avoir chacun un ensemble d’objets mutuellement exclusifs. Vous pouvez, par exemple, délimiter l’étendue de chaque serveur à un domaine ou à une unité d’organisation spécifique.

Facteurs impactant les composants d’Azure AD Connect

Le diagramme ci-dessous illustre l’architecture générale d’un moteur de provisionnement connecté à une seule forêt, mais la connexion à plusieurs forêts est également prise en charge. Cette architecture montre les interactions entre les divers composants.

Le diagramme montre comment les annuaires connectés et le moteur de provisionnement Azure AD Connect interagissent, y compris l’espace de connecteur et les composants Metaverse dans une base de données SQL.

Le moteur de provisionnement se connecte à chaque forêt Active Directory et à Azure AD. Importer est le processus consistant à obtenir des informations de chaque annuaire. Exporter fait référence à la mise à jour des annuaires à partir du moteur de provisionnement. Synchroniser est l’opération qui évalue les règles de transfert des objets au sein du moteur de provisionnement.

Azure AD Connect utilise les zones de transit, les règles et les processus suivants pour effectuer la synchronisation entre Active Directory et Azure AD :

  • Espace connecteur (CS) : les objets de chaque annuaire connecté (CD), les annuaires réels, sont d’abord mis en transit dans cet espace en attendant d’être traités par le moteur de provisionnement. Azure AD a son propre espace connecteur, tout comme chaque forêt à laquelle vous vous connectez.

  • Métaverse (MV) : les objets qui doivent être synchronisés sont créés ici en fonction des règles de synchronisation. Les objets doivent avoir été créés dans le métaverse afin de pouvoir ensuite remplir des objets et des attributs dans les autres annuaires connectés. Il y a un seul métaverse.

  • Règles de synchronisation : elles déterminent quels objets seront créés (projetés) ou quels objets seront connectés (joints) aux objets dans le métaverse. Les règles de synchronisation déterminent également quelles valeurs d’attribut seront copiées ou transformées vers et depuis les annuaires.

  • Profils d’exécution : ils regroupent les étapes du processus de copie des objets et de leurs valeurs d’attribut, selon les règles de synchronisation définies, entre les zones de transit et les annuaires connectés.