Fédérer Google Cloud avec Microsoft Entra ID (anciennement Azure AD)

Last reviewed 2024-06-26 UTC

Ce document explique comment configurer Cloud Identity ou Google Workspace pour utiliser Microsoft Entra ID (anciennement Azure AD) en tant que fournisseur d'identité et source des identités.

Cet article compare la structure logique de Microsoft Entra ID à celle utilisée par Cloud Identity et Google Workspace, et explique comment mapper des locataires, des domaines, des utilisateurs et des groupes Microsoft Entra ID.

Implémenter la fédération

Google Cloud utilise les identités Google pour l'authentification et la gestion des accès. La gestion manuelle des identités Google pour chaque employé peut entraîner des coûts de gestion inutiles lorsque tous les employés possèdent déjà un compte dans Microsoft Entra ID. En fédérant les identités des utilisateurs entre Google Cloud et votre système de gestion des identités existant, vous pouvez automatiser la maintenance des identités Google et associer leur cycle de vie à des utilisateurs existants dans Microsoft Entra ID.

La configuration de la fédération entre Microsoft Entra ID et Cloud Identity ou Google Workspace repose sur deux éléments :

• Provisionnement des comptes utilisateur : les utilisateurs et les groupes concernés sont régulièrement synchronisés entre Microsoft Entra ID et Cloud Identity ou Google Workspace. Ce processus garantit que lorsque vous créez un utilisateur dans Microsoft Entra ID ou que vous synchronisez un nouvel utilisateur d'Active Directory avec Microsoft Entra ID, il est également disponible dans Google Cloud afin qu'il puisse être référencé dans Google Cloud avant même que l'utilisateur associé ne se connecte pour la première fois. Ce processus garantit également la propagation des suppressions d'utilisateurs.

  Le provisionnement fonctionne à sens unique, ce qui signifie que les modifications apportées dans Microsoft Entra ID sont répliquées dans Google Cloud, mais pas l'inverse. De plus, le provisionnement n'inclut pas les mots de passe.

• Authentification unique : chaque fois qu'un utilisateur doit s'authentifier, Google Cloud délègue l'authentification à Microsoft Entra ID à l'aide du protocole SAML (Security Assertion Markup Language). Selon sa configuration, Microsoft Entra ID peut effectuer l'une des opérations suivantes :

  • effectuer lui-même l'authentification ;
  • utiliser l'authentification directe ou la synchronisation de hachage de mot de passe ;
  • déléguer l'authentification à un serveur AD FS sur site.

Donner à Cloud Identity ou Google Workspace la possibilité de déléguer l'authentification à Microsoft Entra ID évite non seulement d'avoir à synchroniser les mots de passe avec Google Cloud, mais garantit également l'application des règles ou des mécanismes d'authentification multifacteur (MFA, Multi-Factor Authentication) en vigueur configurés dans Microsoft Entra ID ou AD FS.

Remarque : Ce document fait référence à l'application de galerie Google Cloud/G Suite Connector by Microsoft disponible sur la place de marché Microsoft Azure. Cette application est un produit Microsoft, et Google n'en assure ni la gestion, ni l'assistance.

Structure logique de Microsoft Entra ID

Lorsque vous utilisez Azure, vous utilisez un ou plusieurs locataires Microsoft Entra ID (également appelés annuaires). Les locataires Microsoft Entra ID constituent une structure de niveau supérieur. Ils sont considérés comme des limites administratives et servent de conteneurs pour les utilisateurs, les groupes, ainsi que les ressources et les groupes de ressources.

Chaque locataire Microsoft Entra ID est associé à au moins un domaine DNS. Ce domaine DNS figure dans les noms d'utilisateur (également appelés noms d'utilisateur principaux ou UPN, User Principal Names), qui prennent la forme name@domain, où domain est l'un des domaines DNS associés au locataire correspondant.

Une entreprise peut gérer plusieurs locataires Microsoft Entra ID. Cette approche est fréquemment utilisée pour faire la distinction entre différentes parties de l'organisation, séparer les ressources de production des ressources de développement et de test, ou encore pour utiliser des locataires distincts pour intégrer plusieurs forêts à partir d'Active Directory sur site.

Structure logique de Google Cloud

Dans Google Cloud, les organisations servent de conteneurs pour toutes les ressources et peuvent être segmentées à l'aide de dossiers et de projets. Toutefois, à l'exception des comptes de service, les organisations ne servent pas à gérer les utilisateurs et les groupes, ce qui les différencie des locataires Microsoft Entra ID.

Pour la gestion des utilisateurs et des groupes, Google Cloud s'appuie sur Cloud Identity ou Google Workspace. Un compte Cloud Identity ou Google Workspace sert d'annuaire privé pour les utilisateurs et les groupes. En tant qu'administrateur du compte, vous pouvez contrôler le cycle de vie et la configuration des utilisateurs et des groupes et définir les modalités d'authentification.

Lorsque vous créez un compte Cloud Identity ou Google Workspace, une organisation Google Cloud est automatiquement créée. Le compte Cloud Identity ou Google Workspace et l'organisation Google Cloud qui lui est associée portent le même nom et sont liés l'un à l'autre. Toutefois, une organisation Google Cloud est autorisée à référencer des utilisateurs et des groupes à partir d'autres comptes Cloud Identity ou Google Workspace.

Intégrer Microsoft Entra ID et Google Cloud

Malgré certaines similitudes entre la structure logique de Microsoft Entra ID et celle de Google Cloud, il n'existe pas de mappage unique entre les deux structures fonctionnant aussi bien dans tous les scénarios possibles. Au lieu de cela, l'approche optimale à adopter pour intégrer les deux systèmes et mapper la structure dépend de plusieurs facteurs :

• Comment mapper des locataires Microsoft Entra ID sur des comptes Cloud Identity ou Google Workspace
• Comment mapper des domaines DNS
• Comment mapper des utilisateurs
• Comment mapper des groupes

Les sections suivantes abordent chacun de ces facteurs.

Google Cloud n'interagit qu'avec Microsoft Entra ID, et non avec votre solution Active Directory sur site. Aussi, la façon dont vous avez mappé les forêts et les domaines de votre solution Active Directory sur site sur Microsoft Entra ID n'a que peu d'importance.

Mappeur de locataires Microsoft Entra ID

Les sections suivantes décrivent comment mapper des locataires Microsoft Entra ID pour ces scénarios :

• Locataire unique
• Locataires multiples
• Utilisateurs externes

Locataire unique

Si vous utilisez un seul locataire Microsoft Entra ID, vous pouvez le mapper sur un seul compte Cloud Identity ou Google Workspace et configurer la fédération entre les deux. Ce compte Cloud Identity ou Google Workspace constitue ensuite la base d'une organisation Google Cloud unique que vous pouvez utiliser pour gérer toutes les ressources Google Cloud.

Locataires multiples

Dans les grandes organisations, il n'est pas rare d'avoir plusieurs locataires Microsoft Entra ID. Des locataires multiples peuvent être utilisés pour différencier les environnements de test et de production ou les différentes parties d'une organisation.

Il est possible de mapper plusieurs locataires Microsoft Entra ID sur un seul compte Cloud Identity ou Google Workspace, et de configurer le provisionnement des utilisateurs et l'authentification unique en conséquence. Toutefois, un tel mappage N:1 peut affaiblir l'isolation entre les locataires Microsoft Entra ID : si vous accordez à plusieurs locataires Microsoft Entra ID l'autorisation de créer et de modifier des utilisateurs dans un seul compte Cloud Identity ou Google Workspace, cela signifie que ces locataires peuvent interférer et altérer leurs modifications.

En règle générale, une meilleure approche pour intégrer plusieurs locataires Microsoft Entra ID consiste à créer un compte Cloud Identity ou Google Workspace distinct pour chaque locataire et à configurer la fédération entre chaque paire.

Dans Google Cloud, une organisation distincte est créée pour chaque compte Cloud Identity ou Google Workspace. Google Cloud permet d'organiser les ressources à l'aide de projets et de dossiers au sein d'une même organisation. Il est donc souvent peu pratique de disposer de plusieurs organisations. Vous pouvez cependant sélectionner l'une des organisations et l'associer aux autres comptes Cloud Identity ou Google Workspace, créant ainsi une organisation fédérée avec plusieurs forêts Active Directory. Les autres organisations restent inutilisées.

Utilisateurs externes

Microsoft Entra ID B2B vous permet de convier des utilisateurs externes en tant qu'invités sur votre locataire Microsoft Entra ID. Un utilisateur est créé pour chaque invité, et Microsoft Entra ID attribue automatiquement un UPN à ces utilisateurs invités. L'UPN généré par Microsoft Entra ID utilise un préfixe dérivé de l'adresse e-mail de l'invité, associé au domaine initial du locataire : prefix#EXT#@tenant.onmicrosoft.com.

Le provisionnement des utilisateurs invités entre Microsoft Entra ID et Cloud Identity ou Google Workspace est soumis à certaines limites :

• Vous ne pouvez pas mapper l'UPN des utilisateurs invités sur des adresses e-mail dans Cloud Identity ou Google Workspace, car le domaine onmicrosoft.com ne peut pas être ajouté et validé dans Cloud Identity ou Google Workspace. Vous devez donc mapper les utilisateurs à l'aide d'un attribut autre que l'UPN.
• Si un utilisateur invité est suspendu dans son locataire d'origine, il est possible que l'utilisateur correspondant dans Cloud Identity ou Google Workspace reste actif et que l'accès aux ressources Google Cloud ne soit pas révoqué correctement.

Afin de mieux gérer les utilisateurs invités qui proviennent d'un locataire Microsoft Entra ID différent, il est préférable de créer plusieurs comptes Cloud Identity ou Google Workspace, comme indiqué dans la section précédente, chacun étant fédéré avec un locataire Microsoft Entra ID différent. Pour en savoir plus, consultez la page Provisionnement des comptes utilisateur et authentification unique Microsoft Entra ID B2B.

Pour que l'accès à certaines ressources Google Cloud puisse être accordé à un utilisateur externe, celui-ci ne doit pas nécessairement disposer d'un compte dans Cloud Identity ou Google Workspace. Sauf en cas de restriction par des règles, vous pouvez également ajouter directement l'utilisateur externe en tant que membre à l'organisation, aux projets ou aux dossiers correspondants, à condition que cet utilisateur dispose d'une identité Google.

Mapper des domaines DNS

Le DNS joue un rôle crucial à la fois pour Microsoft Entra ID et pour Cloud Identity et Google Workspace. Lorsque vous envisagez de fédérer Microsoft Entra ID et Google Cloud, le deuxième facteur à prendre en compte est le mode de partage ou de mappage des domaines DNS entre Microsoft Entra ID et Google Cloud.

Utiliser des domaines DNS dans Google Cloud

Google Sign-In, sur lequel Google Cloud s'appuie pour l'authentification, utilise des adresses e-mail pour identifier les utilisateurs. L'utilisation d'adresses e-mail garantit non seulement que chaque utilisateur est unique, mais permet également à Google Cloud d'envoyer des messages de notification à ces adresses.

Google Sign-In détermine l'annuaire ou le fournisseur d'identité à utiliser pour authentifier un utilisateur en fonction de la partie "domaine" des adresses e-mail, qui suit le caractère @. Pour une adresse e-mail qui utilise le domaine gmail.com, par exemple, Google Sign-In utilise l'annuaire des utilisateurs Gmail pour l'authentification.

Lorsque vous créez un compte Google Workspace ou Cloud Identity, vous créez un annuaire privé pouvant être utilisé pour l'authentification lors de l'inscription. De la même manière que l'annuaire Gmail est associé au domaine gmail.com, les comptes Google Workspace et Cloud Identity doivent être associés à un domaine personnalisé. Trois types de domaines différents sont utilisés :

• Domaine principal : ce domaine identifie le compte Cloud Identity ou Google Workspace et sert également de nom d'organisation dans Google Cloud. Vous devez spécifier ce nom de domaine lors de votre inscription à Cloud Identity ou Google Workspace.
• Domaine secondaire : en plus du domaine principal, vous pouvez associer des domaines secondaires à un compte Cloud Identity ou Google Workspace. Chaque utilisateur de l'annuaire est associé soit au domaine principal, soit à l'un des domaines secondaires. Deux utilisateurs ([e-mail] et [e-mail]) sont considérés comme des utilisateurs distincts si example.com est le domaine principal et secondary.example.com est un domaine secondaire.
• Domaine d'alias : un domaine d'alias est un nom alternatif pour un autre domaine. Autrement dit, [e-mail] et [e-mail] font référence au même utilisateur si alias.example.com est configuré en tant que domaine d'alias pour example.com.

Tous les domaines doivent répondre aux exigences suivantes :

• Il doit s'agir de noms de domaine DNS globaux et valides. Durant la mise en place, vous aurez sans doute besoin d'un accès administrateur aux zones DNS correspondantes afin de valider la propriété du domaine.
• Un domaine tel que example.com ne peut faire référence qu'à un seul annuaire. Toutefois, vous pouvez utiliser différents sous-domaines, par exemple subdomain.example.com, pour faire référence à différents annuaires.
• Le domaine principal et les domaines secondaires doivent posséder un enregistrement MX valide pour que les messages envoyés aux adresses e-mail formées à partir de ce nom de domaine puissent être correctement remis.

Utilisation des domaines DNS dans Microsoft Entra ID

La manière dont Cloud Identity et Google Workspace utilisent le DNS est semblable à la manière dont Microsoft Entra ID s'appuie sur le DNS pour distinguer les locataires Microsoft Entra ID et associer des noms d'utilisateur aux locataires. Toutefois, vous devez tenir compte des deux différences notables suivantes :

1. Domaines initiaux : lorsque vous créez un locataire Microsoft Entra ID, le locataire est associé à un domaine initial, qui est un sous-domaine de onmicrosoft.com. Ce domaine est différent de tout nom de domaine personnalisé que vous pourriez enregistrer, car vous ne possédez pas le domaine et vous ne disposez pas d'un accès administrateur à la zone DNS correspondante.

   Cloud Identity n'a pas d'équivalent de domaine initial. Vous devez donc posséder tous les domaines que vous associez à un compte Cloud Identity. Cette condition signifie que vous ne pouvez pas enregistrer un sous-domaine onmicrosoft.com en tant que domaine Cloud Identity.

2. Domaines utilisés dans les identifiants d'utilisateur : Microsoft Entra ID fait la distinction entre les adresses e-mail MOERA (Microsoft Online Email Routing Addresses, adresses de routage des e-mails en ligne Microsoft) et les UPN. Tous deux respectent le format RFC 822 (user@domain), mais ils servent des objectifs différents : les UPN servent à identifier les utilisateurs et sont utilisés dans le formulaire d'inscription, alors que seules les adresses MOERA sont utilisées pour la remise des e-mails.

   Le suffixe de domaine utilisé par les UPN doit correspondre à l'un des domaines enregistrés de votre locataire Microsoft Entra ID. Cette exigence ne s'applique pas aux adresses e-mail.

   Cloud Identity et Google Workspace ne s'appuient pas sur le concept d'UPN, mais utilisent l'adresse e-mail d'un utilisateur comme identifiant. Par conséquent, le domaine utilisé par l'adresse e-mail doit correspondre à l'un des domaines enregistrés du compte Cloud Identity ou Google Workspace.

Un locataire Microsoft Entra ID et un compte Cloud Identity ou Google Workspace peuvent utiliser les mêmes domaines DNS. Si l'utilisation des mêmes domaines n'est pas possible, vous pouvez configurer le provisionnement des utilisateurs et l'authentification unique pour remplacer les noms de domaine.

Compte tenu des deux différences décrites ci-dessus, vous devez baser votre mappage de domaine sur la manière dont vous prévoyez de mapper les utilisateurs entre Microsoft Entra ID et Cloud Identity ou G Suite.

Map users (Mapper des utilisateurs)

Le troisième facteur à prendre en compte lorsque vous envisagez de fédérer Microsoft Entra ID avec Google Cloud est le moyen de mapper les utilisateurs entre Microsoft Entra ID et Cloud Identity ou Google Workspace.

Le mappage d'utilisateurs Microsoft Entra ID et d'utilisateurs Cloud Identity ou Google Workspace requiert deux informations pour chaque utilisateur :

1. Un ID unique et stable que vous pouvez utiliser lors de la synchronisation pour déterminer quel utilisateur Microsoft Entra ID correspond à quel utilisateur dans Cloud Identity ou Google Workspace.
2. Une adresse e-mail dont la partie "domaine" correspond à un domaine principal, secondaire ou d'alias dans Cloud Identity. Cette adresse e-mail doit être lisible, car elle sera utilisée partout dans Google Cloud.

En interne, Microsoft Entra ID identifie les utilisateurs à l'aide d'ObjectId, un ID unique généré de manière aléatoire. Bien que cet ID soit stable et corresponde donc à la première condition, il est dénué de sens pour l'humain et ne respecte pas le format d'une adresse e-mail. Pour mapper des utilisateurs, les seules options pratiques consistent à effectuer un mappage par UPN ou par adresse e-mail.

Si l'utilisateur saisit une adresse e-mail appartenant à un compte Cloud Identity ou Google Workspace configuré pour utiliser l'authentification unique avec Microsoft Entra ID, il est alors redirigé vers l'écran de connexion de Microsoft Entra ID.

Microsoft Entra ID utilise des UPN, et non des adresses e-mail, pour identifier les utilisateurs. L'écran de connexion invite l'utilisateur à fournir un UPN.

Si le locataire Microsoft Entra ID est configuré pour utiliser AD FS pour l'authentification, l'utilisateur est redirigé vers l'écran de connexion d'AD FS. Les utilisateurs peuvent se connecter aux services AD FS à l'aide de leur UPN Active Directory ou de leur nom de connexion antérieur à Windows 2000 (domain\user).

Si l'adresse e-mail utilisée pour Cloud Identity ou Google Workspace, l'UPN utilisé par Microsoft Entra ID et l'UPN utilisé par Active Directory sont tous différents, les différents écrans de connexion peuvent vite devenir confus pour les utilisateurs finaux. En revanche, si les trois identifiants sont les mêmes, comme c'est le cas dans les captures d'écran données à titre d'exemple ([e-mail]), les utilisateurs ne sont pas confrontés aux différences techniques entre les UPN et les adresses e-mail, ce qui minimise les risques de confusion.

Mapper par UPN

Du point de vue de l'expérience utilisateur, le mappage des UPN Microsoft Entra ID à des adresses e-mail Cloud Identity ou Google Workspace peut être considéré comme la meilleure option. Le fait de s'appuyer sur les UPN présente un autre avantage : Microsoft Entra ID garantit l'unicité et vous permet ainsi d'éviter les risques de conflits de noms.

Pour mapper des UPN Microsoft Entra ID à des adresses e-mail Cloud Identity, vous devez toutefois répondre aux exigences suivantes :

• Les UPN Microsoft Entra ID doivent être des adresses e-mail valides afin que tous les e-mails de notification envoyés par Google Cloud soient correctement remis dans la boîte aux lettres de l'utilisateur. Dans le cas contraire, vous pouvez configurer des adresses e-mail d'alias pour vous assurer que l'utilisateur reçoit ces e-mails.
• Les UPN de tous les utilisateurs concernés dans Microsoft Entra ID doivent comporter un domaine personnalisé comme suffixe (user@custom-domain). Les UPN utilisant le domaine initial Microsoft Entra ID ([e-mail]) ne peuvent pas être mappés sur des adresses e-mail dans Cloud Identity, car le domaine initial n'est pas détenu par vous, mais par Microsoft.
• Tous les domaines personnalisés utilisés par Microsoft Entra ID pour les UPN doivent également être enregistrés dans Cloud Identity. Cela signifie que vous devez avoir accès aux zones DNS correspondantes pour pouvoir effectuer la validation de domaine. Afin d'éviter de remplacer les enregistrements DNS TXT existants que vous avez éventuellement créés pour valider la propriété du domaine dans Microsoft Entra ID, vous pouvez utiliser un enregistrement CNAME pour valider la propriété du domaine dans Cloud Identity.

Mapper des utilisateurs par adresse e-mail

Si le mappage des UPN Microsoft Entra ID sur les adresses e-mail Cloud Identity ou Google Workspace n'est pas possible dans votre cas, vous pouvez mapper les utilisateurs par adresse e-mail.

Lorsque vous spécifiez une adresse e-mail dans Active Directory, elle est stockée dans l'attribut mail de l'objet user correspondant. Microsoft Entra ID synchronise ensuite cette valeur avec l'attribut Mail dans Microsoft Entra ID. Microsoft Entra ID rend également l'attribut disponible pour le provisionnement des utilisateurs, afin que vous puissiez le mapper sur l'adresse e-mail dans Cloud Identity ou cloudid_name_short.

L'attribut Microsoft Entra ID Mail n'est actuellement pas affiché sur le portail Azure et ne peut être affiché et modifié que via des API ou PowerShell. Bien que l'interface utilisateur vous permette de spécifier une adresse e-mail et une adresse e-mail secondaire, aucune de ces valeurs n'est stockée dans l'attribut Mail. Elles ne peuvent donc pas être utilisées pour le provisionnement vers Cloud Identity ou cloudid_name_short. Ainsi, le mappage des utilisateurs d'une adresse e-mail n'est intéressant que lorsque vous créez et modifiez la plupart de vos utilisateurs dans Active Directory, et non dans Microsoft Entra ID.

Pour mapper des utilisateurs par adresse e-mail, vous devez répondre aux exigences supplémentaires suivantes :

• Les affectations des adresses e-mail doivent être exhaustives. Une adresse e-mail doit être attribuée à tous les utilisateurs soumis à la synchronisation. Il se peut que ce ne soit pas le cas, en particulier lorsque les utilisateurs sont synchronisés à partir d'un annuaire Active Directory sur site, car mail est un attribut utilisateur facultatif dans Active Directory. Les utilisateurs dépourvus d'adresse e-mail dans l'attribut Microsoft Entra ID Mail sont ignorés sans notification pendant la synchronisation.
• Les adresses e-mail doivent être uniques au sein du locataire Microsoft Entra ID. Bien qu'Active Directory ne vérifie pas l'unicité lors de la création des utilisateurs, Microsoft Entra ID détecte les conflits par défaut, ce qui peut entraîner l'échec de la synchronisation des utilisateurs concernés.
• Les domaines utilisés par les adresses e-mail n'ont pas besoin d'être enregistrés dans Microsoft Entra ID, mais ils doivent l'être dans Cloud Identity ou Google Workspace. Cette condition signifie que vous devez avoir accès aux zones DNS respectives pour effectuer la validation du domaine, ce qui exclut l'utilisation d'adresses e-mail de domaines qui ne vous appartiennent pas (comme gmail.com).

Mapper le cycle de vie des utilisateurs

Après avoir défini un mappage entre les utilisateurs Microsoft Entra ID et les utilisateurs dans Cloud Identity ou Google Workspace, vous devez choisir le groupe d'utilisateurs que vous souhaitez provisionner. Reportez-vous à nos bonnes pratiques pour mapper des ensembles d'identité pour savoir comment prendre cette décision.

Si vous ne souhaitez pas provisionner tous les utilisateurs de votre locataire Microsoft Entra ID, vous pouvez activer le provisionnement pour un sous-ensemble d'utilisateurs à l'aide d'affectations d'utilisateurs ou de filtres de champ d'application.

Le tableau suivant récapitule le comportement par défaut du provisionnement Microsoft Entra ID et indique comment l'activation ou la désactivation du provisionnement pour un utilisateur contrôle les actions que Microsoft Entra ID effectue dans Cloud Identity ou Google Workspace.

Provisionnement activé pour le groupe Microsoft Entra ID	État de l'utilisateur dans Cloud Identity ou Google Workspace	Action effectuée dans Microsoft Entra ID	Action effectuée dans Cloud Identity ou Google Workspace
Non	(n'existe pas)	Activer le provisionnement	Créer un utilisateur (*)
Non	Exists (actif)	Activer le provisionnement	Mettre à jour l'utilisateur existant
Non	Exists (suspendu)	Activer le provisionnement	Mettre à jour l'utilisateur existant et conserver sa suspension
Oui	Exists	Modifier l'utilisateur	Mettre à jour l'utilisateur existant
Oui	Exists	Renommer l'UPN/l'adresse e-mail	Modifier l'adresse e-mail principale et conserver l'adresse précédente en tant qu'adresse d'alias
Oui	Exists	Désactiver le provisionnement	Laisser l'utilisateur tel quel
Oui	Exists	Supprimer l'utilisateur de façon réversible	Suspendre les comptes utilisateur
Oui	Exists	Supprimer définitivement l'utilisateur	Suspendre l'utilisateur et ajouter le préfixe del_ à l'adresse e-mail

(*) Si un compte personnel associé à la même adresse e-mail existe, celui-ci est exclu.

Remarque : Si vous activez le provisionnement pour un utilisateur, puis désactivez ce provisionnement, l'utilisateur correspondant dans Cloud Identity ou Google Workspace reste actif. Pour révoquer l'autorisation de l'utilisateur de se connecter et d'accéder aux services Google, vous devez supprimer l'utilisateur dans Microsoft Entra ID ou le désactiver manuellement dans Cloud Identity ou Google Workspace.

Mapper les groupes

Le quatrième facteur à prendre en compte lorsque vous envisagez de fédérer Microsoft Entra ID avec Google Cloud consiste à savoir si les groupes doivent être synchronisés entre Microsoft Entra ID et Google Cloud, et comment les mapper.

Dans Google Cloud, les groupes sont couramment utilisés pour gérer efficacement l'accès entre projets. Plutôt que d'affecter des utilisateurs individuels à des rôles IAM dans chaque projet, vous définissez un ensemble de groupes modélisant les rôles courants au sein de votre organisation. Vous affectez ensuite ces groupes à un ensemble de rôles IAM. Modifier l'appartenance aux groupes vous permet de contrôler l'accès des utilisateurs à un ensemble complet de ressources.

Le mappage de groupes entre Microsoft Entra ID et Google Cloud est facultatif. Une fois le provisionnement des comptes utilisateur configuré, vous pouvez créer et gérer des groupes directement dans Cloud Identity ou Google Workspace, ce qui signifie qu'Active Directory ou Microsoft Entra ID reste le système central pour la gestion des identités, mais pas pour la gestion des accès Google Cloud.

Pour préserver le rôle central d'Active Directory ou de Microsoft Entra ID pour la gestion des identités et des accès, nous vous recommandons de synchroniser les groupes à partir de Microsoft Entra ID plutôt que de les gérer dans Cloud Identity ou Google Workspace. Cette approche vous permet de configurer IAM afin d'exploiter l'appartenance à des groupes dans Active Directory ou Microsoft Entra ID pour contrôler qui a accès aux ressources dans Google Cloud.

Groupes dans Cloud Identity et Google Workspace

Dans Cloud Identity et Google Workspace, il n'existe qu'un seul type de groupe. Les groupes dans Cloud Identity et Google Workspace ne se limitent pas au champ d'application du compte Cloud Identity ou Google Workspace dans lequel ils ont été définis. Au lieu de cela, ils peuvent inclure des utilisateurs issus de différents comptes Cloud Identity ou Google Workspace, être référencés et imbriqués dans d'autres comptes, et être utilisés dans toute organisation Google Cloud.

Comme pour les utilisateurs, Cloud Identity et Google Workspace identifient les groupes par adresse e-mail. L'adresse e-mail ne doit pas nécessairement correspondre à une boîte aux lettres réelle, mais elle doit utiliser l'un des domaines enregistrés pour le compte Cloud Identity correspondant.

Lorsque vous travaillez avec des groupes dans Cloud IAM, vous devez souvent spécifier des groupes par adresse e-mail plutôt que par nom. Il est donc préférable que les groupes aient non seulement un nom significatif, mais également une adresse e-mail pertinente et reconnaissable.

Groupes dans Microsoft Entra ID

Microsoft Entra ID prend en charge plusieurs types de groupes, chacun correspondant à différents cas d'utilisation. Les groupes sont limités à un seul locataire et sont identifiés par un ID d'objet, qui est un identifiant unique généré de manière aléatoire. Les groupes peuvent être imbriqués et peuvent contenir soit des utilisateurs du même locataire, soit des utilisateurs invités depuis d'autres locataires utilisant Azure B2B. Microsoft Entra ID est également compatible avec les groupes dynamiques, dont les membres sont définis automatiquement en fonction d'une requête.

Dans le contexte de l'intégration de Microsoft Entra ID à Cloud Identity ou Google Workspace, deux propriétés de groupe sont particulièrement intéressantes, à savoir l'extension messagerie et la sécurité :

• Un groupe sécurisé peut être utilisé pour gérer l'accès aux ressources dans Microsoft Entra ID. Tout groupe dont la sécurité est activée est donc potentiellement pertinent dans le contexte de Google Cloud.
• Un groupe à extension messagerie possède une adresse e-mail, ce qui est intéressant puisque Cloud Identity et Google Workspace exigent que les groupes soient identifiés par une adresse e-mail.

Dans Microsoft Entra ID, vous pouvez créer des groupes de type Sécurité ou Office 365 (parfois appelés groupes unifiés). Lors de la synchronisation de groupes à partir d'Active Directory sur site ou lors de l'utilisation du type Office 365, vous pouvez également créer des groupes de type Liste de distribution.

Le tableau suivant récapitule les différences entre ces différents types de groupes en ce qui concerne l'extension messagerie ou la sécurité, ainsi que la manière dont ils sont mappés aux types de groupe Active Directory, en se basant sur une configuration Microsoft Entra ID Connect par défaut :

Source	Type de groupe Active Directory	Type de groupe Microsoft Entra ID	Extension messagerie	Sécurité
Microsoft Entra ID	-	Groupe Office 365	Toujours	Facultatif
Microsoft Entra ID	-	Groupe de sécurité	Facultatif	Toujours
sur site	Groupe de sécurité (avec e-mail)	Groupe de sécurité	Oui	Oui
sur site	Groupe de sécurité (sans e-mail)	Groupe de sécurité	Non	Oui
sur site	Liste de distribution (avec e-mail)	Liste de distribution	Oui	Non
sur site	Liste de distribution (sans e-mail)	(ignoré par Microsoft Entra ID Connect)

Contrairement aux utilisateurs, Microsoft Entra ID nécessite que les adresses e-mail attribuées aux groupes utilisent un domaine qui a été enregistré en tant que domaine personnalisé dans Microsoft Entra ID. Cette exigence entraîne le comportement par défaut suivant :

• Si un groupe dans Active Directory utilise une adresse e-mail qui utilise un domaine précédemment enregistré dans Microsoft Entra ID, l'adresse e-mail est correctement conservée lors de la synchronisation avec Microsoft Entra ID.
• Si un groupe dans Active Directory utilise une adresse e-mail qui n'a pas été enregistrée dans Microsoft Entra ID, celui-ci génère automatiquement une nouvelle adresse e-mail lors de la synchronisation. Cette adresse e-mail utilise le domaine par défaut du locataire. Si votre locataire utilise le domaine initial comme domaine par défaut, l'adresse e-mail obtenue sera au format [name]@[tenant].onmicrosoft.com.
• Si vous créez un groupe Office 365 dans Microsoft Entra ID, ce dernier génère aussi automatiquement une adresse e-mail qui utilise le domaine par défaut du locataire.

Mapper des identités de groupe

Le mappage des groupes Microsoft Entra ID avec les groupes Cloud Identity ou Google Workspace requiert un identifiant commun, qui doit être une adresse e-mail. Du côté de Microsoft Entra ID, cette exigence vous laisse deux options:

• Vous pouvez utiliser l'adresse e-mail d'un groupe dans Microsoft Entra ID et la mapper avec une adresse e-mail Cloud Identity ou Google Workspace.
• Vous pouvez générer une adresse e-mail à partir du nom du groupe dans Microsoft Entra ID et mapper l'adresse résultante avec une adresse e-mail dans Cloud Identity ou Google Workspace.

Mapper par adresse e-mail

Le mappage de groupes par adresse e-mail est le choix le plus évident, mais il implique de respecter plusieurs exigences :

• Tous les groupes soumis à la synchronisation doivent posséder une adresse e-mail. En pratique, cela signifie que vous ne pouvez synchroniser que des groupes à extension messagerie. Les groupes sans adresse e-mail sont ignorés lors du provisionnement.
• Les adresses e-mail doivent être uniques au sein du locataire. Étant donné que Microsoft Entra ID n'impose pas l'unicité des adresses, vous devrez peut-être mettre en œuvre des règles ou des contrôles personnalisés.
• Les domaines utilisés par les adresses e-mail doivent être enregistrés à la fois dans Microsoft Entra ID et dans Cloud Identity ou Google Workspace. La synchronisation échouera pour tous les groupes dont les adresses e-mail utilisent des domaines non enregistrés dans Cloud Identity ou Google Workspace, y compris le domaine tenant.onmicrosoft.com.

Si tous les groupes concernés répondent à ces critères, identifiez les domaines utilisés par ces adresses e-mail et vérifiez qu'ils font bien partie de la liste des domaines DNS enregistrés dans Cloud Identity ou Google Workspace.

Mapper par nom

Répondre aux critères requis pour mapper des groupes par adresse e-mail peut s'avérer difficile, en particulier si un grand nombre des groupes de sécurité que vous souhaitez provisionner dans Cloud Identity ou Google Workspace ne sont pas à extension messagerie. Dans ce cas, il peut être préférable de générer automatiquement une adresse e-mail à partir du nom complet du groupe.

La génération d'une adresse e-mail présente deux difficultés :

1. Une adresse e-mail dérivée du nom d'un groupe peut entrer en conflit avec l'adresse e-mail d'un utilisateur.
2. Microsoft Entra ID n'impose pas l'unicité des noms de groupe. Si plusieurs groupes de votre locataire Microsoft Entra ID partagent le même nom, les adresses e-mail dérivées de ce nom entreront en conflit, et un seul groupe sera donc synchronisé correctement.

Vous pouvez résoudre la première difficulté en utilisant pour l'adresse e-mail générée un domaine différent de tous les domaines utilisés par les utilisateurs. Par exemple, si tous vos utilisateurs utilisent des adresses e-mail du domaine example.com, vous pouvez choisir groups.example.com pour tous les groupes. L'enregistrement de sous-domaines dans Cloud Identity ou Google Workspace ne nécessite pas de validation de domaine. La zone DNS groups.example.com n'a donc pas besoin d'exister.

La deuxième difficulté, qui concerne la duplication des noms de groupe, ne peut se résoudre que techniquement, en générant l'adresse e-mail du groupe à partir de l'ID d'objet. Comme les noms de groupe résultants sont plutôt difficiles à lire et à manipuler, il est préférable d'identifier et de renommer les noms de groupe en double dans Microsoft Entra ID avant de configurer le provisionnement vers Cloud Identity ou Google Workspace.

Mapper le cycle de vie du groupe

Après avoir défini un mappage entre les groupes Microsoft Entra ID et les groupes dans Cloud Identity ou Google Workspace, vous devez choisir le groupe d'utilisateurs que vous souhaitez provisionner. Comme pour les utilisateurs, vous pouvez activer le provisionnement pour un sous-ensemble de groupes à l'aide d'affectations de groupes ou de filtres de champ d'application.

Le tableau suivant récapitule le comportement par défaut du provisionnement Microsoft Entra ID et indique comment l'activation ou la désactivation du provisionnement pour un groupe contrôle les actions que Microsoft Entra ID effectue dans Cloud Identity ou Google Workspace.

Provisionnement activé pour le groupe Microsoft Entra ID	État du groupe dans Cloud Identity ou Google Workspace	Action effectuée dans Microsoft Entra ID	Action effectuée dans Cloud Identity ou Google Workspace
Non	(n'existe pas)	Activer le provisionnement	Créer un groupe
Non	Exists	Activer le provisionnement	Ajouter un membre et conserver tous les membres existants
Oui	Exists	Renommer le groupe	Renommer le groupe
Oui	Exists	Modifier la description	Mettre à jour la description
Oui	Exists	Ajouter un membre	Ajouter un membre et conserver tous les membres existants
Oui	Exists	Supprimer le membre	Supprimer le membre
Oui	Exists	Désactiver le provisionnement	Laisser le groupe tel quel (y compris ses membres)
Oui	Exists	Supprimer le groupe	Laisser le groupe tel quel (y compris ses membres)

Remarque : Lorsque vous supprimez un groupe dans Microsoft Entra ID, celui-ci ne propage pas la suppression dans Cloud Identity ou Google Workspace. De même, si vous activez le provisionnement pour un groupe, puis désactivez ce provisionnement, le groupe correspondant dans Cloud Identity ou Google Workspace reste actif. Ce comportement peut conduire les utilisateurs à conserver par inadvertance leurs droits d'accès dans Google Cloud. Pour éviter cela, supprimez d'abord tous les membres d'un groupe, attendez que les modifications soient appliquées, puis supprimez le groupe dans Microsoft Entra ID ou désactivez le provisionnement pour ce groupe dans Microsoft Entra ID.

Étapes suivantes

• Consultez les bonnes pratiques pour planifier des comptes et des organisations ainsi que les bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
• Découvrez comment configurer le provisionnement et l'authentification unique entre Microsoft Entra ID et Cloud Identity.
• Découvrez les bonnes pratiques de gestion des comptes de super-administrateur.