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

Last reviewed 2023-02-27 UTC

Cet article 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.

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

Fédérer Cloud Identity avec 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.

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.

Structure logique de Microsoft Entra ID

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.

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

Mappage des locataires Microsoft Entra ID

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.

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

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

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.

Utiliser des domaines DNS dans Google Cloud.

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 nom alternatif pour un autre domaine. 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 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.

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.

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

Écran de connexion demandant 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).

Écran de connexion AD FS

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 (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 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 (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 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.<