Intégration d'Active Directory à Google Cloud NetApp Volumes

Cette page décrit l'intégration de Google Cloud NetApp Volumes à Active Directory.

À propos de l'intégration

Une stratégie Active Directory indique à NetApp Volumes comment se connecter à Active Directory. Les configurations de pool de stockage utilisent des stratégies Active Directory pour définir les paramètres Active Directory des volumes que vous créez dans ces pools.

Les stratégies Active Directory sont spécifiques à chaque région. Vous pouvez en configurer jusqu'à cinq par région.

Les protocoles de partage de fichiers, tels que SMB (CIFS), NFSv3 avec des groupes étendus et NFSv4, qui utilisent des principes de sécurité, s'appuient sur des services d'annuaire externes pour fournir des informations sur l'identité des utilisateurs. NetApp Volumes s'appuie sur Active Directory pour les services d'annuaire. Active Directory fournit les services suivants:

  • Serveurs LDAP: recherchent des objets tels que des utilisateurs, des groupes ou des machines

  • Serveurs DNS: résolvent les noms d'hôte et permettent de découvrir les contrôleurs de domaine Active Directory.

  • Serveurs Kerberos: effectuent l'authentification

Pour en savoir plus, consultez les bonnes pratiques pour exécuter Active Directory sur Google Cloud.

Cas d'utilisation d'Active Directory

NetApp Volumes utilise Active Directory pour plusieurs cas d'utilisation:

  • Service de domaine SMB: Active Directory est le service de domaine central pour SMB. Il utilise SMB pour l'authentification et la recherche d'identité des utilisateurs et des groupes. NetApp Volumes rejoint le domaine en tant que membre, mais n'est pas compatible avec SMB en mode groupe de travail.

  • Compatibilité avec les groupes étendus NFSv3: pour NFSv3 avec compatibilité avec les groupes étendus, Active Directory fournit le serveur LDAP requis pour rechercher des objets tels que des utilisateurs, des groupes ou des comptes de machine. Plus précisément, les recherches d'ID utilisateur et d'ID de groupe nécessitent un serveur LDAP conforme à RFC2307bis. La prise en charge de LDAP est activée sur les pools de stockage lors de leur création.

    La prise en charge des groupes étendus ignore tous les ID de groupe envoyés par le client NFS dans un appel NFS. Au lieu de cela, il prend l'ID utilisateur de la requête et recherche tous les ID de groupe pour l'ID utilisateur donné sur le serveur LDAP afin de vérifier les autorisations de fichiers.

    Pour en savoir plus, consultez Gérer les attributs POSIX RFC2307bis LDAP.

  • Mappage des principaux de sécurité NFSv4.x sur les ID utilisateur et les ID de groupe: pour NFSv4.x, NetApp Volumes utilise Active Directory pour mapper les principaux de sécurité sur les ID utilisateur et les ID de groupe. NFSv4 utilise un modèle d'authentification basé sur les principaux. Dans l'authentification basée sur les principaux, les principaux de sécurité identifient les utilisateurs qui prennent la forme user@dns_domain (voir la section Considérations de sécurité pour RFC 7530) au lieu des ID utilisateur et des ID de groupe. Pour mapper des principaux de sécurité sur des ID utilisateur et des ID de groupe lorsque vous accédez au volume avec un protocole NFSv4.x, NetApp Volumes nécessite un serveur LDAP conforme à RFC2307bis. NetApp Volumes n'est compatible qu'avec les serveurs LDAP Active Directory. La prise en charge de LDAP est activée sur les pools de stockage lors de leur création.

    Pour utiliser des principaux de sécurité, le client et le serveur NFS doivent se connecter à la même source LDAP, et vous devez configurer le fichier idmapd.conf au niveau du client. Pour en savoir plus sur la configuration du fichier idmapd.conf, consultez la documentation Ubuntu sur la configuration du fichier idmapd.conf pour libnfsidmap.

    dns_domain utilise le nom de domaine Active Directory et user s'identifie comme le nom de l'utilisateur Active Directory. Utilisez ces valeurs lorsque vous définissez vos attributs POSIX LDAP.

    Pour utiliser NFSv4.1 sans mappage d'ID et n'utiliser que des ID utilisateur et des ID de groupe semblables à NFSv3, utilisez des ID numériques pour ignorer les principaux de sécurité. NetApp Volumes est compatible avec les ID numériques. Les clients NFS actuels utilisent des ID numériques par défaut si le mappage d'ID n'est pas configuré.

  • NFSv4.x avec Kerberos:si vous utilisez Kerberos, vous devez utiliser Active Directory comme serveur LDAP pour les recherches de principal de sécurité. Les principals Kerberos sont utilisés comme identifiants de sécurité. Le centre de distribution de clés Kerberos utilise Active Directory. Pour ce faire, vous devez associer une stratégie Active Directory contenant des paramètres Kerberos au pool et activer la compatibilité LDAP sur un pool de stockage lorsque vous le créez.

Autorisations requises pour créer des comptes de machine Active Directory

Vous pouvez ajouter des objets de machine NetApp Volumes à un Active Directory Windows avec un compte disposant des autorisations nécessaires pour associer un ordinateur au domaine. Il s'agit généralement du groupe Domain Admins, mais Active Directory peut déléguer les autorisations requises à des utilisateurs ou à des groupes individuels au niveau d'un domaine ou d'une unité organisationnelle complets.

Vous pouvez accorder ces autorisations à l'aide de l'Assistant de délégation de contrôle dans Active Directory en créant une tâche personnalisée qui vous permet de créer et de supprimer des objets ordinateur avec les autorisations d'accès suivantes:

  • Lecture et écriture

  • Créer et supprimer tous les objets enfants

  • Lire et écrire toutes les propriétés

  • Modifier et réinitialiser le mot de passe ("Lire et écrire les stratégies de mot de passe et de verrouillage du domaine")

La délégation d'un utilisateur ajoute une liste de contrôle des accès de sécurité pour l'utilisateur défini à l'unité organisationnelle dans Active Directory et réduit l'accès à l'environnement Active Directory. Une fois qu'un utilisateur a été délégué, vous pouvez fournir le nom d'utilisateur et le mot de passe en tant qu'identifiants de stratégie Active Directory.

Pour plus de sécurité, lors de l'interrogation et de la création de l'objet de compte machine, le nom d'utilisateur et le mot de passe transmis au domaine Active Directory utilisent le chiffrement Kerberos.

Contrôleurs de domaine Active Directory

Pour connecter NetApp Volumes à votre domaine, le service utilise la découverte basée sur DNS afin d'identifier une liste de contrôleurs de domaine disponibles à utiliser.

Le service exécute les étapes suivantes pour trouver un contrôleur de domaine à utiliser:

  1. Détection de site Active Directory: NetApp Volumes utilise un ping LDAP à l'adresse IP du serveur DNS spécifiée dans la stratégie Active Directory pour récupérer les informations de sous-réseau du site Active Directory. Il renvoie une liste des plages CIDR et des sites Active Directory qui leur sont attribués.

    Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

  2. Définir des noms de site: si l'adresse IP du volume correspond à l'un des sous-réseaux définis, le nom de site associé est utilisé. Les correspondances de sous-réseaux plus petits ont la priorité sur les correspondances de sous-réseaux plus grands. Si l'adresse IP du volume est inconnue, créez manuellement un volume temporaire avec le type de protocole NFS pour déterminer le bloc CIDR /28 utilisé.

    Si aucun nom de site n'est défini dans Active Directory, le nom de site configuré dans la stratégie Active Directory est utilisé. Si aucun nom de site n'est configuré, les niveaux de service Standard, Premium et Extreme utilisent le site Default-First-Site-Name. Si le niveau de service Flex tente d'utiliser le site Default-First-Site-Name, il échoue et le niveau de service Flex utilise plutôt la découverte complète du contrôleur de domaine. Notez que les modifications apportées au paramètre de site Active Directory sont ignorées par les pools de stockage de niveau de service Flex.

  3. Détection de contrôleurs de domaine: une fois toutes les informations nécessaires acquises, le service identifie les contrôleurs de domaine potentiels à l'aide de la requête DNS suivante:

    nslookup -type=srv _ldap._tcp.<site_name>._sites.dc._msdcs.<domain-name> <dns-server>

    Pour une découverte complète du domaine, le service utilise la requête DNS suivante:

    nslookup -type=srv _ldap._tcp.dc._msdcs.<domain-name> <dns-server>

  4. Génération d'une liste de contrôleurs de domaine: une liste de contrôleurs de domaine est générée. NetApp Volumes surveille en permanence leur disponibilité. Parmi les contrôleurs de domaine disponibles, il en sélectionne un pour l'association au domaine et les recherches. Si le contrôleur de domaine sélectionné disparaît, un autre contrôleur de domaine de la liste Disponible est utilisé automatiquement. Notez que le contrôleur de domaine que vous choisissez n'est pas nécessairement le serveur DNS spécifié.

Vous devez fournir au moins un contrôleur de domaine accessible pour que le service puisse l'utiliser. Nous vous recommandons d'en utiliser plusieurs pour améliorer la disponibilité des contrôleurs de domaine. Assurez-vous qu'un chemin réseau routé existe entre les NetApp Volumes et les contrôleurs de domaine, et que les règles de pare-feu sur vos contrôleurs de domaine autorisent les NetApp Volumes à se connecter.

Pour en savoir plus, consultez la section Considérations et bonnes pratiques concernant la conception d'Active Directory.

Topologies de contrôleurs de domaine Active Directory

Une fois que vous êtes connecté aux contrôleurs de domaine Active Directory, vous pouvez utiliser les protocoles de partage de fichiers suivants:

  • PME

  • NFSv3 avec groupes étendus

  • NFSv4 avec des principaux de sécurité et Kerberos

Les scénarios suivants décrivent des topologies possibles. Les scénarios ne décrivent que le contrôleur de domaine utilisé par NetApp Volumes. Les autres contrôleurs de domaine du même domaine ne sont décrits que si nécessaire. Nous vous recommandons de déployer au moins deux contrôleurs de domaine pour la redondance et la disponibilité.

  • Contrôleur de domaine Active Directory et volumes dans une même région : ce scénario est la stratégie de déploiement la plus simple, dans laquelle un contrôleur de domaine se trouve dans la même région que le volume.

  • Contrôleur de domaine Active Directory et volumes dans des régions distinctes : vous pouvez utiliser un contrôleur de domaine dans une région différente de celle d'un volume. Cela peut avoir un impact négatif sur les performances d'authentification et d'accès aux fichiers.

  • Contrôleurs de domaine Active Directory dans plusieurs régions à l'aide de sites AD : si vous utilisez des volumes dans plusieurs régions, nous vous recommandons de placer au moins un contrôleur de domaine dans chaque région. Bien que le service tente de choisir automatiquement le meilleur contrôleur de domaine à utiliser, nous vous recommandons de gérer la sélection des contrôleurs de domaine avec des sites Active Directory.

  • Contrôleur de domaine Active Directory dans un réseau sur site : vous pouvez utiliser un contrôleur de domaine sur site via un VPN, mais cela peut avoir un impact négatif sur l'authentification des utilisateurs finaux et les performances d'accès aux fichiers. Veillez à ne pas ajouter d'autres sauts d'appairage cloud privé virtuel dans votre chemin réseau. L'appairage de VPC est soumis à des restrictions de routage transitif. Le trafic n'est pas acheminé au-delà du saut d'appairage VPC que NetApp Volumes consomme déjà.

  • Contrôleur de domaine Active Directory dans un autre réseau VPC: vous ne pouvez pas placer le contrôleur de domaine dans un autre VPC, car l'appairage de réseaux VPCGoogle Cloud n'autorise pas le routage transitif. Vous pouvez également connecter les VPC à l'aide d'un VPN ou associer des NetApp Volumes à un réseau VPC partagé qui héberge les contrôleurs de domaine Active Directory. Si vous associez des NetApp Volumes à un réseau VPC partagé, d'un point de vue architectural, ce scénario devient identique à l'un des scénarios des sections précédentes.

Étape suivante

Créez une stratégie Active Directory.