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 Microsoft Active Directory pour les services d'annuaire. Active Directory fournit des services tels que des serveurs LDAP pour la recherche d'objets (utilisateurs, groupes, comptes de machine, etc.), des serveurs DNS pour résoudre les noms d'hôte et des serveurs Kerberos pour l'authentification.
Pour en savoir plus, consultez la section Bonnes pratiques pour l'exécution d'Active Directory sur Google Cloud.
NetApp Volumes n'est pas compatible avec le service Microsoft AD géré de Google Cloud.
Cas d'utilisation
NetApp Volumes utilise Active Directory dans les cas décrits dans les sections suivantes.
Service de domaine SMB
Active Directory est le service de domaine central pour les PME. SMB est utilisé pour l'authentification et la recherche d'identité des utilisateurs et des groupes. NetApp Volumes rejoint le domaine en tant que membre et n'est pas compatible avec SMB en mode groupe de travail.
Compatibilité avec les 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, un serveur LDAP conforme à la RFC2307bis est requis pour les recherches d'ID utilisateur et d'ID de groupe. 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. À la place, elle 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 la section Gérer les attributs POSIX RFC2307bis LDAP.
Mappage du principal de sécurité NFSv4.x sur l'ID utilisateur et l'ID de groupe
Pour NFSv4.x, Active Directory permet de mapper des principaux de sécurité sur des ID utilisateur et des ID de groupe. NFSv4 utilise un modèle d'authentification basé sur les principaux. Dans l'authentification basée sur les principaux, les utilisateurs sont identifiés par des principaux de sécurité qui prennent la forme user@dns_domain (voir https://www.rfc-editor.org/rfc/rfc7530.html#section-19) au lieu d'être identifiés par 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 à l'aide d'un protocole NFSv4.x, NetApp Volumes nécessite un serveur LDAP conforme à la RFC2307bis. Le seul serveur LDAP compatible est 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 le fichier idmapd.conf doit être configuré sur le client. Pour en savoir plus sur la configuration du fichier idmapd.conf, consultez la page de manuel Ubuntu: idmapd.conf - fichier de configuration pour libnfsidmap.
Le nom de domaine Active Directory est utilisé pour dns_domain. user correspond au nom des utilisateurs Active Directory. Utilisez ces valeurs lorsque vous définissez vos attributs POSIX LDAP.
Pour utiliser NFSv4.1 sans configurer de mappage d'ID et n'utiliser que des ID utilisateur et des ID de groupe semblables à NFSv3, vous pouvez utiliser des ID numériques pour ignorer les principaux de sécurité. NetApp Volumes accepte les ID numériques, et les clients NFS actuels utilisent des ID numériques par défaut si la mise en correspondance des ID n'est pas configurée.
NFSv4.x avec Kerberos
Si vous utilisez Kerberos, vous devez impérativement utiliser Active Directory comme serveur LDAP pour les recherches d'entités de sécurité. Les comptes principaux Kerberos sont utilisés comme identifiants de sécurité. Active Directory est également utilisé comme centre de distribution de clés (KDC, Key Distribution Center) Kerberos. Pour ce faire, vous devez joindre une stratégie Active Directory contenant des paramètres Kerberos au pool et activer la prise en charge de LDAP sur un pool de stockage lors de sa création.
Pour en savoir plus, consultez Créer un pool de stockage.
Accès LDAP Active Directory
Pour les cas d'utilisation NFS, Active Directory est utilisé comme serveur LDAP. NetApp Volumes s'attend à des données d'identité utilisant un schéma RFC2307bis. Active Directory fournit déjà ce schéma, mais vous devez vous assurer de renseigner les attributs requis pour vos utilisateurs et groupes.
NetApp Volumes utilise les identifiants fournis par la stratégie Active Directory pour lier LDAP à l'aide de la signature LDAP.
Si l'utilisateur ou le groupe ne sont pas trouvés, l'accès est refusé.
Mise en cache des attributs
NetApp Volumes met en cache les résultats des requêtes LDAP. Le tableau suivant décrit les paramètres TTL (Time To Live) du cache LDAP. Si le cache contient des données non valides en raison de mauvaises configurations que vous essayez de corriger, vous devez attendre que le cache soit actualisé avant que vos modifications dans Active Directory ne soient détectées. Sinon, le serveur NFS continue d'utiliser les anciennes données pour valider l'accès, ce qui entraîne probablement des messages d'autorisation refusée sur le client. Une fois la période TTL écoulée, les entrées arrivent à expiration afin que les entrées obsolètes ne restent pas en attente. Les requêtes de recherche qui ne sont pas trouvées sont conservées pendant une minute pour éviter les problèmes de performances.
| Cache | Délai avant expiration par défaut |
|---|---|
| Liste des membres du groupe | Valeur TTL de 24 heures |
| Groupes Unix (GID) | TTL de 24 heures, TTL négatif de 1 minute |
| Utilisateurs Unix (UID) | TTL de 24 heures, TTL négatif de 1 minute |
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
Les sections suivantes illustrent différentes topologies possibles. Les diagrammes n'affichent que le contrôleur de domaine utilisé par NetApp Volumes. Les autres contrôleurs de domaine du même domaine ne s'affichent que si nécessaire.
Microsoft recommande de déployer au moins deux contrôleurs de domaine (CD) pour la redondance et la disponibilité.
Contrôleur de domaine Active Directory dans la même région que les volumes NetApp Volumes
Le schéma suivant illustre le mode de déploiement le plus simple, un contrôleur de domaine dans la même région que les volumes NetApp Volumes.
Contrôleurs de domaine Active Directory dans plusieurs régions à l'aide de sites AD
Si vous utilisez des volumes NetApp 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, il est recommandé de gérer la sélection du contrôleur de domaine à l'aide de sites AD.
Contrôleur de domaine Active Directory dans un réseau sur site
L'utilisation d'un contrôleur de domaine sur site via un VPN est prise en charge, mais 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 de VPC dans votre chemin réseau.
Éléments à prendre en compte pour les DC sur site
Les connexions aux contrôleurs de domaine sur site utilisent TCP et IP. Ces connexions échouent souvent en raison des limitations suivantes:
Appairage de VPC: les volumes NetApp ne peuvent atteindre que les nœuds de données situés sur le VPC du pool de stockage ou qui y sont connectés via un VPN. Les volumes NetApp ne peuvent pas atteindre les nœuds de données de n'importe quel autre VPC, y compris ceux qui sont appairés au VPC qui se connecte au pool de stockage.
Pare-feu: vous devez autoriser NetApp Volumes à contacter vos contrôleurs de domaine. Consultez les règles de pare-feu pour l'accès à Active Directory.
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 VPC Google Cloud n'autorise pas le routage transitif. Vous pouvez également associer des volumes NetApp à un réseau VPC partagé qui héberge les contrôleurs de domaine Active Directory. Si vous associez des volumes NetApp à un réseau VPC partagé, d'un point de vue architectural, ce scénario devient l'un des scénarios des sections précédentes.
Gérer les sélections de contrôleurs de domaine à l'aide de sites AD
Pour représenter au mieux les emplacements réels des centres de données, des bureaux et de la topologie réseau, placez les contrôleurs de domaine dans la même région que vos volumes et définissez un site Active Directory pour cette région.
Lorsque NetApp Volumes est connecté à votre domaine, le service utilise la découverte basée sur DNS pour trouver les contrôleurs de domaine avec lesquels communiquer. À l'aide des résultats de la découverte, le service gère une liste de DCD valides auxquels se connecter et utilise celui qui présente la latence la plus faible.
Lorsque vous spécifiez un site dans les paramètres Active Directory de NetApp Volumes, vous pouvez limiter la liste des contrôleurs de domaine à ceux spécifiés dans le site AD.
Si la sélection automatique du contrôleur de domaine échoue, vous pouvez utiliser des sites AD pour résoudre le problème:
Déployez au moins un contrôleur de domaine dans la région NetApp Volumes et associez-le à votre Active Directory existant.
Créez un site Active Directory pour votre région Google Cloud et placez-y les contrôleurs de domaine appropriés.
Utilisez le site Active Directory lorsque vous configurez des connexions Active Directory.
Pour vérifier manuellement la liste des contrôleurs de domaine potentiels que le service peut utiliser, consultez la section "Identifier les contrôleurs de domaine Active Directory utilisés par NetApp Volumes".
Pour en savoir plus, consultez Active Directory: considérations et bonnes pratiques de conception.