Scénarios de gestion multilocataire des utilisateurs
Cet article est le deuxième d’une série d’articles qui fournissent des recommandations pour configurer et assurer la gestion du cycle de vie des utilisateurs dans des environnements multilocataires Microsoft Entra. Pour plus d’informations consultez les articles de la série répertoriés ci-dessous.
- L’article Présentation de la gestion multilocataire des utilisateurs est le premier d’une série d’articles d’aide à la configuration et à la gestion du cycle de vie des utilisateurs dans les environnements multilocataires Microsoft Entra.
- L’article Considérations courantes sur la gestion multilocataire des utilisateurs fournit des conseils sur les points suivants : synchronisation entre clients, objet annuaire, accès conditionnel Microsoft Entra, contrôle d’accès supplémentaire et Office 365.
- Solutions courantes de gestion multilocataire des utilisateurs, lorsque la location unique ne fonctionne pas pour votre scénario, cet article donne des conseils sur ces problématiques : gestion automatique du cycle de vie des utilisateurs et allocation des ressources entre les locataires, partage d’applications locales entre locataires.
Ces conseils vous aident à mettre en place une gestion cohérente du cycle de vie des utilisateurs. La gestion de cycle de vie comprend le provisionnement, la gestion et le déprovisionnement des utilisateurs entre les locataires à l’aide des outils Azure disponibles, par exemple Microsoft Entra B2B Collaboration (B2B) et la synchronisation interlocataire.
Cet article décrit trois scénarios pour lesquels vous pouvez utiliser les fonctionnalités de gestion multilocataire des utilisateurs.
- À l’initiative de l’utilisateur final
- Avec script
- Automatisé
Scénario lancé par un utilisateur final
Dans les scénarios initiés par l’utilisateur final, les administrateurs de locataires de ressources délèguent certaines capacités aux utilisateurs du locataire. Les administrateurs permettent aux utilisateurs finals d’inviter des utilisateurs externes à accéder au locataire, à une application ou à une ressource. Vous pouvez inviter des utilisateurs à partir du locataire de base, ou ils peuvent s’inscrire individuellement.
Par exemple, une société internationale de services professionnels collabore avec des sous-traitants sur des projets. Les sous-traitants (les utilisateurs externes) nécessitent un accès aux applications et documents de la société. Les administrateurs de la société peuvent déléguer aux utilisateurs finals la possibilité d’inviter des sous-traitants, ou configurer un libre-service pour l’accès des sous-traitants aux ressources.
Provisionnement de comptes
Voici les méthodes les plus couramment utilisées pour inviter les utilisateurs finals à accéder aux ressources de locataire.
- Invitations basées sur l’application. Les applications Microsoft (telles que Teams et SharePoint) peuvent permettre les invitations d’utilisateurs externes. Configurez les paramètres d’invitation B2B dans Microsoft Entra B2B et dans les applications appropriées.
- MyApps. Les utilisateurs peuvent inviter et affecter des utilisateurs externes à des applications à l’aide de MyApps. Le compte d’utilisateur doit disposer des autorisations de l’approbateur Inscription des applications en libre-service. Les propriétaires de groupes peuvent inviter des utilisateurs externes dans leurs groupes.
- Gestion des droits d’utilisation. Permet aux administrateurs ou aux propriétaires de ressources de créer des packages d’accès contenant des ressources, des organisations externes autorisées, une expiration des utilisateurs externes et des stratégies d’accès. Publiez des packages d’accès pour permettre l’inscription en libre-service d’utilisateurs externes à l’accès aux ressources.
- Portail Azure. Les utilisateurs finaux ayant le rôle Inviteur d’invités peuvent se connecter au portail Azure et inviter des utilisateurs externes à partir du menu Utilisateurs dans Microsoft Entra ID.
- Par programmation (PowerShell, API Graph). Les utilisateurs finals pourvus du rôle Inviteur d’invités peuvent utiliser PowerShell ou l’API Graph pour inviter des utilisateurs externes.
Échange d’invitations
Lorsque vous provisionnez des comptes pour accéder à une ressource, les invitations par e-mail sont envoyées à l’adresse e-mail de l’utilisateur invité.
Lorsqu’un utilisateur invité reçoit une invitation, il peut suivre le lien contenu dans l’e-mail vers l’URL d’échange. Ce faisant, l’utilisateur invité peut approuver ou refuser l’invitation et, si nécessaire, créer un compte d’utilisateur externe.
Les utilisateurs invités peuvent également essayer d’accéder directement à la ressource, procédé appelé « échange juste-à-temps (JAT) », si l’un des scénarios suivants est avéré.
- L’utilisateur invité dispose déjà d’un compte Microsoft Entra ID ou d’un compte Microsoft, ou
- Les administrateurs ont autorisé les codes secrets à usage unique par e-mail.
Pendant l’échange juste-à-temps, les considérations suivantes peuvent s’appliquer.
- Si les administrateurs n’ont pas supprimé les invites de consentement, l’utilisateur doit consentir avant d’accéder à la ressource.
- Vous pouvez autoriser ou bloquer les invitations à des utilisateurs externes d’organisations spécifiques en utilisant une liste verte ou une liste rouge.
Pour plus d’informations, consultez Acceptation d’invitation à Microsoft Entra B2B Collaboration.
Activation de l’authentification par code secret à usage unique
Dans les scénarios où vous autorisez le service B2B ad hoc, activez l’authentification par code secret à usage unique via e-mail. Cette fonctionnalité authentifie les utilisateurs externes lorsque vous ne pouvez pas les authentifier par d’autres moyens, par exemple :
- Microsoft Entra ID.
- Compte Microsoft.
- Compte Gmail via la fédération Google.
- Compte d’un fournisseur d’identité SAML (Security Assertion Markup Language)/WS-Fed via la fédération directe.
Avec l’authentification par code secret à usage unique, il est inutile de créer un compte Microsoft. Quand l’utilisateur externe accepte une invitation ou accède à une ressource partagée, il reçoit un code temporaire par le biais de son adresse e-mail. Il entre ensuite le code pour poursuivre sa connexion.
Gérer des comptes
Dans le scénario initié par l’utilisateur final, l’administrateur du locataire de ressources gère les comptes d’utilisateurs externes dans le locataire de ressource (non mis à jour, en fonction des valeurs mises à jour dans le locataire de base). Les seuls attributs visibles reçus comprennent l’adresse e-mail et le nom d’affichage.
Vous pouvez configurer d’autres attributs sur les objets utilisateur externe pour faciliter différents scénarios (tels que les scénarios de droits d’utilisation). Vous pouvez inclure le remplissage du carnet d’adresses avec des coordonnées. Envisagez, par exemple, les attributs suivants.
- HiddenFromAddressListsEnabled [ShowInAddressList]
- FirstName [GivenName]
- LastName [SurName]
- Titre
- Département
- TelephoneNumber
Vous pouvez définir ces attributs pour ajouter des utilisateurs externes à la liste d’adresses globale (GAL) et à la recherche de personnes (par exemple, au sélecteur de personnes SharePoint). D’autres scénarios peuvent nécessiter des attributs différents (tels que la définition des droits d’utilisation et des autorisations sur les packages d’accès, l’appartenance de groupe dynamique et les revendications SAML).
Par défaut, la liste d’adresses globale masque les utilisateurs externes invités. Définissez les attributs des utilisateurs externes comme n’étant pas masqués pour les inclure dans la liste d’adresses globale unifiée. La section Microsoft Exchange Online de Considérations courantes relatives à la gestion multilocataire des utilisateurs explique comment atténuer les limites en créant des utilisateurs membres externes plutôt que des utilisateurs invités externes.
Déprovisionnement des comptes
Les scénarios initiés par les utilisateur finals décentralisent les décisions d’accès, ce qui peut créer une problématique de décision quant au moment où un utilisateur externe et son accès associé doivent être supprimés. La gestion des droits d’utilisation et les révisions d’accès vous permettent de vérifier et de supprimer des utilisateurs externes existants et leur accès aux ressources.
Lorsque vous invitez des utilisateurs en dehors de la gestion des droits d’utilisation, vous devez créer un processus distinct pour examiner et gérer leur accès. Par exemple, si vous invitez directement un utilisateur externe via SharePoint dans Microsoft 365, il ne se trouve pas dans votre processus de gestion des droits d’utilisation.
Scénario avec script
Dans le scénario avec script, les administrateurs de locataire de ressources déploient un processus de tirage par script pour automatiser la détection et le provisionnement des utilisateurs externes.
Prenons l’exemple d’une entreprise rachetant un concurrent. Chaque entreprise a un seul locataire Microsoft Entra. Celle-ci veut que les scénarios Au premier jour suivants fonctionnent sans que les utilisateurs aient à se soumettre à des étapes d’invitation ou d’acceptation. Tous les utilisateurs doivent être en mesure d’effectuer les opérations suivantes :
- Utiliser l’authentification unique pour toutes les ressources provisionnées.
- Se trouver les uns les autres, et trouver des ressources dans une liste d’adresses globale unifiée.
- Déterminer la présence de l’autre et lancez la conversation.
- Accéder à des applications en fonction de groupes d’appartenance dynamique.
Dans ce scénario, le locataire de chaque organisation est le locataire de base pour ses employés existants, tout en étant le locataire de ressources pour les employés de l’autre organisation.
Provisionnement de comptes
Avec une requête delta, les administrateurs de locataire peuvent déployer un processus de tirage par script pour automatiser la détection et le provisionnement d’identités permettant de prendre en charge l’accès aux ressources. Ce processus recherche les nouveaux utilisateurs dans le locataire de base. Il utilise les API Graph B2B pour approvisionner les nouveaux utilisateurs en tant qu’utilisateurs externes dans le locataire de ressources, comme illustré dans le diagramme de topologie multilocataire suivant.
- Les administrateurs de locataire organisent préalablement les informations d’identification, et donnent leur consentement pour autoriser la lecture à chaque locataire.
- Les administrateurs de locataire automatisent l’énumération et le tirage des utilisateurs délimités vers le locataire de ressources.
- Utilisez l’API Microsoft Graph avec les autorisations accordées pour lire et provisionner des utilisateurs avec l’API d’invitation.
- Le provisionnement initial peut lire les attributs de la source et les appliquer à l’objet utilisateur cible.
Gérer des comptes
L’organisation des ressources peut accroître les données de profil pour prendre en charge les scénarios de partage en mettant à jour les attributs des métadonnées de l’utilisateur dans le locataire de ressources. Cependant, si une synchronisation continue est nécessaire, une solution synchronisée peut être une meilleure option.
Déprovisionnement des comptes
Une requête delta peut indiquer quand un utilisateur externe doit être déprovisionné. La gestion des droits d’utilisation et les révisions d’accès peuvent fournir un moyen de vérification et de suppression des utilisateurs externes existants et de leur accès aux ressources.
Si des utilisateurs sont invités en dehors de la gestion des droits d’utilisation, créez un processus distinct pour vérifier et gérer l’accès des utilisateurs externes. Par exemple, si vous invitez l’utilisateur externe directement via SharePoint dans Microsoft 365, il ne se trouve pas dans votre processus de gestion des droits d’utilisation.
Scénario automatisé
Le partage synchronisé entre locataires est le plus complexe des modèles décrits dans cet article. Ce modèle permet des options de gestion et de déprovisionnement plus automatisés que ceux lancés par l’utilisateur final ou avec script.
Dans les scénarios automatisés, les administrateurs de locataire de ressources utilisent un système de provisionnement d’identités pour automatiser des processus de provisionnement et de déprovisionnement. Dans les scénarios au sein de l’instance Cloud commercial de Microsoft, nous disposons d’une synchronisation entre locataires. Dans les scénarios qui couvrent les instances Cloud souverain de Microsoft, vous avez besoin d’autres approches, car la synchronisation entre locataires ne prend pas encore en charge le déploiement intercloud.
Par exemple, dans une instance Microsoft Commercial Cloud, un conglomérat multinational/régional possède plusieurs filiales dont les exigences sont les suivantes.
- Chacune d’elles a son propre locataire Microsoft Entra, et doit travailler avec les autres.
- En plus de synchroniser les nouveaux utilisateurs entre les locataires, il faut synchroniser automatiquement les mises à jour des attributs et automatiser le déprovisionnement.
- Si un employé ne fait plus partie d’une filiale, il faut supprimer son compte de tous les autres locataires lors de la synchronisation suivante.
Dans un scénario intercloud étendu, le fournisseur d’une Base industrielle de défense (DIB) dispose d’une filiale commerciale et d’une filiale dédiée à la défense. Celles-ci ont des exigences réglementaires en concurrence :
- L’activité de défense des États-Unis réside dans un locataire Cloud souverain américain, tel que Microsoft 365 US Government GCC High et Azure Government.
- L’activité commerciale se situe sur un locataire Microsoft Entra distinct, par exemple un environnement Microsoft Entra s’exécutant sur le cloud Azure mondial.
Pour agir comme une seule entreprise déployée dans une architecture intercloud, tous les utilisateurs se synchronisent avec les deux locataires. Cette approche permet une disponibilité de la liste d’adresses globale unifiée entre les deux locataires et peut garantir que les utilisateurs synchronisés automatiquement sur les deux locataires incluent des droits d’utilisation et des restrictions pour les applications et le contenu. Des exemples de conditions incluent :
- Les employés américains peuvent avoir un accès complet aux deux locataires.
- Les employés non américains apparaissent dans la liste d’adresses globale unifiée des deux locataires, mais n’ont pas accès au contenu protégé dans le locataire GCC High.
Ce scénario nécessite une synchronisation et une gestion des identités automatiques pour configurer les utilisateurs dans les deux locataires tout en les associant aux stratégies appropriées d’habilitation et de protection des données.
La solution B2B intercloud vous oblige à configurer les Paramètres d’accès entre locataires pour chaque organisation avec laquelle vous souhaitez collaborer dans l’instance de cloud distant.
Provisionnement de comptes
Cette section décrit trois techniques d’automatisation du provisionnement de comptes dans le scénario automatisé.
Technique 1 : Utiliser la fonctionnalité de synchronisation interlocataire intégrée dans Microsoft Entra ID
Cette approche fonctionne uniquement lorsque tous les locataires à synchroniser se trouvent dans la même instance de cloud (par exemple, Commercial à Commercial).
Technique 2 : Provisionner les comptes avec Microsoft Identity Manager
Utilisez une solution de gestion des identités et des accès (IAM) externe, telle que Microsoft Identity Manager (MIM) comme moteur de synchronisation.
Ce déploiement avancé utilise MIM comme moteur de synchronisation. MIM appelle l’API Microsoft Graph et Exchange Online PowerShell. D’autres implémentations peuvent inclure l’offre Microsoft Industry Solutions de service managé ADSS (Active Directory Synchronization Services) hébergé dans le cloud. Il existe des offres autres que celles de Microsoft, que vous pouvez créer à partir de zéro avec d’autres offres IAM (telles que SailPoint, Omada et OKTA).
Vous effectuez une synchronisation cloud-à-cloud d’identités (utilisateurs, contacts et groupes) d’un locataire à un autre, comme illustré dans le schéma suivant.
Les considérations qui n’entrent pas dans le cadre de cet article incluent l’intégration d’applications locales.
Technique 3 : Provisionner des comptes avec Microsoft Entra Connect
Cette technique s’applique uniquement aux organisations complexes qui gèrent toutes les identités dans le service AD DS (Active Directory Domain Services) classique s’appuyant sur Windows Server. L’approche utilise Microsoft Entra Connect en tant que moteur de synchronisation, comme le montre le diagramme suivant.
Contrairement à la technique MIM, toutes les sources d’identité (utilisateurs, contacts et groupes) proviennent du service AD DS (Active Directory Domain Services) Windows Server classique. L’annuaire AD DS constitue généralement un déploiement local pour une organisation complexe qui gère l’identité de plusieurs locataires. L’identité cloud uniquement dépasse le cadre de cette technique. Toutes les identités doivent se trouver dans AD DS pour être incluses dans l’étendue de la synchronisation.
En théorie, cette technique synchronise un utilisateur dans un locataire de base, en tant qu’utilisateur membre interne (comportement par défaut). Elle peut également synchroniser un utilisateur dans un locataire de ressources en tant qu’utilisateur externe (comportement personnalisé).
Microsoft prend en charge cette technique de double synchronisation utilisateur, en portant une attention particulière aux modifications qui se produisent dans la configuration de Microsoft Entra Connect. Par exemple, si vous apportez des modifications à la configuration d’installation pilotée par l’Assistant, vous devez documenter les modifications s’il vous faut reconstruire la configuration pendant un incident de support.
Par défaut, Microsoft Entra Connect ne peut pas synchroniser un utilisateur externe. Vous devez l’augmenter au moyen d’un processus externe (comme un script PowerShell) pour convertir les utilisateurs, des comptes internes vers les comptes externes.
Les avantages de cette technique incluent la synchronisation de l’identité par Microsoft Entra Connect avec des attributs stockés dans AD DS. La synchronisation peut inclure des attributs de carnet d’adresses, des attributs de gestionnaire, des appartenances de groupe et d’autres attributs d’identité hybride dans tous les locataires de l’étendue. Elle déprovisionne l’identité conformément à AD DS. Elle n’a pas besoin d’une solution IAM plus complexe pour gérer l’identité cloud de cette tâche spécifique.
Il existe une relation un-à-un de Microsoft Entra Connect par locataire. Chaque locataire a sa propre configuration de Microsoft Entra Connect, que vous pouvez modifier individuellement pour permettre la prise en charge de la synchronisation des comptes d’utilisateur membre ou externe.
Choix de la topologie appropriée
La plupart des clients utilisent une des topologies suivantes dans les scénarios automatisés.
- Une topologie de maillage permet de partager toutes les ressources de tous les locataires. Vous créez des utilisateurs provenant d’autres locataires dans chaque locataire de ressource, en tant qu’utilisateurs externes.
- Une topologie unique de locataire de ressources utilise un seul locataire (le locataire de ressources), dans lequel les utilisateurs d’autres locataires sont des utilisateurs externes.
Référez-vous au tableau suivant comme arbre de décision lorsque vous concevez votre solution. Faisant suite au tableau, des diagrammes illustrent les deux topologies pour vous aider à déterminer laquelle convient à votre organisation.
Comparaison entre les topologies de maillage et les topologies de locataire de ressources unique
Considération | Topologie de maillage | Locataire de ressources unique |
---|---|---|
Chaque entreprise a un locataire Microsoft Entra distinct avec des utilisateurs et des ressources | Oui | Oui |
Emplacement des ressources et collaboration | ||
Les applications partagées et les autres ressources restent dans leur locataire de base actuel | Oui | Non. Vous pouvez partager uniquement les applications et les autres ressources du locataire de ressource. Vous ne pouvez pas partager les applications et les autres ressources restantes dans d’autres locataires. |
Toutes sont visibles dans les listes d’adresses globales de chaque société (liste d’adresses globale unifiée) | Oui | Non |
Accès et administration des ressources | ||
Vous pouvez partager TOUTES les applications connectées à Microsoft Entra ID entre toutes les entreprises. | Oui | Non. Seules les applications du locataire de ressource sont partagées. Vous ne pouvez pas partager les applications restantes dans d’autres locataires. |
Administration des ressources globales | Se poursuit au niveau locataire. | Regroupée dans le locataire de ressources. |
Licences : Office 365 SharePoint dans Microsoft 365, la liste d’adresses globale unifiée, l’accès Teams prennent tous en charge les invités ; cependant, ce n’est pas le cas des autres scénarios Exchange Online. | Se poursuit au niveau locataire. | Se poursuit au niveau locataire. |
Licences : Microsoft Entra ID (premium) | Les premiers 50 000 utilisateurs actifs mensuels sont gratuits (par locataire). | Les premiers 50 000 utilisateurs actifs mensuels sont gratuits. |
Licences : applications SaaS (Software as a Service) | Restent dans les locataires individuels, peuvent nécessiter des licences par utilisateur, par locataire. | Toutes les ressources partagées se trouvent dans le locataire de ressources unique. Vous pouvez examiner un éventuel regroupement des licences sur le seul locataire si c’est approprié. |
Topologie de maillage
Le schéma suivant illustre la topologie de maillage.
Dans une topologie de maillage, chaque utilisateur dans chaque locataire de base se synchronise avec tous les autres locataires, qui deviennent des locataires de ressources.
- Vous pouvez partager n’importe quelle ressource avec des utilisateurs externes dans un locataire.
- Chaque organisation peut voir tous les utilisateurs du conglomérat. Dans le diagramme ci-dessus, il y a quatre listes d’adresses globales unifiées, chacune contient les utilisateurs de base et les utilisateurs externes des trois autres locataires.
L’article Considérations courantes relatives à la gestion multilocataire des utilisateurs fournit des informations sur l’approvisionnement, la gestion et le déprovisionnement d’utilisateurs dans ce scénario.
Topologie de maillage pour une architecture intercloud
Vous pouvez utiliser la topologie de maillage dès le nombre de deux locataires atteint, comme dans le scénario du sous-traitant travaillant pour la Base industrielle de défense, qui utilise une solution mixte de cloud souverain transversal. Comme pour la topologie de maillage, chaque utilisateur dans chaque locataire de base se synchronise avec l’autre locataire, qui devient un locataire de ressources. Dans le diagramme de la section Technique 3, l’utilisateur interne du locataire Commercial public se synchronise avec le locataire souverain américain GCC High, en tant que compte d’utilisateur externe. En même temps, l’utilisateur interne de GCC High se synchronise avec le locataire Commercial, en tant que compte d’utilisateur externe.
Le diagramme illustre également les emplacements de stockage des données. La catégorisation et la conformité des données dépassent le cadre de cet article, mais vous pouvez inclure des droits d’utilisation et des restrictions aux applications et au contenu. Le contenu peut inclure les emplacements où résident les données appartenant à un utilisateur interne (telles que les données stockées dans une boîte aux lettres Exchange Online ou sur OneDrive). Le contenu peut se trouver dans son locataire de base et non pas dans le locataire de ressources. Les données partagées peuvent se trouver dans l’un ou l’autre locataire. Vous pouvez restreindre l’accès au contenu via le contrôle d’accès et des stratégies d’accès conditionnel.
Topologie de locataire de ressources unique
Le diagramme suivant illustre la topologie de locataire de ressources unique.
Dans une topologie de locataire de ressources unique, les utilisateurs et leurs attributs se synchronisent avec le locataire de ressources (la société A dans le diagramme ci-dessus).
- Toutes les ressources partagées entre les organisations membres doivent se trouver dans le locataire de ressources unique. Si plusieurs filiales présentent des abonnements aux mêmes applications SaaS, il existe une possibilité de regrouper ces abonnements.
- Seule la liste d’adresses globale du locataire de ressources affiche les utilisateurs de toutes les sociétés.
Gérer des comptes
Cette solution détecte et synchronise les modifications d’attributs des utilisateurs du locataire source avec ceux des utilisateurs externes du locataire de ressources. Vous pouvez utiliser ces attributs pour prendre des décisions d’autorisation (par exemple, lorsque vous utilisez des groupes d’appartenance dynamique).
Déprovisionnement des comptes
L’automation détecte la suppression d’un objet dans l’environnement source, et supprime l’objet utilisateur externe associé dans l’environnement cible.
L’article Considérations courantes relatives à la gestion multilocataire des utilisateurs fournit des informations supplémentaires sur l’approvisionnement, la gestion et le déprovisionnement d’utilisateurs dans ce scénario.
Étapes suivantes
- L’article Présentation de la gestion multilocataire des utilisateurs est le premier d’une série d’articles d’aide à la configuration et à la gestion du cycle de vie des utilisateurs dans les environnements multilocataires Microsoft Entra.
- L’article Considérations courantes sur la gestion multilocataire des utilisateurs fournit des conseils sur les points suivants : synchronisation entre clients, objet annuaire, accès conditionnel Microsoft Entra, contrôle d’accès supplémentaire et Office 365.
- Solutions courantes de gestion multilocataire des utilisateurs, lorsque la location unique ne fonctionne pas pour votre scénario, cet article donne des conseils sur ces problématiques : gestion automatique du cycle de vie des utilisateurs et allocation des ressources entre les locataires, partage d’applications locales entre locataires.