Fédérer Google Cloud avec Active Directory

Ce document explique comment configurer Cloud Identity ou Google Workspace pour utiliser Active Directory comme fournisseur d'identité et source faisant autorité.

Ce document compare la structure logique d'Active Directory à celle de Cloud Identity et de Google Workspace, et explique comment mapper les forêts, les domaines, les utilisateurs et les groupes Active Directory. Le document fournit également un organigramme qui vous permet de déterminer la meilleure approche de mappage pour votre scénario.

Dans ce document, nous partons du principe que vous connaissez Active Directory.

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

La configuration d'une fédération entre Active Directory et Cloud Identity ou Google Workspace repose sur deux éléments :

• Provisionnement des utilisateurs : les utilisateurs et les groupes concernés sont régulièrement synchronisés entre Active Directory et Cloud Identity ou Google Workspace. Ce processus garantit que lorsque vous créez un utilisateur dans Active Directory, il peut ê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 Active Directory sont répliquées dans Google Cloud, mais pas l'inverse. Par ailleurs, le provisionnement n'inclut pas les mots de passe. Dans une configuration fédérée, Active Directory reste le seul système à gérer ces informations d'identification.

• 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). Cette délégation garantit que seul Active Directory gère les identifiants de l'utilisateur et que toutes les règles et tous les mécanismes d'authentification multifacteurs (MFA) applicables sont effectivement mis en œuvre. Toutefois, pour qu'une connexion réussisse, l'utilisateur concerné doit avoir été provisionné au préalable.

Pour mettre en œuvre la fédération, vous pouvez utiliser les outils suivants :

• Google Cloud Directory Sync (GCDS) est un outil gratuit fourni par Google qui met en œuvre le processus de synchronisation. GCDS communique avec Google Cloud via SSL (Secure Sockets Layer) et s'exécute généralement dans l'environnement informatique existant.
• Les services AD FS (Active Directory Federation Services) sont fournis par Microsoft avec Windows Server. AD FS vous permet d'utiliser Active Directory pour l'authentification fédérée. AD FS s'exécute généralement dans l'environnement informatique existant.

Étant donné que les API Google Cloud sont disponibles publiquement et que SAML est une norme ouverte, de nombreux outils sont disponibles pour mettre en œuvre la fédération. Ce document se concentre sur l'utilisation de GCDS et d'AD FS.

Structure logique d'Active Directory

Dans une infrastructure Active Directory, le composant de premier niveau est la forêt. Celle-ci sert de conteneur à un ou plusieurs domaines et tire son nom du domaine racine de forêt. Les domaines d'une forêt Active Directory se font mutuellement confiance, ce qui permet aux utilisateurs authentifiés dans un domaine d'accéder aux ressources d'un autre domaine. À moins d'être connectées à l'aide d'approbations interforêts, des forêts distinctes ne se font pas confiance par défaut : ainsi, les utilisateurs authentifiés dans une forêt ne peuvent pas accéder aux ressources hébergées dans une autre forêt.

Les domaines Active Directory sont des conteneurs pour la gestion des ressources et sont considérés comme des limites au niveau de l'administration. Rassembler plusieurs domaines dans une même forêt représente un moyen de simplifier l'administration ou de structurer les ressources, mais les domaines d'une forêt ne constituent pas des limites de sécurité.

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. Les organisations, les dossiers et les projets ont donc une fonction semblable à celle des domaines Active Directory.

Active Directory considère les utilisateurs comme des ressources. La gestion et l'authentification des utilisateurs sont donc liées aux domaines. En revanche, Google Cloud ne gère pas les utilisateurs d'une organisation, à l'exception des comptes de service. À la place, Google Cloud s'appuie sur Cloud Identity ou Google Workspace pour gérer les utilisateurs.

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 Active Directory et Google Cloud

Malgré certaines similitudes entre la structure logique d'Active Directory 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 domaines et des forêts 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.

Cartographier des forêts

Dans les grandes entreprises en particulier, il est fréquent d'utiliser plusieurs domaines Active Directory pour gérer les identités et les accès au sein de l'entreprise. Lorsque vous envisagez de fédérer Active Directory et Google Cloud, le premier facteur à prendre en compte est la topologie de votre infrastructure Active Directory.

Forêt unique, domaine unique

Lorsqu'une forêt ne comprend qu'un seul domaine, vous pouvez mapper la totalité de la forêt Active Directory sur un seul compte Cloud Identity ou Google Workspace. Ce compte constitue ensuite la base d'une organisation Google Cloud unique que vous pouvez utiliser pour gérer vos ressources Google Cloud.

Dans un environnement présentant un domaine unique, les contrôleurs de domaine et les serveurs de catalogues globaux fournissent un accès à tous les objets gérés dans Active Directory. Dans la plupart des cas, vous pouvez exécuter une seule instance de GCDS pour synchroniser les comptes utilisateur et les groupes avec Google Cloud, ainsi que pour gérer une seule instance ou un seul parc AD FS gérant l'authentification unique.

Forêt unique, domaines multiples

Lorsqu'une forêt comporte plusieurs domaines Active Directory, vous pouvez les organiser suivant une ou plusieurs arborescences de domaines. Dans les deux cas, vous pouvez mapper la totalité de la forêt sur un seul compte Cloud Identity ou Google Workspace. Ce compte constitue ensuite la base d'une organisation Google Cloud unique que vous pouvez utiliser pour gérer vos ressources Google Cloud.

Dans un environnement multidomaine, il existe une différence entre les informations pouvant être extraites d'un contrôleur de domaine et celles pouvant être obtenues à partir d'un serveur de catalogue global. Tandis que les contrôleurs de domaine ne diffusent que des données sur leur domaine local, les serveurs de catalogues globaux permettent d'accéder aux informations concernant tous les domaines de la forêt. Il est important de noter que les données diffusées par les serveurs de catalogues globaux sont partielles et ne présentent pas certains attributs LDAP. Cette limitation peut affecter la manière dont vous configurez GCDS pour synchroniser les groupes.

Suivant la façon dont vous envisagez de mapper les groupes, fédérer une forêt multidomaine avec Google Cloud nécessite une ou plusieurs instances GCDS, mais une seule instance ou un seul parc AD FS pour gérer l'authentification unique.

Forêts multiples avec approbation interforêt

Dans les grandes organisations, il n'est pas rare d'avoir plusieurs forêts Active Directory, qui sont souvent le résultat d'une fusion ou d'une acquisition. Vous pouvez combiner ces forêts en établissant une approbation réciproque entre forêts afin que les utilisateurs puissent partager des ressources et y accéder en s'affranchissant des limites de leur propre forêt.

Si toutes les forêts présentent une relation d'approbation bidirectionnelle avec une autre forêt, vous pouvez mapper l'environnement tout entier sur un seul compte Cloud Identity ou Google Workspace. Ce compte constitue ensuite la base d'une organisation Google Cloud unique que vous pouvez utiliser pour gérer vos ressources Google Cloud.

Bien que les serveurs de catalogues globaux donnent accès aux données sur plusieurs domaines, leur champ d'application est limité à une seule forêt. Ainsi, dans un environnement comportant plusieurs forêts, vous devez interroger plusieurs contrôleurs de domaine ou serveurs de catalogues globaux pour obtenir, par exemple, la liste complète des utilisateurs. En raison de cette limitation, fédérer un environnement à plusieurs forêts avec Google Cloud nécessite au moins une instance GCDS par forêt. Les approbations interforêts permettent d'étendre l'authentification des utilisateurs au-delà des limites de leur forêt, de sorte qu'une seule instance ou un seul parc AD FS suffit à gérer l'authentification unique.

Si votre environnement s'étend sur plusieurs forêts sans approbation interforêt, mais que tous les domaines Active Directory concernés par la fédération avec Google Cloud sont connectés via des approbations externes, les mêmes considérations s'appliquent.

Forêts multiples sans approbation interforêt

Dans l'environnement illustré ici, il est impossible de s'authentifier ou d'accéder aux ressources au-delà des limites de la forêt. Il est également impossible pour une seule instance ou un seul parc AD FS de traiter des requêtes d'authentification unique pour les utilisateurs de l'ensemble des forêts.

Par conséquent, il n'est pas possible de mapper plusieurs forêts sur un seul compte Cloud Identity ou Google Workspace sans approbation interforêt. Dans ce contexte, chaque forêt doit être mappée sur un compte Cloud Identity ou Google Workspace distinct, ce qui implique d'exécuter au moins une instance GCDS et un serveur ou parc AD FS par forêt.

Dans Google Cloud, une organisation distincte est créée pour chaque compte Cloud Identity ou Google Workspace. Dans la plupart des cas, il n'est pas nécessaire de gérer plusieurs organisations distinctes. Vous pouvez 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.

Mapper des domaines DNS

Le DNS joue un rôle crucial à la fois dans Active Directory et pour Cloud Identity et Google Workspace. Lorsque vous envisagez de fédérer Active Directory et Google Cloud, le deuxième facteur à prendre en compte consiste à savoir comment partager ou mapper des domaines DNS entre Active Directory et Google Cloud.

Utilisation des domaines DNS dans Active Directory

Au sein d'une forêt Active Directory, les domaines DNS sont utilisés dans différents contextes :

• Domaines DNS Active Directory : chaque domaine Active Directory correspond à un domaine DNS. Ce domaine peut être global, comme corp.example.com, ou il peut s'agir d'un nom de domaine local, tel que corp.local ou corp.internal.
• Domaines d'échange de courrier (MX) : les adresses e-mail utilisent un domaine DNS. Dans certains cas, ce domaine est identique au domaine DNS Active Directory, mais le plus souvent, c'est un domaine différent et souvent plus court, tel que example.com, qui est utilisé. Idéalement, les utilisateurs d'Active Directory disposent de l'adresse e-mail associée à l'attribut facultatif mail.
• Domaines de suffixe UPN : ces domaines sont utilisés pour les noms d'utilisateurs principaux (UPN, User Principal Names). Par défaut, le domaine DNS Active Directory correspondant au domaine de l'utilisateur est utilisé pour créer un UPN. Pour un utilisateur john du domaine corp.example.com, l'UPN par défaut est donc john@corp.example.com. Toutefois, vous pouvez configurer une forêt pour utiliser en tant que suffixes UPN des domaines DNS supplémentaires qui ne correspondent ni aux domaines DNS Active Directory, ni aux domaines MX. Les UPN sont facultatifs et sont stockés dans le champ userPrincipalName de l'utilisateur.
• Domaines de points de terminaison : les serveurs accessibles publiquement, comme les serveurs AD FS, se voient généralement attribuer un nom DNS du type login.external.example.com. Le domaine utilisé à ces fins peut chevaucher le domaine MX, le suffixe UPN ou le domaine DNS Active Directory, ou il peut s'agir d'un domaine entièrement différent.

Utiliser des domaines DNS dans Google Cloud

La fonctionnalité Google Sign-In, sur laquelle 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 (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.

Afin d'activer la synchronisation entre les annuaires, un mappage est nécessaire entre les domaines Active Directory et les domaines utilisés par Cloud Identity ou Google Workspace. La détermination du mappage approprié dépend de votre utilisation d'Active Directory et nécessite un examen plus approfondi de la façon dont les utilisateurs sont identifiés dans une forêt Active Directory et de la façon dont ils peuvent être mappés sur Cloud Identity ou Google Workspace.

Map users (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 comptes utilisateur entre Active Directory et Cloud Identity ou Google Workspace.

Identifier des utilisateurs dans Active Directory

En interne, Active Directory utilise deux identifiants pour identifier les utilisateurs de manière unique :

• objectGUID : cet ID unique est généré à la création d'un utilisateur et ne change jamais.
• objectSID : l'identifiant de sécurité ou SID est utilisé pour tous les contrôles d'accès. Bien que cet ID soit unique et stable au sein d'un domaine, un utilisateur qui est déplacé vers un autre domaine de la forêt peut se voir attribuer un nouveau SID.

Aucun de ces ID n'est pertinent pour les utilisateurs. Active Directory propose donc deux méthodes permettant d'identifier facilement les utilisateurs :

• UPN (userPrincipalName) : le moyen privilégié pour identifier un utilisateur est l'UPN. Les UPN suivent le format RFC 822 pour les adresses e-mail, et ils sont créés en combinant le nom d'utilisateur avec un domaine de suffixe UPN, comme dans johndoe@corp.example.com. Bien qu'ils constituent la méthode privilégiée pour identifier les utilisateurs, les UPN sont facultatifs. Par conséquent, certains utilisateurs de votre forêt Active Directory peuvent ne pas en avoir.

  Il est généralement considéré comme une bonne pratique d'utiliser des adresses e-mail valides comme noms UPN, mais c'est une pratique qu'Active Directory n'impose pas.

• Nom de connexion antérieur à Windows 2000 (sAMAccountName) : ce nom combine le nom de domaine NetBIOS et le nom d'utilisateur au format domain<var>user (par exemple, corp\johndoe). Bien que ces noms soient considérés comme anciens, ils sont encore couramment utilisés et constituent le seul identifiant obligatoire d'un utilisateur.

Il est à noter qu'Active Directory n'utilise pas l'adresse e-mail de l'utilisateur (mail) pour l'identification des utilisateurs. Par conséquent, ce champ n'est ni obligatoire, ni nécessairement unique au sein d'une forêt.

Tous ces identifiants peuvent être modifiés à tout moment.

Associez les identités des utilisateurs

Mapper des utilisateurs Active Directory avec des utilisateurs Cloud Identity ou Google Workspace requiert deux éléments d'information pour chaque utilisateur :

• Un identifiant unique et stable que vous pouvez utiliser lors de la synchronisation pour déterminer quel utilisateur Active Directory correspond à quel utilisateur dans Cloud Identity ou Google Workspace. Du côté AD, l'identifiant objectGUID est parfaitement adapté à cet usage.
• Une adresse e-mail dont la partie "domaine" correspond à un domaine principal, secondaire ou d'alias dans Cloud Identity ou Google Workspace. Étant donné que cette adresse e-mail sera utilisée partout dans Google Cloud, vous devez vous assurer qu'elle ait un sens. Dériver une adresse de l'identifiant objectGUID n'est pas pratique, comme c'est le cas pour toutes les adresses e-mail générées automatiquement.

Pour un utilisateur Active Directory, deux champs permettent de fournir une adresse e-mail Cloud Identity ou Google Workspace : userPrincipalName et mail.

Mapper suivant le nom d'utilisateur principal

L'utilisation du champ userPrincipalName nécessite que deux critères soient remplis pour tous les utilisateurs soumis à la synchronisation :

• Les noms principaux d'utilisateur (UPN) doivent être des adresses e-mail valides. Tous les domaines utilisés en tant que suffixes UPN doivent également être des domaines MX et doivent être configurés de manière à ce que tout e-mail envoyé à l'UPN d'un utilisateur soit transmis à sa boîte de réception.

• Les affectations UPN doivent être exhaustives. Tous les utilisateurs soumis à la synchronisation doivent disposer d'un UPN. La commande PowerShell suivante vous permet d'identifier les utilisateurs dépourvus d'UPN :

  Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

Si ces deux critères sont remplis, vous pouvez mapper en toute sécurité les noms UPN aux adresses e-mail Cloud Identity ou Google Workspace. Vous pouvez utiliser l'un des suffixes UPN en tant que domaine principal dans Cloud Identity ou Google Workspace et ajouter tout autre suffixe UPN en tant que domaine secondaire.

Si l'un des critères n'est pas respecté, vous pouvez toujours mapper des UPN sur des adresses e-mail Cloud Identity ou Google Workspace, avec les mises en garde suivantes :

• Si les UPN ne sont pas des adresses e-mail valides, les utilisateurs risquent de ne pas recevoir les e-mails de notification envoyés par Google Cloud, ce qui pourrait leur faire manquer des informations importantes.
• Les utilisateurs sans UPN sont ignorés lors de la synchronisation.
• Vous pouvez configurer la synchronisation pour remplacer le suffixe UPN par un autre domaine. Toutefois, si vous utilisez plusieurs suffixes UPN au sein d'une forêt, cette approche peut créer des doublons car tous les suffixes UPN se verront remplacés par un seul et même domaine. En cas de doublons, un seul utilisateur peut être synchronisé.

Utiliser les noms UPN pour mapper les utilisateurs présente un avantage majeur : l'unicité des UPN est garantie au sein d'une forêt, et ils utilisent un ensemble organisé de domaines, ce qui permet d’éviter les éventuels problèmes de synchronisation.

Mapper par adresse e-mail

L'utilisation du champ mail nécessite que les critères suivants soient remplis pour tous les utilisateurs soumis à la synchronisation :

• Les affectations des adresses e-mail doivent être exhaustives. Le champ mail doit être renseigné pour tous les utilisateurs soumis à la synchronisation. La commande PowerShell suivante vous permet d'identifier les utilisateurs pour lesquels ce n'est pas le cas :

  Get-ADUser -LDAPFilter "(!mail=*)"

• Les adresses e-mail doivent utiliser un ensemble de domaines organisés, qui vous appartiennent tous. Si certains de vos utilisateurs utilisent des adresses e-mail faisant référence à des sociétés partenaires ou à des fournisseurs de messagerie grand public, celles-ci ne peuvent pas être utilisées.

• Toutes les adresses e-mail doivent être uniques au sein de la forêt. Comme Active Directory n'impose pas l'unicité, vous pouvez être amené à mettre en place des contrôles ou des règles personnalisés.

Si tous les utilisateurs concernés répondent à ces critères, vous pouvez identifier tous les domaines utilisés par ces adresses e-mail et les utiliser comme domaines principal et secondaire dans Cloud Identity ou Google Workspace.

Si l'un des critères n'est pas respecté, vous pouvez toujours mapper des adresses e-mail sur Cloud Identity ou Google Workspace, avec les mises en garde suivantes :

• Lors de la synchronisation, les utilisateurs sans adresse e-mail seront ignorés, de même que les utilisateurs qui disposent d'adresses e-mail utilisant des domaines non associés au compte Cloud Identity ou Google Workspace.
• Lorsque deux utilisateurs partagent la même adresse e-mail, seul l'un d'eux est synchronisé.
• Vous pouvez configurer la synchronisation pour remplacer le domaine des adresses e-mail par un autre domaine. Ce processus est susceptible de créer des doublons, auquel cas un seul utilisateur est synchronisé.

Mapper les groupes

Le quatrième facteur à prendre en compte lorsque vous envisagez de fédérer Active Directory avec Google Cloud consiste à savoir si les groupes doivent être synchronisés entre Active Directory 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 qui modélisent des rôles courants au sein de votre organisation, puis attribuez 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.

Active Directory distingue deux types de groupes : les groupes de distribution et les groupes de sécurité. Les groupes de distribution sont utilisés pour gérer les listes de diffusion. La synchronisation des groupes de distribution est pertinente lorsque vous effectuez une migration de Microsoft Exchange vers Google Workspace de sorte que GCDS puisse gérer les groupes de distribution standards et dynamiques. Toutefois, les groupes de distribution ne sont pas une préoccupation en termes de gestion de l'authentification et des accès pour Google Cloud. Cette discussion se concentre donc exclusivement sur les groupes de sécurité.

Le mappage des groupes entre Active Directory et Google Cloud est facultatif. Une fois que vous avez configuré le provisionnement des utilisateurs, vous pouvez créer et gérer des groupes directement dans Cloud Identity ou Google Workspace. Cela signifie qu'Active Directory demeure le système central pour la gestion des identités, mais pas pour la gestion des accès. Pour qu'Active Directory demeure le système central pour la gestion des identités et des accès, nous vous recommandons de synchroniser les groupes de sécurité à partir d'Active Directory 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 pour contrôler qui a accès aux ressources dans Google Cloud.

Groupes de sécurité dans Active Directory

Les groupes de sécurité jouent un rôle fondamental dans la sécurité Windows et la gestion des accès avec Active Directory. Ce rôle est facilité par l'existence de trois types de groupes Active Directory différents : les groupes locaux à un domaine, les groupes globaux et les groupes universels.

Groupes locaux à un domaine

Ces groupes n'ont de sens qu'au sein d'un seul domaine et ils ne peuvent pas être référencés dans d'autres domaines. Étant donné que la liste de leurs membres n'a pas besoin d'être répliquée au sein de la forêt, les groupes locaux à un domaine sont les plus souples vis-à-vis des types de membres qu'ils peuvent inclure.

Groupes globaux

Ces groupes sont transmis aux autres domaines qui peuvent y faire référence. Toutefois, leur liste de membres n'est pas répliquée. Cette limitation restreint les types de membres qui peuvent être inclus dans ces groupes. Les groupes globaux ne peuvent inclure que des utilisateurs et d'autres groupes globaux appartenant au même domaine.

Groupes universels

Ces groupes, ainsi que leurs listes de membres, sont répliqués au sein de la forêt. Ils peuvent donc être référencés dans d'autres domaines et peuvent inclure non seulement des utilisateurs et d'autres groupes universels, mais également des groupes globaux de tous les domaines.

Si votre forêt Active Directory ne contient qu'un seul domaine, vous pouvez synchroniser les trois types de groupes de sécurité à l'aide de GCDS. Si votre forêt Active Directory utilise plusieurs domaines, le type d'un groupe détermine s'il peut être synchronisé avec Cloud Identity ou Google Workspace et de quelle manière.

Étant donné que les groupes locaux à un domaine et les groupes globaux ne sont pas intégralement répliqués au sein d'une forêt, les serveurs de catalogues globaux ne contiennent que des informations incomplètes à leur sujet. Bien que cette limitation soit intentionnelle et accélère la réplication des annuaires, elle constitue un problème lorsque vous souhaitez synchroniser ces groupes avec Cloud Identity ou Google Workspace. Plus précisément, si vous configurez GCDS pour utiliser un serveur de catalogue global comme source, l'outil pourra rechercher des groupes parmi tous les domaines de la forêt. Toutefois, seuls les groupes appartenant au même domaine que le serveur de catalogue global contiendront une liste de membres et conviendront à la réplication. Pour synchroniser des groupes locaux à un domaine ou des groupes globaux dans une forêt multidomaine, vous devez exécuter une instance GCDS distincte pour chaque domaine.

Les groupes universels étant intégralement répliqués au sein de la forêt, ils ne sont pas soumis à cette restriction. Une seule instance GCDS peut synchroniser des groupes universels de plusieurs domaines.

Avant de conclure que vous avez besoin de plusieurs instances GCDS pour synchroniser plusieurs domaines Active Directory avec Cloud Identity ou Google Workspace, n'oubliez pas que tous les groupes n'ont pas besoin d'être synchronisés. Pour cette raison, il est utile d'examiner comment les différents types de groupes de sécurité sont généralement utilisés dans votre forêt Active Directory.

Utiliser des groupes de sécurité dans Active Directory

Les sections suivantes décrivent les types de groupes de sécurité utilisés dans Active Directory.

Groupes de ressources

Windows utilise un modèle d'accès basé sur des listes de contrôle d'accès (LCA). Chaque ressource, qu'il s'agisse d'un fichier ou d'un objet LDAP, est associée à une LCA qui détermine quels utilisateurs y ont accès. Les ressources et les LCA assurant un contrôle très précis, elles sont donc très nombreuses. Pour simplifier la maintenance des LCA, il est courant de créer des groupes de ressources afin de regrouper les ressources qui sont utilisées fréquemment et ensemble. Vous ajoutez le groupe de ressources à toutes les LCA concernées une seule fois, puis vous gérez les accès supplémentaires en modifiant l’appartenance au groupe de ressources, et non les LCA.

Les ressources regroupées de cette manière résident généralement dans un même domaine. Par conséquent, un groupe de ressources tend également à être référencé dans un unique domaine, soit dans les LCA, soit par d'autres groupes de ressources. Comme la plupart des groupes de ressources sont locaux, ils sont généralement mis en œuvre dans Active Directory à l'aide de groupes locaux à un domaine.

Groupes de rôles et groupes d'organisation

Les groupes de ressources contribuent à simplifier la gestion des accès mais, dans un environnement très étendu, vous pouvez être amené à ajouter un nouvel utilisateur à un grand nombre de groupes de ressources. Pour cette raison, les groupes de ressources se voient généralement complétés par des groupes de rôles ou des groupes d'organisation.

Les groupes de rôles regroupent les autorisations requises par un rôle spécifique au sein de l'organisation. Un groupe de rôles nommé "Lecteur de la documentation d'ingénierie", par exemple, peut accorder aux membres l'accès en lecture seule à toute la documentation d'ingénierie. En pratique, vous pourriez mettre en œuvre cette solution en créant un groupe de rôles, puis en l'ajoutant comme membre à tous les groupes de ressources utilisés pour contrôler l'accès à divers types de documentation.

De la même manière, les groupes d'organisation regroupent les autorisations requises par les services existant au sein d'une organisation. Par exemple, un groupe d'organisation dénommé "Ingénierie" peut accorder l'accès à toutes les ressources généralement utilisées par les membres du service d'ingénierie.

Sur le plan technique, il n'existe pas de différence entre les groupes de rôles et les groupes de ressources, et les deux sont couramment utilisés de concert. Toutefois, contrairement aux groupes de ressources, les groupes de rôles et d’organisation peuvent avoir une légitimité au-delà des limites d’un domaine. Pour leur permettre d'être référencés par des groupes de ressources d'autres domaines, les groupes de rôles et d'organisation sont généralement mis en œuvre à l'aide de groupes globaux restreints à des membres d'un même domaine, parfois complétés par des groupes universels autorisant des membres d'autres domaines.

Le diagramme suivant illustre un modèle d'imbrication couramment utilisé dans les environnements Active Directory multidomaines.

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.

Contrairement aux groupes Active Directory, les membres d'un groupe Cloud Identity ou Google Workspace ne sont pas implicitement autorisés à répertorier les autres membres du même groupe. Vérifier l'appartenance à un groupe requiert généralement une autorisation explicite.

Utiliser des groupes dans Google Cloud

Google Cloud utilise un modèle d'accès basé sur les rôles plutôt que sur les LCA. Les rôles s'appliquent à toutes les ressources d'un certain type qui s'inscrivent dans un champ d'application donné. Par exemple, le rôle Kubernetes Engine Developer dispose d'un accès complet sur les objets d'API Kubernetes dans tous les clusters d'un projet donné. De par la nature des rôles, il n'y a pas d'impératif fort à maintenir des groupes de ressources sur Google Cloud, et il est rarement nécessaire de synchroniser des groupes de ressources avec Google Cloud.

Les groupes de rôles et les groupes d'organisation sont tout aussi pertinents dans Google Cloud que dans Active Directory, car ils facilitent la gestion des accès pour un nombre d'utilisateurs élevé. Synchroniser les groupes de rôles et d’organisation permet de préserver le rôle d'Active Directory en tant qu’emplacement principal de gestion des accès.

Si vous mettez en place de manière systématique les groupes de ressources en tant que groupes locaux à un domaine et les groupes de rôles et d'organisation en tant que groupes globaux ou universels, vous pouvez tirer parti du type de groupe pour vous assurer que seuls les groupes de rôles et les groupes d'organisation sont synchronisés.

Déterminer si vous aurez besoin d'exécuter une seule ou plusieurs instances GCDS par forêt multidomaine revient alors simplement à vous demander si vous utilisez des groupes globaux. Si vous créez tous vos groupes de rôles et d'organisation à l'aide de groupes universels, une seule instance GCDS suffit ; sinon, vous aurez besoin d'une instance GCDS par domaine.

Mapper des identités de groupe

Mapper des groupes de sécurité Active Directory avec des groupes Cloud Identity ou Google Workspace nécessite un identifiant commun. Dans Cloud Identity et Google Workspace, cet identifiant doit être une adresse e-mail dont la partie "domaine" correspond au domaine principal, secondaire ou d'alias du compte Cloud Identity ou Google Workspace. Étant donné que cette adresse e-mail sera utilisée partout dans Google Cloud, elle doit être lisible. L'adresse e-mail ne doit pas nécessairement correspondre à une boîte de courrier.

Dans Active Directory, les groupes sont identifiés soit par leur nom commun (cn), soit par un nom de connexion antérieur à Windows 2000 (sAMAccountName). De manière analogue aux comptes utilisateur, les groupes peuvent également posséder une adresse e-mail (mail), mais cette adresse constitue un attribut facultatif pour les groupes, dont Active Directory ne vérifie par ailleurs pas l'unicité.

Vous disposez de deux options pour mapper les identités de groupe entre Active Directory et Cloud Identity ou Google Workspace.

Mapper par nom commun

L'avantage d'utiliser le nom commun (cn) est que sa disponibilité est garantie, ainsi que, au niveau de l'unité organisationnelle au moins, son unicité. Cependant, le nom commun n'est pas une adresse e-mail. Un suffixe @DOMAIN doit donc lui être ajouté pour le transformer en adresse e-mail.

Vous pouvez configurer GCDS pour qu'il ajoute automatiquement un suffixe au nom du groupe. Étant donné qu'Active Directory garantit que les noms de groupe et les noms d'utilisateur n'entrent pas en conflit, il est peu probable qu'une adresse e-mail ainsi construite entraîne des conflits.

Si votre forêt Active Directory contient plusieurs domaines, les réserves suivantes s'appliquent :

• Si deux groupes appartenant à des domaines différents partagent un nom commun, l'adresse e-mail dérivée va générer un conflit. Par conséquent, l'un des groupes sera ignoré lors de la synchronisation.
• Vous ne pouvez synchroniser des groupes qu'à partir des domaines d'une même forêt. Si vous synchronisez des groupes issus de plusieurs forêts à l'aide d'instances GCDS distinctes, les adresses e-mail dérivées du nom commun ne reflètent pas la forêt à laquelle elles correspondent. Cette ambiguïté obligera une instance GCDS à supprimer tout groupe issu d'une autre forêt créé précédemment par une autre instance GCDS.
• Vous ne pouvez pas mapper des groupes par nom commun si vous utilisez la substitution de domaine pour mapper les utilisateurs.

Mapper par adresse e-mail

L'utilisation de l'adresse e-mail (mail) pour mapper les identités de groupe signifie que vous devez répondre aux mêmes critères que lorsque vous utilisez l'adresse e-mail pour mapper les utilisateurs :

• Les affectations des adresses e-mail doivent être exhaustives. Bien qu'il soit courant pour les groupes de distribution d'avoir une adresse e-mail, cet attribut manque fréquemment aux groupes de sécurité. Pour que les identités puissent être mappées à l'aide de l'adresse e-mail, le champ mail doit être renseigné pour les groupes de sécurité soumis à la synchronisation. La commande PowerShell suivante vous permet d'identifier les comptes pour lesquels ce n'est pas le cas :

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Les adresses e-mail doivent utiliser un ensemble organisé de domaines, qui vous appartiennent tous. Si certains de vos utilisateurs emploient des adresses e-mail qui font référence à des sociétés partenaires ou des fournisseurs de messagerie grand public, celles-ci ne peuvent pas être utilisées.

• Toutes les adresses e-mail doivent être uniques au sein de la forêt. Comme Active Directory n'impose pas l'unicité, vous pouvez être amené à mettre en place des contrôles ou des règles personnalisés.

Si tous les groupes concernés répondent à ces critères, vous pouvez identifier tous les domaines utilisés par ces adresses e-mail et vous assurer que la liste des domaines DNS enregistrés dans Cloud Identity ou Google Workspace couvre ces domaines.

Si l'un des critères n'est pas respecté, vous pouvez toujours mapper des UPN sur des adresses e-mail Cloud Identity ou Google Workspace, avec les mises en garde suivantes :

• Lors de la synchronisation, les groupes sans adresse e-mail seront ignorés, de même que les adresses e-mail utilisant des domaines non associés au compte Cloud Identity ou Google Workspace.
• Lorsque deux groupes partagent la même adresse e-mail, seul l'un d'eux sera synchronisé.

Le mappage de groupes par adresse e-mail n'est pas possible si votre forêt Active Directory contient plusieurs domaines et que vous utilisez la substitution de domaine pour mapper les utilisateurs.

Mappage des unités organisationnelles

La plupart des domaines Active Directory exploitent de manière intensive les unités organisationnelles pour regrouper et organiser les ressources de manière hiérarchique, contrôler les accès et appliquer des règles.

Dans Google Cloud, les dossiers et projets jouent un rôle similaire, bien que les types de ressources gérés dans une organisation Google Cloud soient très différents de ceux gérés dans Active Directory. Par conséquent, la hiérarchie de dossiers Google Cloud adaptée à une entreprise donnée peut être très différente de la structure des unités organisationnelles dans Active Directory. Le mappage automatique des unités organisationnelles vers des dossiers et projets n'est donc que rarement envisageable dans la pratique et n'est pas possible avec GCDS.

Sans relation avec les dossiers, Cloud Identity et Google Workspace intègrent le concept d'unité organisationnelle. Les unités organisationnelles sont créées pour regrouper et organiser les utilisateurs, comme dans Active Directory. Toutefois, contrairement à Active Directory, elles ne s'appliquent qu'aux utilisateurs, et non aux groupes.

GCDS offre la possibilité de synchroniser les unités organisationnelles d'Active Directory avec Cloud Identity ou Google Workspace. Dans une configuration où Cloud Identity sert simplement à étendre la gestion des identités Active Directory à Google Cloud, le mappage des unités organisationnelles n'est généralement pas nécessaire.

Choisir le bon mappage

Comme indiqué au début de ce document, il n'existe pas de solution unique permettant un mappage optimal des structures Active Directory avec Google Cloud. Pour vous aider à choisir le meilleur mappage pour votre cas d'utilisation, les graphes décisionnels ci-dessous récapitulent les critères abordés dans les sections précédentes.

Tout d'abord, reportez-vous au graphique ci-dessous pour déterminer le nombre de comptes Cloud Identity ou Google Workspace, d'instances GCDS et d'instances ou de parcs AD FS dont vous aurez besoin.

Reportez-vous ensuite au second graphique pour identifier les domaines à configurer dans votre compte Cloud Identity ou Google Workspace.

É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.
• Configurez GCDS pour synchroniser les utilisateurs et les groupes Active Directory avec Cloud Identity.
• Configurez l'authentification unique entre Active Directory et Google Cloud.
• Découvrez les bonnes pratiques de gestion des comptes de super-administrateur.