Fédérer Google Cloud avec Azure Active Directory

Cet article explique comment configurer Cloud Identity ou Google Workspace pour utiliser Azure AD comme fournisseur d'identité et source des identités.

Cet article compare la structure logique d'Azure AD à celle utilisée par Cloud Identity et Google Workspace, et explique comment mapper des locataires, des domaines, des utilisateurs et des groupes Azure AD.

Mettre en œuvre 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 Azure AD. 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 Azure AD.

Fédérer Cloud Identity avec Azure AD

La configuration de la fédération entre Azure AD et Cloud Identity ou Google Workspace implique deux étapes :

  • Provisionnement des comptes utilisateur : les utilisateurs et les groupes concernés sont régulièrement synchronisés entre Azure AD et Cloud Identity ou Google Workspace. Ce processus garantit que lorsque vous créez un utilisateur dans Azure AD ou que vous synchronisez un nouvel utilisateur d'Active Directory avec Azure AD, 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 Azure AD 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 à Active Directory à l'aide du protocole SAML (Security Assertion Markup Language). Selon votre configuration Azure AD, Azure AD 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 à Azure AD é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 Azure AD ou AD FS.

Structure logique d'Azure AD

Lorsque vous utilisez Azure, vous utilisez un ou plusieurs locataires Azure AD (également appelés annuaires). Les locataires Azure AD 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 Azure AD 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.

Structure logique d'Azure AD

Une entreprise peut gérer plusieurs locataires Azure AD. 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 Azure AD.

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.

Structure logique de Google Cloud

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 Azure AD et Google Cloud

Malgré certaines similitudes entre la structure logique d'Azure AD et celle de Google Cloud, il n'existe pas de mappage unique entre les deux structures à même d'assurer des performances semblables 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 Azure AD 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 Azure AD, 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 Azure AD n'a que peu d'importance.

Mapper des locataires Azure AD

Locataire unique

Si vous utilisez un seul locataire Azure AD, 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.

Mappage d'un locataire sur un seul compte Cloud Identity

Locataires multiples

Dans les grandes organisations, il n'est pas rare d'avoir plusieurs locataires Azure AD. 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.

Bien qu'il soit possible de provisionner des utilisateurs et des groupes de plusieurs locataires Azure AD vers un seul compte Cloud Identity ou Google Workspace, il est actuellement impossible de configurer l'authentification unique de manière à ce qu'elle fonctionne pour les utilisateurs de plusieurs locataires Azure AD. Si vous utilisez plusieurs locataires Azure AD, vous devez 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.

Organisation fédérée avec plusieurs forêts Active Directory

Utilisateurs externes

Azure AD B2B vous permet de convier des utilisateurs externes en tant qu'invités sur votre locataire Azure AD. Un utilisateur est créé pour chaque invité, auquel Azure AD attribue automatiquement un UPN. L'UPN généré par Azure AD 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 Azure AD 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 Azure AD 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 Azure AD différent.

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 Azure AD et pour Cloud Identity et Google Workspace. Lorsque vous envisagez de fédérer Azure AD et Google Cloud, le deuxième facteur à prendre en compte est le mode de partage ou de mappage des domaines DNS entre Active Directory 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.

Utiliser des domaines DNS dans GCP

Lorsque vous créez un compte Google Workspace ou Cloud Identity, vous créez un annuaire 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 (johndoe@example.com et johndoe@secondary.example.com) 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 domaine alternatif pour le domaine principal. Autrement dit, johndoe@example.com et johndoe@alias.example.com font référence au même utilisateur si alias.example.com est configuré en tant que domaine d'alias. Un domaine d'alias ne peut fournir un nom alternatif qu'au domaine principal : il n'est pas possible d'ajouter des domaines d'alias pour les domaines secondaires.

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.

Utiliser des domaines DNS dans Azure AD

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

  1. Domaines initiaux : lorsque vous créez un locataire Azure AD, 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 : Azure AD 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 Azure AD. 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 Azure AD et un compte Cloud Identity ou Google Workspace peuvent utiliser les mêmes domaines DNS. 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 Azure AD et Cloud Identity ou Google Workspace.

Mapper des utilisateurs

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

Le mappage d'utilisateurs Azure AD et d'utilisateurs Cloud Identity ou Google Workspace requiert deux informations pour chaque utilisateur :

  1. Un identifiant unique et stable que vous pouvez utiliser lors de la synchronisation pour déterminer quel utilisateur Azure AD 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, Azure AD 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.

Mapper des utilisateurs 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 Azure AD, il est alors redirigé vers l'écran de connexion d'Azure AD.

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

Écran de connexion demandant un UPN

Si le locataire Azure AD 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).

Écran de connexion AD FS

Si l'adresse e-mail utilisée pour Cloud Identity ou Google Workspace, l'UPN utilisé par Azure AD 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 (johndoe@example.com), 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 des utilisateurs par UPN

Du point de vue de l'expérience utilisateur, le mappage des UPN Azure AD à 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 : Azure AD garantit l'unicité et vous permet ainsi d'éviter les risques de conflits de noms.

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

  • Les UPN Azure AD 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 Azure AD doivent comporter un domaine personnalisé comme suffixe ([user]@[custom-domain]). Les UPN utilisant le domaine initial Azure AD ([user]@[tenant].onmicrosoft.com) 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 Azure AD 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 Azure AD, 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 Azure AD 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. Azure AD Connect synchronise ensuite cette valeur avec l'attribut Mail dans Azure AD. Azure AD 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 Azure AD 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 Azure AD.

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 Azure AD Mail sont ignorés sans notification pendant la synchronisation.
  • Les adresses e-mail doivent être uniques au sein du locataire Azure AD. Bien qu'Active Directory ne vérifie pas l'unicité lors de la création des utilisateurs, Azure AD Connect 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 Azure AD, mais ils doivent l'être dans Cloud Identity ou cloudid_name_short. 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 Azure AD 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 Azure AD, 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 Azure AD et indique comment l'activation ou la désactivation du provisionnement pour un groupe contrôle les actions qu'Azure AD effectue dans Cloud Identity ou Google Workspace.

Provisionnement activé pour l'utilisateur Azure AD État de l'utilisateur dans Cloud Identity/Google Workspace Action effectuée dans Azure AD Action effectuée dans Cloud Identity/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.

Mapper des groupes

Le quatrième facteur à prendre en compte lorsque vous envisagez de fédérer Active Directory et Google Cloud est la synchronisation et le mode de mappage des groupes entre Active Directory et Google Cloud.

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 Azure AD 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 Azure AD 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 d'Azure AD pour la gestion des identités et des accès, nous vous recommandons de synchroniser les groupes à partir d'Azure AD 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 Azure AD 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 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 Azure AD

Azure AD 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. Azure AD 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 d'Azure AD à 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 Azure AD. 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 Azure AD, 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 Azure AD Connect par défaut :

Source Type de groupe Active Directory Type de groupe Azure AD Extension messagerie Sécurité
Azure AD - Groupe Office 365 Toujours Facultatif
Azure AD - 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 Azure AD Connect)

Contrairement aux utilisateurs, Azure AD requiert que les adresses e-mail affectées à des groupes utilisent un domaine qui a été enregistré en tant que domaine personnalisé dans Azure AD. Cette condition 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 Azure AD, l'adresse e-mail est correctement conservée lors de la synchronisation avec Azure AD.
  • Si un groupe dans Active Directory utilise une adresse e-mail qui n'a pas été enregistrée dans Azure AD, Azure AD 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 Azure AD, Azure AD génère également automatiquement une adresse e-mail qui utilise le domaine par défaut du locataire.

Mapper des identités de groupe

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

  • Vous pouvez utiliser l'adresse e-mail d'un groupe dans Azure AD 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 Azure AD et mapper l'adresse résultante avec une adresse e-mail dans Cloud Identity ou Google Workspace.

Mappage 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. Comme Azure AD 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 Azure AD et dans Cloud Identity/Google Workspace. La synchronisation échouera pour tous les groupes dont les adresses e-mail utilisent des domaines non enregistrés dans Cloud Identity/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.

Mappage 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. Azure AD n'impose pas l'unicité des noms de groupe. Si plusieurs groupes de votre locataire Azure AD 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 Azure AD 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 Azure AD et les groupes dans Cloud Identity ou Google Workspace, vous devez choisir l'ensemble de groupes que vous souhaitez provisionner. Comme pour les utilisateurs, vous pouvez activer le provisionnement pour un sous-ensemble de groupes à 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 Azure AD et indique comment l'activation ou la désactivation du provisionnement pour un groupe contrôle les actions qu'Azure AD effectue dans Cloud Identity ou Google Workspace.

Provisionnement activé pour le groupe Azure AD État du groupe dans Cloud Identity/Google Workspace Action effectuée dans Azure AD Action effectuée dans Cloud Identity/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)

Étapes suivantes