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 à une région. Vous pouvez configurer jusqu'à cinq stratégies par région.

Les protocoles de partage de fichiers (SMB (CIFS), NFSv3 avec groupes étendus et NFSv4, par exemple) qui utilisent des principaux 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 découvrent les contrôleurs de domaine Active Directory

  • Serveurs Kerberos : effectuent l'authentification

Pour en savoir plus, consultez 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 les PME. Il utilise SMB pour l'authentification et les recherches d'identité pour les utilisateurs et les groupes. NetApp Volumes rejoint le domaine en tant que membre, mais n'est pas compatible avec SMB en mode groupe de travail.

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

    La prise en charge étendue des groupes ignore tous les ID de groupe envoyés par le client NFS dans un appel NFS. Au lieu de cela, il récupère l'ID utilisateur de la requête et recherche tous les ID de groupe pour l'ID utilisateur donné à partir du serveur LDAP afin de vérifier les autorisations d'accès aux fichiers.

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

  • Mappage du principal de sécurité NFSv4.x à l'ID utilisateur et à l'ID de groupe : pour NFSv4.x, NetApp Volumes utilise Active Directory pour mapper les principaux de sécurité aux ID utilisateur et aux ID de groupe. NFSv4 utilise un modèle d'authentification basé sur les comptes principaux. Dans l'authentification basée sur les comptes principaux, les comptes principaux de sécurité identifient les utilisateurs sous la forme user@dns_domain (voir les considérations de sécurité RFC 7530) au lieu des ID utilisateur et des ID de groupe. Pour mapper les principaux de sécurité aux ID utilisateur et aux 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 ne sont compatibles qu'avec les serveurs LDAP Active Directory. La compatibilité 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 identifie le nom de l'utilisateur Active Directory. Utilisez ces valeurs lorsque vous définissez vos attributs LDAP POSIX.

    Pour utiliser NFSv4.1 sans mappage d'ID et uniquement avec 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 obligatoirement utiliser Active Directory comme serveur LDAP pour les recherches de comptes principaux de sécurité. Les comptes principaux Kerberos sont utilisés comme identifiants de sécurité. Le centre de distribution de clés Kerberos utilise Active Directory. Pour que cela fonctionne, vous devez associer une règle 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 machine Active Directory

Pour utiliser Active Directory, NetApp Volumes doit joindre un ou plusieurs serveurs de fichiers virtuels à votre domaine en tant que comptes d'ordinateur. Pour rejoindre le domaine, vous devez fournir les identifiants d'un utilisateur du domaine autorisé à joindre des ordinateurs à votre domaine. Par défaut, seuls les membres du groupe Domain Admins peuvent joindre des ordinateurs au domaine, 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 (UO) complets.

Pour NetApp Volumes, il est recommandé de créer un compte de service de domaine dédié. Déléguez uniquement les autorisations nécessaires pour joindre de nouveaux ordinateurs à une UO spécifique. Une fois qu'un utilisateur membre d'un groupe Domain User ou Domain Guest est créé, suivez les instructions ci-dessous pour déléguer les autorisations requises.

  1. Connectez-vous à votre système en tant qu'administrateur de domaine pour votre domaine Active Directory.

  2. Ouvrez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory.

  3. Dans la barre de menu, sélectionnez Affichage et assurez-vous que l'option Fonctionnalités avancées est activée.

    Une coche s'affiche si les fonctionnalités avancées sont activées.

  4. Dans le volet des tâches, développez le nœud du domaine.

  5. Localisez l'UO que vous souhaitez modifier, effectuez un clic droit, puis sélectionnez Propriétés dans le menu contextuel.

  6. Dans la fenêtre Propriétés de l'UO, sélectionnez l'onglet Sécurité.

  7. Sous Sécurité, cliquez sur Avancé, puis sur Ajouter.

  8. Dans la boîte de dialogue Entrée d'autorisation, procédez comme suit :

    1. Cliquez sur Sélectionner un compte principal.

    2. Saisissez le nom de votre compte de service ou de votre groupe, puis cliquez sur OK.

    3. Pour S'applique à, sélectionnez Cet objet et tous les objets descendants.

    4. Assurez-vous que les autorisations suivantes sont sélectionnées :

      • Modifier les autorisations

      • Créer des objets ordinateur

      • Supprimer des objets ordinateur

  9. Cochez la case Appliquer, puis cliquez sur OK.

  10. Fermez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory.

Une fois le compte de service délégué, vous pouvez fournir le nom d'utilisateur et le mot de passe comme identifiants de la stratégie Active Directory.

Pour renforcer la sécurité, lors de la requête 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 le DNS pour 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écouverte du site Active Directory : NetApp Volumes utilise un ping LDAP vers l'adresse IP du serveur DNS spécifiée dans la stratégie Active Directory pour récupérer les informations du sous-réseau du site Active Directory. Il renvoie une liste de CIDR et des sites Active Directory qui leur sont attribués.

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

  2. Définir des noms de sites : 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 sont prioritaires sur celles 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 règle 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 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 du contrôleur de domaine : une fois toutes les informations nécessaires obtenues, 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 la 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 de la liste des contrôleurs de domaine : une liste des contrôleurs de domaine est générée. NetApp Volumes surveille constamment la disponibilité de tous les volumes. Parmi les contrôleurs de domaine disponibles, il en sélectionne un pour les jointures de domaine et les recherches. Si le contrôleur de domaine sélectionné disparaît, un autre contrôleur de domaine de la liste Available (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'il existe un chemin réseau routé entre NetApp Volumes et les contrôleurs de domaine, et que les règles de pare-feu sur vos contrôleurs de domaine autorisent NetApp Volumes à se connecter.

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

Topologies de contrôleur de domaine Active Directory

Une fois que vous 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 potentielles. Les scénarios ne décrivent que le contrôleur de domaine utilisé par NetApp Volumes. Les autres contrôleurs de domaine pour le même domaine ne sont décrits que lorsque cela est 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 correspond à 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 de contrôleurs de domaine avec les 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 sur les performances d'accès aux fichiers. Veillez à ne pas ajouter de sauts d'appairage de cloud privé virtuel supplémentaires 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 de 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 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é, ce scénario devient, d'un point de vue architectural, identique à l'un des scénarios des sections précédentes.

Étapes suivantes

Créez une règle Active Directory.