Options d’infrastructure d’identité parallèle et combinée

Microsoft offre un vaste éventail de technologies et de solutions pour l’intégration entre les différents composants locaux et cloud de son infrastructure d’identité. Souvent, les clients ne sont pas clairs sur les technologies les plus adaptées et peuvent penser erronément que « la version la plus récente couvre tous les scénarios des versions technologiques antérieures ».

Cet article aborde les scénarios dans lesquels votre entreprise suit un cheminement complexe décrit ci-dessous, et qui cherche à combiner vos informations d’identité. Dans l’idéal, une organisation avec une seule source de ressources humaines (RH), une seule forêt Active Directory (AD) et un seul locataire Microsoft Entra, tous intégrés avec les mêmes personnes en leur sein, aura une expérience d’identité optimale pour les Microsoft Online Services. Toutefois, dans la pratique, un client entreprise n’est pas toujours dans une situation où cela est possible. Par exemple, le client peut passer par une fusion ou avoir besoin d’une isolation pour certains utilisateurs ou applications. Un client disposant de plusieurs systèmes RH, de plusieurs AD ou de plusieurs locataires Microsoft Entra doit décider s’il faut combiner un moindre nombre d’instances de chaque ou les conserver en parallèle.

Sur la base des commentaires de nos clients, voici quelques-uns des scénarios et exigences courants.

Scénarios qui surviennent avec les identités multicloud et multiorganisations

• Fusions et acquisitions (M&A) : référence à une situation où, généralement, une société A achète une société B.
• Changement d’image : changement de nom ou de marque de l’entreprise, généralement changement de nom de domaine de courrier.
• Consolidation de locataires Microsoft Entra ID ou Office 365 : les sociétés avec plusieurs locataires Office 365 peuvent souhaiter les combiner en raison d’exigences de conformité ou historiques.
• Consolidation de domaine ou forêt Active Directory : sociétés évaluant la possibilité d’effectuer une consolidation de domaine ou de forêt Active Directory.
• Cessions : quand une division ou un groupe d’une société est vendu ou devient indépendant.
• Confidentialité des informations utilisateur : lorsque des sociétés ont des exigences consistant à empêcher la visibilité publique de certaines données (attributs), que seuls des groupes ou utilisateurs délégués appropriés peuvent lire, modifier et mettre à jour.

Exigences résultant de ces scénarios

• Placez les données de tous les utilisateurs et groupes dans un emplacement unique, incluant la disponibilité des e-mails et des états pour la planification des réunions en créant un répertoire central ou universel.
• Conservez un nom d’utilisateur et des informations d’identification uniques tout en réduisant le besoin d’entrer des noms d’utilisateur et des mots de passe dans toutes les applications en implémentant l’authentification unique.
• Rationalisez l’intégration des utilisateurs afin qu’elle ne prenne pas des semaines ou des mois.
• Préparez l’organisation à de futures acquisitions et demandes de gestion des accès.
• Activez et améliorez la collaboration et la productivité entre sociétés.
• Réduisez la probabilité de violation de sécurité ou d’exfiltration de données avec des stratégies de sécurité déployées de manière centralisée et cohérente.

Scénarios non traités dans cet article

• M&A partiel. Par exemple, une organisation achète une partie d’une autre organisation.
• Cession ou fractionnement d’organisations
• Changement de nom d’organisations.
• Co-entreprises ou partenaires temporaires

Cet article présente divers environnements d’identité multicloud ou multiorganisation, dont des scénarios M&A que Microsoft prend en charge aujourd’hui. Il décrit également la manière dont une organisation peut sélectionner les technologies appropriées en fonction de la façon dont elle approche la consolidation.

Options de consolidation pour un scénario de M&A hypothétique

Les sections suivantes couvrent quatre scénarios majeurs de M&A hypothétique :

Supposons que Contoso soit une entreprise cliente dont le service informatique dispose d’un système RH unique (local), d’une seule forêt Active Directory et d’un seul locataire Microsoft Entra ID pour ses applications, le tout s’exécutant comme prévu. Des utilisateurs sont importés à partir de son système RH dans Active Directory et projetés dans Microsoft Entra ID, puis de là dans des applications SaaS. Ce scénario est illustré dans le diagramme ci-dessous où les flèches montrent le flux des informations d’identité. Le même modèle est également applicable à des clients disposant d’un système RH cloud, tel que Workday ou SuccessFactors approvisionnant Active Directory, pas seulement à des clients utilisant Microsoft Identity Manager (MIM).

Ensuite, Contoso a commencé à fusionner avec Litware qui disposait précédemment de son propre service informatique indépendant. Contoso va gérer la fusion et s’attend à ce que son service informatique continue d’avoir des applications de Contoso inchangées, mais souhaite que les utilisateurs de Litware y aient accès et les utilisent pour collaborer. Pour les applications Microsoft, les applications SaaS tierces et les applications personnalisées, l’état final doit être que les utilisateurs Contoso et Litware aient accès sur le plan conceptuel aux mêmes données.

La première décision du service informatique consiste à déterminer à quel point il souhaite combiner l’infrastructure. Il peut choisir de ne pas s’appuyer sur l’infrastructure d’identité de Litware. Il peut également envisager d’utiliser l’infrastructure de Litware et d’opérer une convergence au fil du temps tout en minimisant les interruptions de l’environnement de Litware. Dans certains cas, le client peut souhaiter conserver l’infrastructure d’identité existante de Litware et ne pas opérer de convergence, tout en continuant à l’utiliser pour permettre aux employés de Litware d’accéder aux applications de Contoso.

Si le client choisit de conserver tout ou partie de l’infrastructure d’identité de Litware, il existe des compromis quant à la proportion d’Active Directory Domain Services ou de Microsoft Entra ID de Litware utilisée pour permettre aux utilisateurs de Litware d’accéder aux ressources de Contoso. Cette section aborde des options réalistes en fonction de ce que Contoso veut utiliser pour les utilisateurs Litware :

• Scénario A : n’utiliser aucune infrastructure d’identité de Litware.
• Scénario B : utiliser les forêts Active Directory de Litware, mais pas son instance Microsoft Entra ID (le cas échéant).
• Scénario C : utiliser l’instance Microsoft Entra ID de Litware.
• Scénario D : utiliser l’infrastructure d’identité non Microsoft de Litware (si Litware n’utilise pas Active Directory / Microsoft Entra ID)

Le tableau suivant récapitule chaque option avec les technologies permettant au client d’obtenir ces résultats, ainsi que les contraintes et avantages de chacune.

À propos de l’installation	A1 : RH unique, IAM et locataire uniques	A2 : RH, IAM unique et locataire distincts	B3 : approbation de forêt Active Directory, Microsoft Entra Connect unique	B4 : Microsoft Entra Connect synchronise son instance Active Directory avec le locataire unique	B5 : Microsoft Entra Connect synchronise dans le cloud son instance Active Directory	C6 : approvisionnement parallèle de plusieurs locataires dans des applications	C7 : lecture à partir du locataire et invitation B2B des utilisateurs	C8 : utilisateurs IAM et B2B uniques selon les besoins	D9 : forêt de domaine avec IdP non Azure AD
Effort de migration	Élevé	Effort moyen	Effort plus faible	Effort faible	Effort faible	None	None	None	None
Effort de déploiement	Moins d’effort	Effort moyen	Effort moyen	Effort moyen	Faible	Faible	Élevé	Élevé	Très élevée
Impact de l’utilisateur final pendant la migration	Élevé	Élevé	Moyenne	Moyenne	Moyenne	None	None	None	None
Effort d’exploitation	Faible coût	Faible coût	Faible coût	Faible coût	Faible coût	Élevé	Élevé	Élevé	Très élevée
Confidentialité et fonctionnalités de données (emplacement géographique/limites de données)	Aucun (obstacle majeur pour les scénarios de géolocalisation)	Isolation limitée même si difficile	Isolation limitée localement mais pas dans le cloud	Isolation limitée localement mais pas dans le cloud	Isolation limitée localement mais pas dans le cloud	Bonne isolation tant localement que dans le cloud	Isolation limitée tant localement que dans le cloud	Isolation limitée tant localement que dans le cloud	Isolation tant localement que dans le cloud
Isolation (délégation distincte et configuration de modèles d’administration différents) Remarque : comme défini dans le système source (RH)	Impossible	Possible	Possible	Possible	Possible	Très possible	Très possible	Très possible	Possible
Fonctionnalités de collaboration	Excellent	Excellent	Excellent	Excellent	Excellent	Médiocre	Moyenne	Moyenne	Médiocre
Modèle d’administration informatique pris en charge (centralisé ou séparé)	Centralisé	Centralisé	Centralisé	Centralisé	Centralisé	Décentralisé	Décentralisé	Décentralisé	Activement décentralisé
Limites	Aucune isolation	Isolation limitée	Isolation limitée	Isolation limitée	Isolation limitée. Aucune fonctionnalité d’écriture différée	Ne fonctionne pas pour les applications Microsoft Online Services. Très dépendant de la capacité de l’application	Requiert que les applications prennent en charge B2B	Requiert que les applications prennent en charge B2B	Requièrent que les applications prennent en charge B2B. Incertitude dans la manière dont tout cela fonctionne ensemble

Détails de la table

• Les employés s’efforcent de prédire l’expertise et le surcroît de travail requis pour implémenter la solution dans une organisation.
• L’équipe d’exploitation s’efforce de prédire le coût et les efforts nécessaires pour maintenir la solution opérationnelle.
• Les fonctionnalités de confidentialité et de données indiquent si la solution autorise la prise en charge de la géolocalisation et des limites de données.
• L’isolation montre si cette solution offre la possibilité de séparer ou de déléguer des modèles d’administration.
• Les fonctionnalités de collaboration montrent le niveau de collaboration que la solution prend en charge. Les solutions intégrées offrent une plus grande fidélité de travail en équipe.
• Le modèle d’administration informatique montre si le modèle d’administration doit être centralisé ou peut être décentralisé.
• Limitations : problèmes ou défis méritant d’être signalés.

Arbre de décision

Utilisez l’arbre de décision suivant pour choisir le scénario le plus approprié pour votre organisation.

Le reste de ce document présente quatre scénarios (de A à D), avec différentes options de prise en charge.

Scénario A : si Contoso ne souhaite pas s’appuyer sur l’infrastructure d’identité existante de Litware

Pour cette option, il se peut que Litware n’ait aucun système d’identité (par exemple, en tant que petite entreprise), ou que le client souhaite désactiver l’infrastructure de Litware. Ou celui-ci souhaite ne toucher à rien en ce qui concerne l’authentification des employés de Litware auprès des applications de Litware, mais attribuer aux employés de Litware de nouvelles identités en lien avec Contoso. Par exemple, si Alice Smith était une employée de Litware, elle pourrait avoir deux identités, Alice@litware.com et ASmith123@contoso.com. Ces identités seraient entièrement distinctes l’une de l’autre.

Option 1 : combiner dans un système RH unique

En règle générale, les clients décideraient d’introduire les employés de Litware dans le système RH de Contoso. Cette option aurait pour effet que ces employés reçoivent des comptes et l’accès approprié aux annuaires et applications de Contoso. Un utilisateur Litware disposerait alors d’une nouvelle identité Contoso qu’il pourrait utiliser pour demander l’accès aux applications Contoso appropriées.

Option 2 : conserver le système RH de Litware

Il n’est parfois pas possible de faire converger les systèmes RH, du moins à brève échéance. Au lieu de cela, le client se connecte à son système d’approvisionnement, par exemple, MIM, pour lire à partir des deux systèmes RH. Dans ce diagramme, le premier système RH est l’environnement Contoso existant, et le deuxième l’ajout de Litware à l’infrastructure globale.

Le même scénario serait également possible en utilisant Workday ou SuccessFactors avec Microsoft Entra en entrée. Contoso pourrait alors intégrer les utilisateurs de la source RH Workday de Litware aux côtés des employés Contoso existants.

Résultats de la consolidation de toute l’infrastructure d’identité

• Infrastructure informatique réduite, un seul système d’identité à gérer, aucune exigence de connectivité réseau, à l’exception d’un système RH.
• Expérience utilisateur final et administrative cohérente

Contraintes de consolidation de l’ensemble de l’infrastructure d’identité

• Toutes les données nécessaires aux employés de Contoso qui provenaient de Litware doivent être migrées vers l’environnement Contoso.
• Toutes les applications intégrées à Active Directory ou Microsoft Entra de Litware qui sont nécessaires pour Contoso doivent être reconfigurées pour l’environnement Contoso. Cette reconfiguration peut nécessiter des modifications de la configuration, des groupes qu’elle utilise pour l’accès, voire des applications elles-mêmes.

Scénario B : si Contoso souhaite conserver les forêts Active Directory de Litware, mais pas utiliser son instance Microsoft Entra ID

Il se peut que Litware ait de nombreuses applications existantes basées sur Active Directory qui lui sont nécessaires. Contoso peut alors souhaiter que les employés de Litware conservent leurs propres identités dans leur AD existant. Un employé de Litware utiliserait alors son identité existante pour l’authentification de ses ressources existantes et l’authentification des ressources Contoso. Dans ce scénario, Litware n’a pas d’identité cloud dans Microsoft Online Services : soit Litware n’était pas un client Microsoft Entra et aucune ressource cloud de Litware ne devait être partagée avec Contoso, soit Contoso a migré les ressources cloud de Litware pour qu’elles fassent partie du locataire de Contoso.

Option 3 : approbation de forêt avec la forêt acquise

Avec une approbation de forêt Active Directory, Contoso et Litware peuvent connecter leurs domaines Active Directory. Cette approbation permet aux utilisateurs Litware d’authentifier des applications intégrées avec Active Directory de Contoso. Par ailleurs Microsoft Entra Connect peut également lire à partir de la forêt Active Directory de Litware de façon à ce que les utilisateurs de Litware s’authentifient auprès des applications intégrées à Microsoft Entra de Contoso. Cette topologie de déploiement nécessite un itinéraire réseau configuré entre les deux domaines, et une connectivité réseau TCP/IP entre tout utilisateur Litware et une application Contoso intégrée avec Active Directory. Il est également facile de configurer des approbations bidirectionnelles de façon à ce que les utilisateurs Contoso puissent accéder aux applications Litware intégrées avec AD (le cas échéant).

Résultat de la configuration d’une approbation de forêt

• Tous les employés de Litware peuvent authentifier les applications intégrées à Active Directory ou Microsoft Entra de Contoso, et Contoso peut utiliser les outils actuels basés sur AD pour gérer l’autorisation.

Contraintes de configuration d’une approbation de forêt

• Requiert une connectivité TCP/IP entre les utilisateurs joints par domaine à une forêt et les ressources jointes à l’autre forêt.
• Requiert que les applications basées sur Active Directory dans la forêt Contoso soient compatibles avec les forêts multiples

Option 4 : configurer Microsoft Entra Connect avec la forêt acquise sans approbation de forêt

Un client peut également configurer Microsoft Entra Connect pour lire à partir d’une autre forêt. Cette configuration permet aux utilisateurs de Litware de s’authentifier auprès des applications intégrées à Microsoft Entra de Contoso, mais ne donne pas aux utilisateurs de Litware accès aux applications intégrées à Active Directory de Contoso. Ces applications Contoso ne reconnaissent pas les utilisateurs de Litware. Cette topologie de déploiement exige une connectivité réseau TCP/IP entre Microsoft Entra Connect et les contrôleurs de domaine de Litware. Par exemple, si Microsoft Entra Connect se trouve sur une machine virtuelle IaaS Contoso, un tunnel doit également être établi vers le réseau de Litware.

Résultat de l’utilisation de Microsoft Entra Connect pour provisionner un locataire

• Tous les employés de Litware peuvent authentifier les applications intégrées à Microsoft Entra de Contoso.

Contraintes liées à l’utilisation de Microsoft Entra Connect pour provisionner un locataire

• Exige une connectivité TCP/IP entre les domaines Active Directory de Litware et Microsoft Entra Connect de Contoso.
• Ne permet pas aux utilisateurs Litware d’accéder aux applications basées sur Active Directory de Contoso

Option 5 : déployer la synchronisation cloud Microsoft Entra Connect dans la forêt acquise

Le provisionnement cloud Microsoft Entra Connect élimine l’exigence de connectivité réseau, mais vous ne pouvez avoir qu’une seule liaison d’Active Directory à Microsoft Entra ID pour un utilisateur donné avec une synchronisation cloud. Les utilisateurs de Litware peuvent authentifier les applications intégrées à Microsoft Entra de Contoso, mais pas les applications intégrées à Active Directory de Contoso. Cette topologie ne nécessite pas de connectivité TCP/IP entre les environnements locaux de Litware et de Contoso.

Résultat du déploiement de la synchronisation cloud Microsoft Entra Connect dans la forêt acquise

• Tous les employés de Litware peuvent authentifier les applications intégrées à Microsoft Entra de Contoso.

Contraintes liées à l’utilisation de la synchronisation cloud Microsoft Entra Connect dans la forêt acquise

• Ne permet pas aux utilisateurs Litware d’accéder aux applications basées sur AD de Contoso

Scénario C : si Contoso souhaite conserver l’instance Microsoft Entra ID de Litware

Litware peut être un client Microsoft Online Services ou Azure ou peut s’appuyer sur une ou plusieurs applications basées sur Microsoft Entra ID. Contoso peut donc décider que les employés Litware conservent leurs propres identités pour accéder à ces ressources. Un employé de Litware utiliserait alors son identité existante pour l’authentification de ses ressources existantes et l’authentification des ressources Contoso.

Ce scénario est approprié dans les cas suivants :

• Litware dispose d’immobilisations conséquentes dans Azure ou Microsoft Online Services, dont plusieurs locataires Office 365 qu’il serait coûteux ou fastidieux de migrer vers un autre locataire.
• Litware pourrait faire l’objet d’une scission à l’avenir, ou opérer en partenariat de manière indépendante.
• Litware n’a pas d’infrastructure locale

Option 6 : maintenir le provisionnement parallèle et l’authentification unique pour les applications dans chaque instance Microsoft Entra ID

Une option pour chaque instance Microsoft Entra ID est de fournir l’authentification unique et de provisionner l’application cible en utilisateurs à partir de son annuaire de manière indépendante. Par exemple, si Contoso utilise une application telle que Salesforce, il fournirait à Litware des droits d’administration nécessaires pour créer des utilisateurs dans le même abonnement Salesforce.

Résultat de l’approvisionnement parallèle

• Les utilisateurs peuvent authentifier des applications à l’aide de leur identité existante sans apporter de modifications à l’infrastructure de Contoso.

Contraintes de l’approvisionnement parallèle

• Si vous utilisez une fédération, celle-ci exige que les applications prennent en charge plusieurs fournisseurs de fédération pour le même abonnement.
• Impossible pour des applications Microsoft telles que Office ou Azure
• Contoso n’a pas de visibilité dans son instance Microsoft Entra ID de l’accès aux applications pour les utilisateurs de Litware

Option 7 : configurer des comptes B2B pour les utilisateurs du locataire acquis

Si Litware exécute son propre locataire, Contoso peut lire les utilisateurs de ce locataire et, via l’API B2B, inviter chacun de ces utilisateurs au locataire Contoso (Ce processus d’invitation en bloc peut être effectué par le biais du connecteur de graphe MIM par exemple.) Si Contoso a également des applications basées sur AD à mettre à la disposition des utilisateurs de Litware, MIM pourrait également créer dans Active Directory des utilisateurs mappés aux UPN des utilisateurs Microsoft Entra afin que le Proxy d’application puisse exécuter KCD pour le compte d’une représentation d’un utilisateur de Litware dans l’instance Active Directory de Contoso.

Ensuite, quand un employé Litware souhaite accéder à une application Contoso, il peut le faire en s’authentifiant auprès de son propre annuaire, avec attribution d’accès au locataire de ressource.

Résultat de la configuration de comptes B2B pour des utilisateurs de l’autre locataire

• Les utilisateurs Litware peuvent authentifier des applications Contoso, et Contoso contrôle cet accès dans son locataire.

Contraintes de configuration de comptes B2B pour des utilisateurs de l’autre locataire

• Requiert un compte en double pour chaque utilisateur Litware qui requiert l’accès aux ressources Contoso.
• Requiert que les applications soient compatibles B2B pour l’authentification unique.

Option 8 : configurer B2B, mais avec un flux RH commun pour les deux annuaires

Dans certains cas, après l’acquisition, l’organisation peut converger sur une seule plateforme RH, tout en continuant à exécuter des systèmes de gestion des identités existants. Dans ce scénario, MIM pourrait provisionner des utilisateurs dans plusieurs systèmes Active Directory, en fonction de la partie de l’organisation à laquelle l’utilisateur est affilié. Il pourrait continuer à utiliser B2B afin que les utilisateurs authentifient leur annuaire existant et disposent d’une GAL unifiée.

Résultat de la configuration d’utilisateurs invités B2B à partir d’un flux de système RH commun

• Les utilisateurs Litware peuvent s’authentifier auprès d’applications Contoso, et Contoso contrôler cet accès dans son locataire.
• Litware et Contoso ont une GAL unifiée.
• Aucune modification de l’instance Active Directory ou Microsoft Entra ID de Litware

Contraintes de configuration d’utilisateurs invités B2B à partir d’un flux de système RH commun

• Requiert des modifications de l’approvisionnement de Contoso pour envoyer également des utilisateurs à l’Active Directory de Litware, et une connectivité entre les domaines de Litware et de Contoso.
• Requiert que les applications soient compatibles B2B pour l’authentification unique.

Scénario D : si Litware utilise une infrastructure non Active Directory

Enfin, si Litware utilise un autre service d’annuaire, qu’il soit local ou dans le cloud, Contoso IT peut toujours configurer le fait que les employés Litware s’authentifient et puissent accéder aux ressources de Contoso à l’aide de leur identité existante.

Option 9 : utiliser une fédération directe B2B (préversion publique)

Dans ce scénario, Litware est supposé avoir :

• Des annuaires existants, tel OpenLDAP, voire une base de données SQL ou un fichier plat d’utilisateurs avec leurs adresses e-mail qu’ils peuvent partager régulièrement avec Contoso.
• un fournisseur d’identité qui prend en charge SAML, tel PingFederate ou OKTA ;
• un domaine DNS routé publiquement, tel Litware.com, et des utilisateurs avec des adresses e-mail dans ce domaine.

Dans cette approche, Contoso configurerait une relation de fédération directe entre son locataire pour ce domaine et le fournisseur d’identité de Litware, puis lirait régulièrement les mises à jour des utilisateurs de Litware à partir de leur annuaire pour inviter ces utilisateurs à l’instance Microsoft Entra ID de Contoso. Cette mise à jour peut être effectuée avec un connecteur Graph MIM. Si Contoso a également des applications basées sur Active Directory à mettre à la disposition des utilisateurs de Litware, MIM pourrait également créer dans Active Directory des utilisateurs mappés aux UPN des utilisateurs Microsoft Entra afin que le Proxy d’application puisse exécuter KCD pour le compte d’une représentation d’un utilisateur de Litware dans l’instance Active Directory de Contoso.

Résultat de l’utilisation d’une fédération directe B2B

• Les utilisateurs de Litware s’authentifient auprès de l’instance Microsoft Entra ID de Contoso avec leur fournisseur d’identité existant et accèdent aux applications web locales et cloud de Contoso.

Contraintes liés à l’utilisation d’une fédération directe B2B

• Exigez que les applications Contoso soient en mesure de prendre en charge l’authentification unique d’utilisateur B2B.

Étapes suivantes

• Qu’est-ce que la synchronisation cloud Microsoft Entra Connect ?
• Configurer le provisionnement entrant pour Microsoft Entra ID
• Configurer une fédération directe B2B
• Options de gestion multilocataire des utilisateurs
• Qu’est-ce que le provisionnement d’application ?