Planifier, concevoir et implémenter Microsoft Entra Connect

Effectué

Azure AD Connect est une solution qui fait un pont entre l'Active Directory d'une organisation locale et votre Microsoft Entra ID basée sur le cloud. Le service informatique peut synchroniser les identités locales dans Azure et garantit une identité cohérente sur les deux plateformes. Cette connexion active des services comme la synchronisation de hachage du mot de passe, l’authentification directe et l’authentification unique (SSO) transparente.

Microsoft Entra Connect est l'outil Microsoft conçu pour atteindre et atteindre vos objectifs 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 Microsoft Entra ID.
• Authentification directe – Méthode de connexion qui permet d’utiliser le même mot de passe localement et dans le cloud, mais qui ne nécessite aucune infrastructure supplémentaire d’un environnement fédéré.
• Intégration de fédération : la fédération est une partie facultative de Microsoft Entra 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.
• Monitoring de l'intégrité : Microsoft Entra Connect-Health fournit un monitoring robuste.

Pourquoi utiliser Microsoft Entra Connect ?

L’intégration de vos annuaires locaux avec Microsoft Entra ID améliore la productivité de vos utilisateurs en leur fournissant une identité commune pour accéder aux ressources cloud et locales. Grâce à Microsoft Entra 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. Microsoft Entra Connect remplace les versions antérieures des outils d'intégration d'identité. Il est inclus dans votre abonnement Microsoft Entra ID.

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 Microsoft Entra 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 Microsoft Entra. 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

Lorsque vous choisissez cette méthode d’authentification, Microsoft Entra ID gère le processus de connexion des utilisateurs. Lorsque vous l’associez à l’authentification unique (SSO) transparente, les utilisateurs peuvent se connecter aux applications cloud sans avoir à entrer à nouveau leurs informations d’identification. L’authentification cloud propose deux options :

Synchronisation de hachage de mot de passe Microsoft Entra (PHS). Il s'agit du moyen le plus simple d'activer l'authentification pour les objets annuaire locaux dans Microsoft Entra. 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 Microsoft Entra ID basées sur Active Directory. Une fois activée, la synchronisation de hachage du mot de passe fait partie du processus de synchronisation Microsoft Entra 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. Si les organisations choisissent de le faire, il est possible d'utiliser des aperçus à partir d'identités avec des rapports Microsoft Entra Identity Protection avec Microsoft Entra ID 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. Microsoft Entra 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 Microsoft Entra Connect en mode de 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 Microsoft Entra ID. 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 (PTA) Microsoft Entra. Fournit une validation de mot de passe simple pour les services d’authentification Microsoft Entra à 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 du compte d’un utilisateur sur site est désactivé, verrouillé ou que son mot de passe expire. L’accès peut également être refusé si la tentative de connexion s’effectue en dehors des heures où l’utilisateur est autorisé à se connecter.
• 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 Microsoft Entra Connect. Ce déploiement 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 du hachage du mot de passe ne se fait pas automatiquement et vous devez utiliser Microsoft Entra Connect pour changer la méthode de connexion manuellement.

Authentification fédérée

Quand vous choisissez cette méthode d'authentification, Microsoft Entra ID délègue le processus d'authentification à un système d'authentification approuvée distinct, notamment 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 Microsoft Entra. La maintenance et la gestion du système fédéré ne relèvent pas de Microsoft Entra ID. 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 Microsoft Entra ID 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 Microsoft Entra. 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 :

  

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

  

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

  

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, l’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 :

• 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é. Évitez les pannes en utilisant la synchronisation de hachage du mot de passe, car le service d'authentification cloud Microsoft Entra est mis à l'échelle globalement et est toujours disponible.

• 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 ont activé la synchronisation du hachage du mot de passe, avec une authentification fédérée ou directe, modifient leur authentification principale. Ils peuvent ensuite 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.

• Protection des identités. L'une des meilleures façons de protéger les utilisateurs dans le cloud est Microsoft Entra Identity Protection avec Microsoft Entra Premium P2. 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. Microsoft Entra ID 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.

Concepts de design de Microsoft Entra Connect

Cette section décrit les domaines qui doivent être envisagés lors de la conception de l'implémentation de Microsoft Entra 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 localement et dans Microsoft Entra ID. 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 reprise d’activité après sinistre, cet attribut lie les objets existants dans Microsoft Entra ID à 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 Microsoft Entra ID 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

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

• Ne doit pas respecter la casse et doit éviter les valeurs qui varient selon la casse

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

Si vous avez une seule forêt locale, l’attribut que vous devez utiliser est objectGuid. Vous pouvez également utiliser l'attribut objectGuid lorsque vous utilisez des paramètres express dans Microsoft Entra Connect. Et également 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 , alors objectGUID est un attribut approprié à utiliser même dans ce cas. Une autre solution consiste à choisir un attribut existant, dont vous êtes sûr qu’il ne changera pas. employeeIDest 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 locataire Microsoft Entra. Les informations seront utilisées dans le cadre d’une installation ultérieure de Microsoft Entra Connect.

Connexion Microsoft Entra

Les paramètres de synchronisation de votre intégration d'annuaire locale avec Microsoft Entra ID peuvent affecter la façon dont l'utilisateur vérifie son identité. Microsoft Entra 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 d’attribut sont conformes à la syntaxe UPN (RFC 822), c’est-à-dire au format nom_utilisateur@domaine.
• Le suffixe des valeurs correspond à l’un des domaines personnalisés vérifiés dans Microsoft Entra ID.

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 le nom d'utilisateur principal john@contoso.com local pour se connecter à Azure une fois que vous avez synchronisé les utilisateurs sur votre répertoire Microsoft Entra contoso.onmicrosoft.com. Pour ce faire, vous devez ajouter et vérifier contoso.com comme domaine personnalisé dans Microsoft Entra ID afin de pouvoir commencer la synchronisation des utilisateurs. Si le suffixe de nom d'utilisateur principal de John, notamment contoso.com, ne correspond pas à un domaine vérifié dans Microsoft Entra ID, l'outil remplace le suffixe de nom d'utilisateur principal par contoso.onmicrosoft.com.

Certaines organisations ont des domaines non routables, comme contoso.local, ou de simples domaines à étiquette unique, comme contoso. Vous ne pouvez pas vérifier un domaine non routable. Microsoft Entra Connect ne peut synchroniser qu’avec un domaine vérifié dans Microsoft Entra ID. Lorsque vous créez un annuaire Microsoft Entra, cela crée un domaine routable qui devient le domaine par défaut de votre Microsoft Entra ID, 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.

Microsoft Entra 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 un suffixe non routable. Si vous utilisez par exemple contoso.local, Microsoft Entra Connect vous suggère d'utiliser les paramètres personnalisés plutôt que 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 Microsoft Entra ID.

Topologies pour Microsoft Entra Connect

Cette section décrit diverses topologies locales et Microsoft Entra ID qui utilisent Microsoft Entra Connect Sync comme solution d'intégration clé. Elle comprend les configurations prises en charge et non prises en charge.

Topologie commune	Description
Forêt unique, locataire Microsoft Entra unique	La topologie la plus commune est une forêt locale unique, avec un ou plusieurs domaines, et un locataire Microsoft Entra unique. La synchronisation de hachage de mot de passe est utilisée pour l'authentification. Il s’agit de la seule topologie prise en charge par l’installation rapide de Microsoft Entra Connect.
Plusieurs forêts, un seul locataire Microsoft Entra	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 seul serveur de synchronisation Microsoft Entra Connect. 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 Microsoft Entra ID, 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 fois dans le métavers et agrégé dans le locataire 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. Microsoft Entra Connect ne peut pas être utilisé pour GALSync local.
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 Teams. Tous les services Exchange et Teams, 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	Microsoft Entra 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 locataires Microsoft Entra	Il existe une relation 1:1 entre un serveur de synchronisation Microsoft Entra Connect et un locataire. Pour chaque locataire Microsoft Entra, vous avez besoin d'une installation de serveur de synchronisation Microsoft Entra Connect. Les instances de locataire AD sont conçues pour être isolées. Ainsi, les utilisateurs dans un locataire ne peuvent pas voir les utilisateurs dans l’autre locataire. La séparation des utilisateurs est une configuration prise en charge. Dans le cas contraire, vous devez utiliser le modèle de locataire unique de Microsoft Entra.
Chaque objet n'est utilisé qu'une seule fois dans un locataire Microsoft Entra	Dans cette topologie, un serveur de synchronisation Microsoft Entra Connect est connecté à chaque locataire. Les serveurs de synchronisation Microsoft Entra Connect doivent être configurés pour le filtrage afin que chacun ait un ensemble d'objets mutuellement exclusifs pour fonctionner. Vous pouvez, par exemple, délimiter l’étendue de chaque serveur à un domaine ou à une unité d’organisation spécifique.

Facteurs de composant Microsoft Entra 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 moteur d’approvisionnement se connecte à chaque forêt Active Directory et à Microsoft Entra ID. 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.

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

• 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. Microsoft Entra ID 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.

Synchronisation cloud Microsoft Entra

La synchronisation cloud Microsoft Entra Connect est conçue pour atteindre les objectifs d'identité hybride pour la synchronisation des utilisateurs, des groupes et des contacts avec Microsoft Entra ID. La synchronisation est réalisée en utilisant l'agent d'approvisionnement cloud au lieu de l'application Microsoft Entra Connect. Elle peut être utilisée parallèlement à la synchronisation Microsoft Entra Connect et offre les avantages suivants :

• prise en charge de la synchronisation avec un locataire Microsoft Entra à partir d'un environnement Active Directory déconnecté de plusieurs forêts : Les scénarios courants comprennent la fusion et l'acquisition. Les forêts AD de la société acquise sont isolées des forêts AD de la société mère. Les entreprises qui ont historiquement eu plusieurs forêts AD.
• Installation simplifiée avec des agents de provisionnement légers : les agents agissent comme un pont entre AD et Microsoft Entra ID, avec toute la configuration de synchronisation gérée dans le cloud.
• Plusieurs agents d'approvisionnement peuvent être utilisés pour simplifier les déploiements de haute disponibilité, essentiels pour les organisations qui dépendent de la synchronisation de hachage du mot de passe entre AD et Microsoft Entra ID.
• Prise en charge des grands groupes comptant jusqu’à 50 000 membres. Nous vous recommandons d’utiliser uniquement le filtre d’étendue d’unités d’organisation pour synchroniser les grands groupes.

Avec la synchronisation cloud Microsoft Entra Connect, le provisionnement d'AD vers Microsoft Entra ID est orchestré dans Microsoft Online Services. Il suffit à une organisation de déployer, dans son environnement sur site ou hébergé par IaaS, un agent léger qui agit comme un pont entre Microsoft Entra ID et AD. La configuration de l'approvisionnement est managée et managée dans le cadre du service. Rappel : la synchronisation s’exécute toutes les 2 minutes.