Autres dépendances des services d'infrastructure NAS (KDC, LDAP et DNS)
Suggérer des modifications
PDF
Google Cloud NetApp volumes pour les partages NAS nécessite parfois des dépendances externes pour assurer le bon fonctionnement du système. Ces dépendances sont en jeu dans des circonstances spécifiques. Le tableau suivant présente différentes options de configuration et le cas échéant, quelles dépendances sont nécessaires.
| Configuration | Dépendances requises |
|---|---|
NFSv3 uniquement |
Aucune |
Kerberos NFSv3 uniquement |
Windows Active Directory : * KDC * DNS * LDAP |
NFSv4.1 uniquement |
Configuration du mappage d'ID client (/etc/idmap.conf) |
NFSv4.1 Kerberos uniquement |
|
PME uniquement |
Active Directory : * KDC * DNS |
NAS multiprotocole (NFS et SMB) |
|
La rotation/mot de passe de l'onglet clé Kerberos est réinitialisée pour les objets du compte machine
Pour les comptes de machine SMB, Google Cloud NetApp volumes planifie des réinitialisations périodiques du mot de passe pour le compte du serveur SMB. Ces réinitialisations de mot de passe se produisent à l'aide du chiffrement Kerberos et fonctionnent sur une programmation de tous les 4 dimanches à une heure aléatoire comprise entre 23 H et 1 H. Ces réinitialisations de mots de passe modifient les versions de clés Kerberos, font pivoter les onglets de clés stockés sur le système Google Cloud NetApp volumes et contribuent à maintenir un niveau de sécurité supérieur pour les serveurs SMB s'exécutant dans Google Cloud NetApp volumes. Les mots de passe du compte machine sont randomisés et ne sont pas connus des administrateurs.
Pour les comptes de machine Kerberos NFS, les réinitialisations de mot de passe n'ont lieu que lorsqu'un nouveau keytab est créé/échangé avec le KDC. Pour le moment, cette opération n'est pas possible dans Google Cloud NetApp volumes.
Ports réseau à utiliser avec LDAP et Kerberos
Lorsque vous utilisez LDAP et Kerberos, vous devez déterminer les ports réseau utilisés par ces services. Vous trouverez la liste complète des ports utilisés par Google Cloud NetApp volumes dans le "Documentation Google Cloud NetApp volumes sur les questions de sécurité".
LDAP
Google Cloud NetApp volumes agit en tant que client LDAP et utilise des requêtes de recherche LDAP standard pour les recherches d'utilisateurs et de groupes pour les identités UNIX. LDAP est nécessaire si vous prévoyez d'utiliser des utilisateurs et des groupes en dehors des utilisateurs par défaut standard fournis par Google Cloud NetApp volumes. LDAP est également nécessaire si vous prévoyez d'utiliser NFS Kerberos avec des principes utilisateur (tels que user1@domain.com). Actuellement, seul LDAP utilisant Microsoft Active Directory est pris en charge.
Pour utiliser Active Directory en tant que serveur LDAP UNIX, vous devez renseigner les attributs UNIX nécessaires pour les utilisateurs et groupes que vous souhaitez utiliser pour les identités UNIX. Google Cloud NetApp volumes utilise un modèle de schéma LDAP par défaut qui interroge les attributs surla base de "RFC-2307-bis" . Par conséquent, le tableau suivant montre les attributs Active Directory minimum requis pour remplir pour les utilisateurs et les groupes et pour quels attributs sont utilisés.
Pour plus d'informations sur la définition des attributs LDAP dans Active Directory, reportez-vous à la section "Gestion de l'accès double protocole."
| Attribut | Ce qu'il fait |
|---|---|
uid* |
Spécifie le nom d'utilisateur UNIX |
Numéro uidNumber* |
Spécifie l'ID numérique de l'utilisateur UNIX |
Numéro gidNumber* |
Spécifie l'ID numérique du groupe principal de l'utilisateur UNIX |
Objectclass* |
Spécifie le type d'objet utilisé ; Google Cloud NetApp volumes requiert que « utilisateur » soit inclus dans la liste des classes d'objet (inclus par défaut dans la plupart des déploiements Active Directory). |
nom |
Informations générales sur le compte (nom réel, numéro de téléphone, etc., également connu sous le nom de gecos) |
Mot de passe unixUserPassword |
Inutile de le définir ; non utilisé dans les recherches d'identité UNIX pour l'authentification NAS. Cette option place la valeur unixUserPassword configurée dans le texte en texte clair. |
UnixHomeDirectory |
Définit le chemin d'accès aux répertoires locaux UNIX lorsqu'un utilisateur s'authentifie auprès de LDAP à partir d'un client Linux. Définissez cette option si vous souhaitez utiliser la fonctionnalité de répertoire local LDAP pour UNIX. |
LoginShell |
Définit le chemin d'accès au shell bash/de profil pour les clients Linux lorsqu'un utilisateur s'authentifie auprès de LDAP. |
*Indique que l'attribut est requis pour que les fonctionnalités soient correctes avec Google Cloud NetApp volumes. Les autres attributs sont uniquement destinés à un usage côté client.
| Attribut | Ce qu'il fait |
|---|---|
cn* |
Spécifie le nom du groupe UNIX. Lors de l'utilisation d'Active Directory pour LDAP, ce paramètre est défini lors de la création de l'objet, mais il peut être modifié ultérieurement. Ce nom ne peut pas être identique à celui des autres objets. Par exemple, si votre utilisateur UNIX nommé user1 appartient à un groupe nommé user1 sur votre client Linux, Windows n'autorise pas deux objets avec le même attribut cn. Pour contourner ce problème, renommez l'utilisateur Windows en un nom unique (par exemple user1-UNIX). LDAP dans Google Cloud NetApp volumes utilise l'attribut uid pour les noms d'utilisateur UNIX. |
Numéro gidNumber* |
Spécifie l'ID numérique du groupe UNIX. |
Objectclass* |
Spécifie le type d'objet utilisé ; Google Cloud NetApp volumes exige que le groupe soit inclus dans la liste des classes d'objet (cet attribut est inclus par défaut dans la plupart des déploiements Active Directory). |
MemberUid |
Indique quels utilisateurs UNIX sont membres du groupe UNIX. Avec Active Directory LDAP dans Google Cloud NetApp volumes, ce champ n'est pas nécessaire. Le schéma LDAP de Google Cloud NetApp volumes utilise le champ membre pour les adhésions à des groupes. |
Membre* |
Requis pour les membres de groupe/groupes UNIX secondaires. Ce champ est rempli en ajoutant des utilisateurs Windows aux groupes Windows. Cependant, si les attributs UNIX des groupes Windows ne sont pas renseignés, ils ne sont pas inclus dans les listes d'appartenance aux groupes de l'utilisateur UNIX. Tous les groupes devant être disponibles dans NFS doivent remplir les attributs de groupe UNIX requis répertoriés dans ce tableau. |
*Indique que l'attribut est requis pour que les fonctionnalités soient correctes avec Google Cloud NetApp volumes. Les autres attributs sont uniquement destinés à un usage côté client.
Informations de liaison LDAP
Pour interroger les utilisateurs dans LDAP, Google Cloud NetApp volumes doit lier (se connecter) au service LDAP. Cette connexion possède des autorisations en lecture seule et est utilisée pour interroger les attributs LDAP UNIX pour les recherches de répertoire. Actuellement, les liaisons LDAP ne sont possibles qu'à l'aide d'un compte de machine SMB.
Vous pouvez activer LDAP pour les instances et l'utiliser uniquement NetApp Volumes-Performance pour les volumes NFS v3, NFS v4.1 ou à double protocole. Pour que le déploiement du volume LDAP soit réussi, une connexion Active Directory doit être établie dans la même région que le volume Google Cloud NetApp volumes.
Lorsque LDAP est activée, les opérations suivantes se produisent dans des scénarios spécifiques.
-
Si seul NFS v3 ou NFS v4.1 est utilisé pour le projet Google Cloud NetApp volumes, un nouveau compte de machine est créé dans le contrôleur de domaine Active Directory et le client LDAP dans Google Cloud NetApp volumes se lie à Active Directory en utilisant les informations d'identification du compte de machine. Aucun partage SMB n'est créé pour le volume NFS et les partages d'administration masqués par défaut (voir la section "« Partages masqués par défaut »") ont supprimé les ACL de partage.
-
Si des volumes à double protocole sont utilisés pour le projet Google Cloud NetApp volumes, seul le compte de machine unique créé pour l'accès SMB est utilisé pour lier le client LDAP dans Google Cloud NetApp volumes à Active Directory. Aucun compte machine supplémentaire n'est créé.
-
Si des volumes SMB dédiés sont créés séparément (avant ou après l'activation des volumes NFS avec LDAP), le compte machine pour les liaisons LDAP est partagé avec le compte de machine SMB.
-
Si NFS Kerberos est également activé, deux comptes machine sont créés : un pour les partages SMB et/ou des liaisons LDAP et un pour l'authentification Kerberos NFS.
Requêtes LDAP
Bien que les liaisons LDAP soient cryptées, les requêtes LDAP sont transmises sur le réseau en texte clair à l'aide du port LDAP commun 389. Ce port connu ne peut pas être modifié dans Google Cloud NetApp volumes pour le moment. Par conséquent, une personne ayant accès au sniffing de paquets dans le réseau peut voir les noms d'utilisateur et de groupe, les ID numériques et les appartenances de groupe.
Cependant, les machines virtuelles Google Cloud ne peuvent pas sniff le trafic unicast d'autres machines virtuelles. Seules les machines virtuelles participant activement au trafic LDAP (c'est-à-dire en mesure de lier) peuvent voir le trafic à partir du serveur LDAP. Pour plus d'informations sur l'reniflage de paquets dans Google Cloud NetApp volumes, consultez la section "“Considérations sur la capture et la détection des paquets.”"
Paramètres par défaut de configuration du client LDAP
Lorsque LDAP est activé dans une instance Google Cloud NetApp volumes, une configuration client LDAP est créée avec des détails de configuration spécifiques par défaut. Dans certains cas, les options ne s'appliquent pas à Google Cloud NetApp volumes (non pris en charge) ou ne sont pas configurables.
| Option client LDAP | Ce qu'il fait | Valeur par défaut | Est-il possible de modifier ? |
|---|---|---|---|
Liste des serveurs LDAP |
Définit les noms de serveur LDAP ou les adresses IP à utiliser pour les requêtes. Ceci n'est pas utilisé pour Google Cloud NetApp volumes. À la place, Active Directory Domain est utilisé pour définir les serveurs LDAP. |
Non défini |
Non |
Domaine Active Directory |
Définit le domaine Active Directory à utiliser pour les requêtes LDAP. Google Cloud NetApp volumes exploite les enregistrements SRV pour LDAP dans DNS afin de trouver les serveurs LDAP dans le domaine. |
Définissez le domaine Active Directory spécifié dans la connexion Active Directory. |
Non |
Serveurs Active Directory préférés |
Définit les serveurs Active Directory préférés à utiliser pour LDAP. Non pris en charge par Google Cloud NetApp volumes. Utilisez plutôt les sites Active Directory pour contrôler la sélection du serveur LDAP. |
Non défini. |
Non |
Lier à l'aide des informations d'identification du serveur SMB |
Se lie à LDAP à l'aide du compte de machine SMB. Actuellement, la seule méthode de liaison LDAP prise en charge dans Google Cloud NetApp volumes. |
Vrai |
Non |
Modèle de schéma |
Modèle de schéma utilisé pour les requêtes LDAP. |
MS-AD-BIS |
Non |
Port du serveur LDAP |
Numéro de port utilisé pour les requêtes LDAP. Google Cloud NetApp volumes utilise actuellement uniquement le port LDAP standard 389. Le port LDAPS/636 n'est pas pris en charge actuellement. |
389 |
Non |
LDAPS est activé |
Contrôle si LDAP sur SSL (Secure Sockets Layer) est utilisé pour les requêtes et les liaisons. Google Cloud NetApp volumes n'est actuellement pas pris en charge. |
Faux |
Non |
Délai d'expiration de la requête (secondes) |
Délai d'attente pour les requêtes. Si les requêtes prennent plus de temps que la valeur spécifiée, les requêtes échouent. |
3 |
Non |
Niveau d'authentification de liaison minimum |
Niveau de liaison minimum pris en charge. Étant donné que Google Cloud NetApp volumes utilise des comptes de machine pour les liaisons LDAP et qu'Active Directory ne prend pas en charge les liaisons anonymes par défaut, cette option ne joue pas le rôle de sécurité. |
Anonyme |
Non |
Lier DN |
Nom d'utilisateur/nom distinctif (DN) utilisé pour les liaisons lorsque la liaison simple est utilisée. Google Cloud NetApp volumes utilise des comptes de machine pour les liaisons LDAP et ne prend pas actuellement en charge l'authentification de liaison simple. |
Non défini |
Non |
DN de base |
Le DN de base utilisé pour les recherches LDAP. |
Le domaine Windows utilisé pour la connexion Active Directory, au format DN (c.c.=domaine, c.c.=local). |
Non |
Étendue de la recherche de base |
Domaine de recherche pour les recherches de DN de base. Les valeurs peuvent inclure la base, l'élévation ou la sous-arborescence. Google Cloud NetApp volumes ne prend en charge que les recherches dans la sous-arborescence. |
Sous-arbre |
Non |
Nom unique de l'utilisateur |
Définit le DN où l'utilisateur recherche les requêtes LDAP. Actuellement, les recherches d'utilisateurs ne sont pas prises en charge pour Google Cloud NetApp volumes. Elles commencent donc toutes par le DN de base. |
Non défini |
Non |
Étendue de la recherche utilisateur |
Domaine de recherche pour les recherches de DN utilisateur. Les valeurs peuvent inclure la base, l'élévation ou la sous-arborescence. Google Cloud NetApp volumes ne prend pas en charge la définition de l'étendue de la recherche d'utilisateurs. |
Sous-arbre |
Non |
DN du groupe |
Définit le DN où le groupe recherche les requêtes LDAP. Actuellement, les recherches de groupe ne sont pas prises en charge pour Google Cloud NetApp volumes. Elles commencent donc toutes par le DN de base. |
Non défini |
Non |
Étendue de la recherche de groupe |
Domaine de recherche pour les recherches de DN de groupe. Les valeurs peuvent inclure la base, l'élévation ou la sous-arborescence. Google Cloud NetApp volumes ne prend pas en charge la définition de la portée de la recherche de groupe. |
Sous-arbre |
Non |
DN du groupe réseau |
Définit le DN où le groupe réseau recherche les requêtes LDAP. Actuellement, les recherches de groupes réseau ne sont pas prises en charge pour Google Cloud NetApp volumes. Elles commencent donc toutes par le DN de base. |
Non défini |
Non |
Domaine de recherche de groupe réseau |
Domaine de recherche pour les recherches de DN de groupe réseau. Les valeurs peuvent inclure la base, l'élévation ou la sous-arborescence. Google Cloud NetApp volumes ne prend pas en charge la définition de la portée de recherche de groupe réseau. |
Sous-arbre |
Non |
Utilisez START_tls sur LDAP |
Utilise Start TLS pour les connexions LDAP basées sur des certificats via le port 389. Google Cloud NetApp volumes n'est actuellement pas pris en charge. |
Faux |
Non |
Activez la recherche netgroup-by-host |
Active les recherches de groupe réseau par nom d'hôte plutôt que d'étendre les groupes réseau pour répertorier tous les membres. Google Cloud NetApp volumes n'est actuellement pas pris en charge. |
Faux |
Non |
DN netgroup-by-host |
Définit le DN où les recherches de netgroup-par-hôte commencent pour les requêtes LDAP. Netgroup-by-host n'est actuellement pas pris en charge pour Google Cloud NetApp volumes. |
Non défini |
Non |
Étendue de recherche netgroup-by-host |
Étendue de recherche pour les recherches de DN netgroup-par-hôte. Les valeurs peuvent inclure la base, l'élévation ou la sous-arborescence. Netgroup-by-host n'est actuellement pas pris en charge pour Google Cloud NetApp volumes. |
Sous-arbre |
Non |
Sécurité de session client |
Définit le niveau de sécurité de session utilisé par LDAP (signe, sceau ou aucun). La signature LDAP est prise en charge par NetApp volumes-Performance, si Active Directory en fait la demande. NetApp volumes-SW ne prend pas en charge la signature LDAP. Pour les deux types d'entretien, le scellage n'est actuellement pas pris en charge. |
Aucune |
Non |
Renvoi LDAP à la recherche |
Lors de l'utilisation de plusieurs serveurs LDAP, la recherche de références permet au client de se référer à d'autres serveurs LDAP de la liste lorsqu'une entrée est introuvable dans le premier serveur. Ce n'est pas pris en charge par Google Cloud NetApp volumes pour le moment. |
Faux |
Non |
Filtre d'appartenance au groupe |
Fournit un filtre de recherche LDAP personnalisé à utiliser lors de la recherche d'appartenance à un groupe à partir d'un serveur LDAP. Google Cloud NetApp volumes n'est pas pris en charge actuellement. |
Non défini |
Non |
Utilisation de LDAP pour le mappage de noms asymétrique
Google Cloud NetApp volumes mappe par défaut les utilisateurs Windows et UNIX avec des noms d'utilisateur identiques dans les deux directions, sans configuration spéciale. Tant que Google Cloud NetApp volumes trouve un utilisateur UNIX valide (avec LDAP), le mappage de noms 1:1 a lieu. Par exemple, si un utilisateur Windows johnsmith est utilisé, si Google Cloud NetApp volumes trouve un utilisateur UNIX nommé johnsmith dans LDAP, le mappage de noms réussit pour cet utilisateur, tous les fichiers/dossiers créés par johnsmith indiquent la propriété correcte de l'utilisateur et toutes les listes de contrôle d'accès affectant johnsmith sont respectées, quel que soit le protocole NAS utilisé. Il s'agit d'un mappage de nom symétrique.
Le mappage de nom asymétrique est utilisé lorsque l'identité utilisateur Windows et l'identité utilisateur UNIX ne correspondent pas. Par exemple, si un utilisateur Windows johnsmith possède une identité UNIX de jsmith, Google Cloud NetApp volumes doit être doté d'un moyen de parler de cette variation. Google Cloud NetApp volumes ne prenant actuellement pas en charge la création de règles de mappage de noms statiques, LDAP doit être utilisé pour rechercher l'identité des utilisateurs pour les identités Windows et UNIX afin d'assurer la propriété correcte des fichiers et dossiers ainsi que les autorisations attendues.
Par défaut, Google Cloud NetApp volumes inclut LDAP dans le commutateur ns de l'instance de la base de données de mappage de noms. Afin d'offrir une fonctionnalité de mappage de noms à l'aide de LDAP pour les noms asymétriques, il suffit de modifier certains attributs d'utilisateur/de groupe pour refléter ce que recherche Google Cloud NetApp volumes recherche.
Le tableau suivant indique quels attributs doivent être renseignés dans LDAP pour la fonctionnalité de mappage de noms asymétriques. Dans la plupart des cas, Active Directory est déjà configuré pour le faire.
| Attribut Google Cloud NetApp volumes | Ce qu'il fait | Valeur utilisée par Google Cloud NetApp volumes pour le mappage de noms |
|---|---|---|
ObjectClass de Windows à UNIX |
Spécifie le type d'objet utilisé. (C'est-à-dire utilisateur, groupe, posixAccount, etc.) |
Doit inclure l'utilisateur (peut contenir plusieurs autres valeurs, si nécessaire). |
Attribut Windows à UNIX |
Qui définit le nom d'utilisateur Windows lors de sa création. Google Cloud NetApp volumes l'utilise pour les recherches Windows vers UNIX. |
Aucune modification n'est nécessaire ici ; sAMAccountName est identique au nom de connexion Windows. |
UID |
Définit le nom d'utilisateur UNIX. |
Nom d'utilisateur UNIX souhaité. |
Google Cloud NetApp volumes n'utilise actuellement pas de préfixes de domaine dans les recherches LDAP, de sorte que les environnements LDAP à plusieurs domaines ne fonctionnent pas correctement avec les recherches de noms LDAP.
L'exemple suivant montre un utilisateur portant le nom Windows asymmetric, Le nom UNIX unix-user, Et le comportement suivant lors de l'écriture de fichiers à partir de SMB et NFS.
La figure suivante montre l'apparence des attributs LDAP à partir du serveur Windows.
À partir d'un client NFS, vous pouvez interroger le nom UNIX mais pas le nom Windows :
# id unix-user uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup) # id asymmetric id: asymmetric: no such user
Lorsqu'un fichier est écrit à partir de NFS en tant que unix-user, Le résultat suivant est celui du client NFS :
sh-4.2$ pwd /mnt/home/ntfssh-4.2$ touch unix-user-file sh-4.2$ ls -la | grep unix-user -rwx------ 1 unix-user sharedgroup 0 Feb 28 12:37 unix-user-nfs sh-4.2$ id uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup)
À partir d'un client Windows, vous pouvez voir que le propriétaire du fichier est défini sur l'utilisateur Windows approprié :
PS C:\ > Get-Acl \\demo\home\ntfs\unix-user-nfs | select Owner Owner ----- NTAP\asymmetric
Inversement, les fichiers créés par l'utilisateur Windows asymmetric À partir d'un client SMB, montrer le propriétaire UNIX approprié, comme indiqué dans le texte suivant.
SMB :
PS Z:\ntfs> echo TEXT > asymmetric-user-smb.txt
NFS :
sh-4.2$ ls -la | grep asymmetric-user-smb.txt -rwx------ 1 unix-user sharedgroup 14 Feb 28 12:43 asymmetric-user-smb.txt sh-4.2$ cat asymmetric-user-smb.txt TEXT
Liaison de canal LDAP
En raison d'une vulnérabilité avec les contrôleurs de domaine Windows Active Directory, "Avis de sécurité de Microsoft ADV190023" Modifie la façon dont le DCS autorise les liaisons LDAP.
L'impact sur Google Cloud NetApp volumes est le même que sur tout client LDAP. Google Cloud NetApp volumes ne prend pas actuellement en charge la liaison de canaux. Google Cloud NetApp volumes prend en charge la signature LDAP par défaut via la négociation. La liaison du canal LDAP ne devrait donc pas poser de problème. Si vous rencontrez des problèmes de liaison avec LDAP avec la liaison de canal activée, suivez les étapes de correction de l'ADV190023 pour permettre la réussite des liaisons LDAP depuis Google Cloud NetApp volumes.
DNS
Active Directory et Kerberos ont tous deux des dépendances sur DNS pour la résolution du nom d'hôte à IP/IP vers le nom d'hôte. Le DNS requiert l'ouverture du port 53. Google Cloud NetApp volumes ne modifie pas les enregistrements DNS et ne prend pas en charge l'utilisation de "DNS dynamique" sur les interfaces réseau.
Vous pouvez configurer Active Directory DNS pour limiter les serveurs qui peuvent mettre à jour les enregistrements DNS. Pour plus d'informations, voir "Un DNS Windows sécurisé".
Notez que les ressources d'un projet Google utilisent par défaut Google Cloud DNS, qui n'est pas connecté à Active Directory DNS. Les clients utilisant un DNS cloud ne peuvent pas résoudre les chemins UNC renvoyés par Google Cloud NetApp volumes. Les clients Windows joints au domaine Active Directory sont configurés pour utiliser Active Directory DNS et peuvent résoudre de tels chemins UNC.
Pour joindre un client à Active Directory, vous devez configurer sa configuration DNS pour utiliser Active Directory DNS. Vous pouvez également configurer Cloud DNS pour transférer les demandes vers Active Directory DNS. Voir "Pourquoi mon client ne parvient-il pas à résoudre le nom NetBIOS du SMB ?"pour en savoir plus.
|
Google Cloud NetApp volumes ne prend pas actuellement en charge DNSSEC et les requêtes DNS s'effectuent en texte brut. |
Audit de l'accès aux fichiers
Actuellement, Google Cloud NetApp volumes n'est pas pris en charge.
Protection antivirus
Vous devez effectuer une analyse antivirus dans Google Cloud NetApp volumes au niveau du client vers un partage NAS. Il n'existe actuellement pas d'intégration antivirus native avec Google Cloud NetApp volumes.