Fédérer Google Cloud avec Active Directory : introduction

Cet article constitue la première partie d'une série expliquant comment étendre une solution de gestion des identités existante basée sur Active Directory à Google Cloud. L'article décrit comment établir des mécanismes d'authentification et d'autorisation cohérents dans un environnement informatique hybride. Il se concentre sur l'utilisation de Cloud Identity, même si une partie de la discussion s'applique également à G Suite.

La série comprend les éléments suivants :

Les services informatiques des entreprises exploitent fréquemment Active Directory pour gérer les comptes utilisateur et contrôler l'accès aux applications et aux ressources informatiques. Cette confiance fait d'Active Directory la pierre angulaire de leur paysage informatique et de leur infrastructure sur site.

Lorsque vous étendez votre environnement informatique existant à Google Cloud dans le cadre d'une stratégie hybride, il est souhaitable de conserver un point unique de gestion des identités. Une solution unique de gestion des identités minimise les tâches d'administration et permet aux utilisateurs et aux applications de s'authentifier de manière sécurisée dans un environnement hybride.

Cet article compare les structures logiques d'Active Directory et de GCP, et explique comment mapper les comptes Active Directory sur des comptes d'utilisateurs et de groupes dans GCP, afin de mettre en œuvre la fédération. À la fin de cet article, un organigramme vous aide à déterminer l'approche optimale pour votre propre scénario de mappage entre Active Directory et GCP.

Cet article part du principe que vous connaissez Active Directory.

Mettre en œuvre la fédération

Google Cloud utilise les identités Google pour l'authentification et la gestion des accès. Pour pouvoir accéder aux ressources Google Cloud, un employé doit posséder une identité Google. Gérer manuellement les identités Google de chacun des employés se révélerait fastidieux, d'autant plus si tous ces employés possèdent déjà un compte dans Active Directory. En fédérant les identités des utilisateurs entre Active Directory et Google Cloud, vous pouvez automatiser la maintenance des comptes Google et lier leur cycle de vie aux comptes d'Active Directory. La fédération contribue à garantir les éléments suivants :

  • Active Directory reste la version unique de référence (SSOT, "Single Source Of Truth") pour la gestion des identités.
  • Un compte utilisateur Google est créé automatiquement pour la totalité des comptes utilisateur dans Active Directory, ou bien pour un sous-ensemble de ces comptes.
  • Si un compte est désactivé ou supprimé dans Active Directory, le compte Google correspondant est également suspendu ou supprimé. En revanche, suspendre ou supprimer un compte Google n'a aucun effet sur Active Directory, car le compte Google sera recréé automatiquement lors de la synchronisation suivante.
  • Active Directory gère l'authentification des utilisateurs, de sorte que vous n'avez pas besoin de synchroniser les mots de passe avec Google Cloud.

Du côté de Google, vous pouvez utiliser Cloud Identity pour configurer un annuaire privé de comptes utilisateur dans lequel créer et gérer des comptes Google. Fédérer Active Directory avec Cloud Identity implique alors deux aspects :

Fédérer Active Directory avec Cloud Identity

  • Synchronisation des comptes : les comptes utilisateur et les groupes concernés sont synchronisés périodiquement d'Active Directory vers Cloud Identity. Ainsi, lorsque vous créez un compte dans Active Directory, celui-ci peut être référencé dans Google Cloud avant même que l'utilisateur associé se soit connecté pour la première fois. Ce processus garantit également la propagation des suppressions de comptes.

    La synchronisation est à sens unique, ce qui signifie que toute modification dans Active Directory est répliquée dans Cloud Identity, mais pas l'inverse. Par ailleurs, la synchronisation 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 dans Google Cloud, Cloud Identity délègue l'authentification à Active Directory au moyen 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. Cependant, pour que la connexion réussisse, le compte correspondant doit avoir été préalablement synchronisé.

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

  • Google Cloud Directory Sync est un outil gratuit fourni par Google qui met en œuvre le processus de synchronisation. Cloud Directory Sync communique avec la plate-forme Google Identity 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.

Du fait que les API de la plate-forme Google Identity sont disponibles publiquement et que SAML est un standard ouvert, il existe de nombreux outils permettant de mettre en œuvre la fédération. Cet article se concentre sur l’utilisation de Cloud Directory Sync et des services 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.

Infrastructure Active Directory

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, vous gérez des ressources au sein d'organisations, que vous pouvez segmenter davantage à 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 comptes utilisateur comme des ressources. La gestion et l'authentification des comptes utilisateur sont donc liées aux domaines. En revanche, Google Cloud ne gère pas les comptes utilisateur au sein d'une organisation, à l'exception des comptes de service. Au lieu de cela, Google Cloud s'appuie sur Cloud Identity ou G Suite pour gérer les comptes utilisateur.

Cloud Identity vous permet de créer et gérer des annuaires privés pour des comptes et groupes d'utilisateurs. Chacun de ces annuaires est géré indépendamment et peut, par exemple, différer au niveau des méthodes d'authentification autorisées ou des stratégies de mot de passe appliquées. Dans Cloud Identity, les annuaires sont désignés par le terme comptes Cloud Identity et sont identifiés par des noms de domaine.

Infrastructure de gestion des identités GCP

Une forêt et un domaine racine de forêt sont toujours créés en tandem dans Active Directory. De manière similaire, un compte Cloud Identity est toujours créé en parallèle avec une organisation Google Cloud. Et, tout comme un domaine racine de forêt et une forêt partagent le même nom et sont indissociables, le compte Cloud Identity et l'organisation Google Cloud partagent 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.

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 ;
  • comment mapper des domaines DNS ;
  • Comment mapper des comptes utilisateur
  • Comment mapper des groupes

Les sections suivantes examinent chacun de ces facteurs.

Mapper 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

Forêt unique, domaine unique

Lorsqu'une forêt comprend un seul domaine, vous pouvez mapper la totalité de la forêt Active Directory sur un seul compte Cloud Identity. 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 Cloud Directory Sync 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

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. 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 Cloud Directory Sync 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 Cloud Directory Sync, mais une seule instance ou un seul parc AD FS pour gérer l'authentification unique.

Forêts multiples avec approbation interforêt

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. 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, une liste complète des comptes utilisateur. En raison de cette limitation, fédérer un environnement à plusieurs forêts avec Google Cloud nécessite au moins une instance Cloud Directory Sync 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

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 si celles-ci sont dépourvues d'approbations interforêts. Dans ce contexte, chaque forêt doit être mappée sur un compte Cloud Identity distinct, ce qui implique d'exécuter au moins une instance Cloud Directory Sync et un serveur ou parc AD FS par forêt.

Dans Google Cloud, une organisation distincte est créée pour chaque compte Cloud Identity. 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, ce qui crée ainsi une organisation fédérée avec plusieurs forêts Active Directory. Les autres organisations demeurent alors inutilisées.

Mapper des domaines DNS

Le DNS joue un rôle crucial à la fois dans Active Directory et pour Cloud Identity. 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é. Dans l'idéal, les comptes utilisateur dans Active Directory possèdent l'adresse e-mail qui est 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 du compte 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 du compte 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

Google Identity Platform, 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 Identity Platform détermine l'annuaire ou le fournisseur d'identité à utiliser pour authentifier un utilisateur sur la base de la partie "domaine" des adresses e-mail, qui suit le caractère @. Ainsi, pour une adresse e-mail utilisant le domaine gmail.com, Google Identity Platform utilise l'annuaire des comptes utilisateur Gmail pour l'authentification.

Utiliser des domaines DNS dans GCP

Dans les faits, lorsque vous créez un compte G Suite ou Cloud Identity, vous créez un annuaire privé dont Google Identity Platform peut se servir pour l'authentification. De la même manière que l'annuaire Gmail est associé au domaine gmail.com, les comptes G Suite et Cloud Identity doivent être associés à un domaine personnalisé. Trois types de domaines différents sont utilisés :

  • Domaine principal : ce domaine identifie l'annuaire Cloud Identity et sert également de nom pour l'organisation dans Google Cloud. Lorsque vous vous inscrivez à Cloud Identity, vous devez spécifier ce nom de domaine.
  • Domaine secondaire : en plus du domaine principal, vous pouvez associer à un annuaire Cloud Identity des domaines secondaires supplémentaires. Chaque compte de l'annuaire est associé soit au domaine principal, soit à l'un des domaines secondaires. Deux comptes tels que johndoe@example.com et johndoe@secondary.example.com sont donc considérés comme des comptes distincts si example.com est le domaine principal et secondary.example.com le domaine secondaire d'un annuaire.
  • Domaine d'alias : un domaine d'alias est un domaine alternatif pour le domaine principal. Cela signifie que johndoe@example.com et johndoe@alias.example.com font référence au même compte 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. Les noms de domaine locaux tels que corp.local ou corp.internal, d'usage courant dans Active Directory, ne sont pas autorisés. Durant la mise en place, vous aurez sans doute besoin d'un accès administrateur aux zones DNS respectives 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. De cette manière, les messages envoyés aux adresses e-mail formées à partir de ce nom de domaine peuvent être correctement remis.

La synchronisation entre les annuaires nécessite un mappage entre les domaines Active Directory et les domaines utilisés par Cloud Identity. Déterminer le bon mappage dépend de la manière dont vous utilisez Active Directory et nécessite d'examiner de plus près comment les comptes utilisateur sont identifiés dans une forêt Active Directory et comment ils peuvent être mappés sur Cloud Identity.

Mapper des comptes utilisateur

Le troisième facteur à prendre en compte lorsque vous envisagez de fédérer Active Directory avec Google Cloud consiste à savoir comment mapper les comptes utilisateur entre Active Directory et Cloud Identity.

Identifier des comptes utilisateur dans Active Directory

En interne, Active Directory utilise deux éléments pour identifier de manière unique les comptes utilisateur :

  • 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 compte qui est déplacé vers un autre domaine de la forêt peut se voir attribuer un nouveau SID.

Comme aucun de ces ID ne revêt de sens pour les utilisateurs, Active Directory propose deux méthodes plus conviviales pour identifier les comptes utilisateur :

  • UPN (userPrincipalName) : le moyen privilégié pour identifier un compte 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 solution privilégiée pour identifier les comptes utilisateur, les noms UPN sont facultatifs. Par conséquent, il se peut que certains comptes utilisateur de votre forêt Active Directory ne disposent pas de nom UPN.

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

Mapper des identités de compte

Mapper des comptes Active Directory et des comptes Cloud Identity requiert deux informations pour chaque compte utilisateur :

  • Un identifiant unique et stable que vous pouvez utiliser lors de la synchronisation pour déterminer quel compte Active Directory correspond à quel compte Cloud Identity. 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. É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.

Un compte utilisateur Active Directory possède deux champs qui sont des candidats potentiels pour l'adresse e-mail Cloud Identity : userPrincipalName et mail.

Mapper suivant le nom d'utilisateur principal

L'utilisation du champ userPrincipalName requiert que les deux critères suivants soient remplis pour tous les comptes soumis à la synchronisation :

  • Les noms 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. Un nom UPN doit être attribué à chacun des comptes utilisateur soumis à la synchronisation. La commande PowerShell suivante vous permet d'identifier les comptes dépourvus de nom 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. Vous pouvez utiliser l'un des suffixes UPN en tant que domaine principal dans Cloud Identity et ajouter tout autre suffixe UPN en tant que domaine secondaire.

Si l'un des critères n'est pas rempli, il reste possible de mapper les noms UPN aux adresses e-mail Cloud Identity, mais les mises en garde suivantes s'appliquent :

  • 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 comptes sans nom UPN seront 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, la synchronisation ne peut s'appliquer qu'à un seul compte.

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.

Mappage par adresse e-mail

L'utilisation du champ mail requiert que les critères suivants soient remplis pour tous les comptes soumis à la synchronisation :

  • Les affectations des adresses e-mail doivent être exhaustives. Le champ mail doit être rempli pour chacun des comptes utilisateur soumis à la synchronisation. La commande PowerShell suivante vous permet d'identifier les comptes 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 comptes 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 comptes concernés répondent à ces critères, vous pouvez identifier tous les domaines utilisés par ces adresses e-mail et les utiliser en tant que domaine principal et domaines secondaires dans Cloud Identity.

Si l'un des critères n'est pas rempli, il reste possible de mapper les adresses e-mail avec les adresses e-mail Cloud Identity, mais les mises en garde suivantes s'appliquent :

  • Les comptes sans adresse e-mail, de même que les comptes dont les adresses utilisent des domaines non associés à l'annuaire Cloud Identity, seront ignorés durant la synchronisation.
  • Lorsque deux comptes partagent la même adresse e-mail, seul l'un d'eux sera 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 compte sera synchronisé.

Mapper des 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'attribuer des utilisateurs individuels aux rôles Cloud IAM (Cloud Identity and Access Management) dans chaque projet, vous définissez un ensemble de groupes modélisant les rôles courants au sein de votre organisation, puis vous affectez ces groupes à un ensemble de rôles Cloud 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 G Suite, afin que Cloud Directory Sync soit en mesure de gérer les groupes de distribution aussi bien standards que 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 de sécurité entre Active Directory et Google Cloud est facultatif. Une fois les comptes utilisateur fédérés, vous pouvez créer et gérer des groupes directement dans Cloud Identity. Cela signifie donc qu'Active Directory reste le système central pour la gestion des identités, mais pas pour la gestion des accès. Pour préserver le rôle central d'Active Directory 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. Cette approche vous permettra de configurer Cloud IAM afin d'utiliser les informations d'appartenance aux groupes dans Active Directory pour contrôler qui a accès à certaines 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 de sécurité dans AD

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 comptes utilisateur et d'autres groupes globaux du 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 comptes utilisateur 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 Cloud Directory Sync. Si votre forêt Active Directory utilise plusieurs domaines, le type d'un groupe détermine si et comment il peut être synchronisé avec Cloud Identity.

É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 délibérée et contribue à accélérer la réplication des annuaires, elle représente un obstacle lorsque vous souhaitez synchroniser des groupes de ce type avec Cloud Identity. Plus précisément, si vous configurez Cloud Directory Sync 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 distincte de Cloud Directory Sync 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 Cloud Directory Sync peut synchroniser des groupes universels de plusieurs domaines.

Toutefois, avant de conclure que vous avez besoin de plusieurs instances Cloud Directory Sync pour synchroniser plusieurs domaines Active Directory avec Cloud Identity, n'oubliez pas que tous les groupes n'ont pas nécessairement 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

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.

Modèle d'imbrication utilisé dans les environnements AD multidomaines

Groupes dans Cloud Identity

Dans Cloud Identity, il n'existe qu'un seul type de groupe, dont le comportement est identique à celui des groupes universels dans Active Directory. Autrement dit, les groupes ne sont pas limités au champ d'application du compte Cloud Identity au sein duquel ils ont été définis. Au lieu de cela, les groupes peuvent inclure des comptes utilisateur issus de différents comptes Cloud Identity. Ces groupes peuvent être référencés et imbriqués dans d'autres comptes Cloud Identity, et ils peuvent être utilisés dans toute organisation Google Cloud.

Contrairement aux groupes Active Directory, les membres d'un groupe Cloud Identity 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.

Synchroniser des groupes de rôles et des groupes d'organisation

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 Cloud Directory Sync 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 Cloud Directory Sync suffit ; sinon, vous aurez besoin d'une instance Cloud Directory Sync par domaine.

Mapper des identités de groupe

Mapper les groupes de sécurité Active Directory avec les groupes Cloud Identity requiert un identifiant commun. Dans Cloud Identity, cet identifiant doit être une adresse e-mail dont la partie "domaine" correspond à un domaine principal, secondaire ou d'alias dans Cloud Identity. É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 avez le choix entre deux options pour mapper les identités de groupe entre Active Directory et Cloud Identity.

Mapper suivant le 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 Cloud Directory Sync pour ajouter automatiquement un suffixe au nom du groupe. Étant donné qu'Active Directory garantit que les noms de groupe et les noms de compte utilisateur n'entrent pas en conflit, une adresse e-mail ainsi construite est également peu susceptible de générer 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 Cloud Directory Sync 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 Cloud Directory Sync à supprimer tout groupe issu d'une autre forêt créé précédemment par une autre instance Cloud Directory Sync.
  • Vous ne pouvez pas mapper des groupes suivant le nom commun si vous utilisez la substitution de domaine pour mapper les comptes utilisateur.

Mappage par adresse e-mail

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

  • 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 comptes 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 groupes concernés répondent à ces critères, vous pouvez identifier tous les domaines utilisés par ces adresses e-mail et vérifier qu'ils font bien partie de la liste des domaines DNS enregistrés dans Cloud Identity.

Si l'un des critères n'est pas rempli, il reste possible de mapper les adresses e-mail avec les adresses e-mail Cloud Identity, mais les mises en garde suivantes s'appliquent :

  • Les groupes sans adresse e-mail, de même que les adresses utilisant des domaines non associés à l'annuaire Cloud Identity, seront ignorés durant la synchronisation.
  • 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 comptes utilisateur.

Mapper 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 Cloud Directory Sync.

Sans relation avec les dossiers, Cloud Identity intègre le concept d’unité organisationnelle. Des unités organisationnelles sont créées pour regrouper et organiser des comptes utilisateur de façon semblable à Active Directory. Toutefois, contrairement à Active Directory, elles ne s’appliquent qu'aux comptes utilisateur et non aux groupes.

Cloud Directory Sync offre la possibilité de synchroniser les unités organisationnelles d'Active Directory avec les unités organisationnelles de Cloud Identity. 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 cet article, il n'existe pas une 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.

Pour commencer, reportez-vous au graphe ci-dessous pour déterminer le nombre de comptes Cloud Identity, d'instances Cloud Directory Sync et d'instances ou de parcs AD FS dont vous aurez besoin.

Graphe décisionnel pour déterminer le nombre de parcs ou d'instances nécessaires

Reportez-vous ensuite au second graphe pour identifier les domaines à configurer dans votre compte Cloud Identity.

Graphe décisionnel pour identifier les domaines à configurer dans Cloud Identity

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…