Partager via

Configurer le domaine ID NFSv4.1 pour Azure NetApp Files

  • Article

NFSv4 introduit le concept de domaine ID d’authentification. Azure NetApp Files utilise la valeur d’entrée defaultv4iddomain.com comme domaine d’authentification, et les clients NFS utilisent leur propre configuration pour authentifier les utilisateurs qui souhaitent accéder aux fichiers sur ces volumes. Par défaut, les clients NFS utilisent le nom de domaine DNS comme domaine d’ID NFSv4. Vous pouvez remplacer ce paramètre à l’aide du fichier de configuration NFSv4 nommé idmapd.conf.

Si les paramètres de domaine d’authentification sur le client NFS et Azure NetApp Files ne correspondent pas, l’accès aux fichiers peut être refusé, car l’utilisateur et le mappage de groupe NFSv4 peuvent échouer. Lorsque cela se produit, les utilisateurs et les groupes qui ne correspondent pas correctement écraseront l’utilisateur et le groupe configurés dans le fichier idmapd.conf (généralement, personne:99) et un événement sera enregistré sur le client.

Cet article explique le comportement par défaut du mappage utilisateur/groupe et comment configurer des clients NFS corrects pour s’authentifier correctement et autoriser l’accès. 

Comportement par défaut du mappage de l’utilisateur/groupe

Le mappage utilisateur racine peut illustrer ce qui se passe s’il existe une incompatibilité entre les clients Azure NetApp Files et NFS. Le processus d’installation d’une application nécessite souvent l’utilisation de l’utilisateur racine. Azure NetApp Files peut être configuré pour autoriser l’accès pour root.

Dans l’exemple de liste de répertoires suivant, l’utilisateur root monte un volume sur un client Linux qui utilise sa configuration par défaut localdomain pour le domaine d’authentification d’ID, différent de la configuration par défaut d’Azure NetApp Files defaultv4iddomain.com.

Capture d’écran de la sortie du répertoire de fichiers.

Dans la liste des fichiers du répertoire, file1 indique qu’ils sont mappés à nobody, quand ils doivent être détenus par l’utilisateur racine.

Il existe deux façons d’ajuster le domaine d’authentification des deux côtés : Azure NetApp Files en tant que serveur NFS et Linux en tant que clients NFS :

  1. Gestion centralisée des utilisateurs : si vous utilisez déjà une gestion centralisée des utilisateurs, comme Active Directory Domain Services (AD DS), vous pouvez configurer leurs clients Linux pour qu’ils utilisent LDAP et définir le domaine configuré dans AD DS comme domaine d’authentification. Côté serveur, vous devez activer le service de domaine AD pour Azure NetApp Files et créer des volumes compatibles LDAP. Les volumes compatibles LDAP utilisent automatiquement le domaine configuré dans AD DS comme domaine d’authentification.

    Pour plus d’informations sur ce processus, consultez Activer l’authentification LDAP Active Directory Domain Services (AD DS) pour les volumes NFS.

  2. Configurez manuellement le client Linux : si vous n’utilisez pas de gestion centralisée des utilisateurs pour vos clients Linux, vous pouvez configurer manuellement les clients Linux pour qu’ils correspondent au domaine d’authentification par défaut d’Azure NetApp Files pour les volumes non compatibles LDAP.

Dans cette section, nous allons nous concentrer sur la configuration du client Linux et sur la modification du domaine d’authentification Azure NetApp Files pour tous les volumes non compatibles LDAP.

Configurer le domaine ID NFSv4.1 sur Azure NetApp Files

Vous pouvez spécifier un domaine d’ID NFSv4.1 souhaité pour tous les volumes non LDAP à l’aide du portail Azure. Ce paramètre s’applique à tous les volumes non LDAP sur tous les comptes NetApp dans le même abonnement et la même région. Elle n’affecte pas les volumes compatibles LDAP dans le même abonnement et la même région NetApp.

Inscrire la fonctionnalité

Azure NetApp Files prend en charge la possibilité de définir le domaine d’ID NFSv4.1 pour tous les volumes non LDAP d’un abonnement à l’aide du portail Azure. Cette fonctionnalité est disponible actuellement en mode Aperçu. Vous devez inscrire la fonctionnalité avant de l’utiliser pour la première fois. Après l’inscription, la fonctionnalité est activée et fonctionne en arrière-plan.

  1. Inscrire la fonctionnalité

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Vérifiez l’état d’inscription de la fonctionnalité :

    Remarque

    RegistrationState peut rester à l’état Registering jusqu’à 60 minutes avant de passer à l’état Registered. Attendez que l'état soit Registered avant de continuer.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

Vous pouvez également utiliser les commandes Azure CLI az feature register et az feature show pour inscrire la fonctionnalité et afficher l’état de l’inscription.

Étapes

  1. Sous l’abonnement Azure NetApp Files, sélectionnez Domaine d’ID NFSv4.1.

  2. Sélectionnez Configurer.

  3. Pour utiliser le domaine par défaut defaultv4iddomain.com, sélectionnez la zone en regard à côté de Utiliser le domaine d’ID NFSv4 par défaut. Pour utiliser un autre domaine, décochez la zone de texte et indiquez le nom du domaine d’ID NFSv4.1.

    Capture d’écran avec le champ pour définir le domaine NFSv4.

  4. Cliquez sur Enregistrer.

Configurer le domaine d’ID NFSv4.1 dans les clients NFS

  1. Modifiez le fichier /etc/idmapd.conf sur le client NFS.
    Supprimez les marques de commentaire de la ligne #Domain (c’est-à-dire, supprimez le caractère # de la ligne), puis remplacez la valeur localdomain comme suit :

    • Si le volume n’est pas activé pour LDAP, utilisez le domaine par défaut defaultv4iddomain.com en spécifiant Domain = defaultv4iddomain.com, ou spécifiez le domaine d’ID NFSv4.1 tel que est configuré dans Azure NetApp Files.
    • Si le volume est activé pour LDAP, définissez Domain sur le domaine configuré dans la connexion Active Directory de votre compte NetApp. Par exemple, si contoso.com est le domaine configuré dans le compte NetApp, définissez Domain = contoso.com.

    Les exemples suivants illustrent la configuration initiale de /etc/idmapd.conf avant les modifications :

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    L’exemple suivant illustre la configuration mise à jour des volumes NFSv4.1 non LDAP pour le domaine par défaut defaultv4iddomain.com :

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    L’exemple suivant illustre la configuration mise à jour des volumes NFSv4.1 avec LDAP. Dans cet exemple, contoso.com est le domaine configuré dans le compte NetApp :

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. Démontez tout volume NFS monté.

  3. Mettre à jour le fichier /etc/idmapd.conf.

  4. Effacez le trousseau de clés du NFS idmapper (nfsidmap -c).

  5. Montez les volumes NFS selon les besoins.

    Consultez Monter un volume pour des machines virtuelles Windows ou Linux.

L’exemple suivant illustre la modification de l’utilisateur/groupe obtenue :

Capture d’écran montrant un exemple de la modification de groupe/d’utilisateur obtenue.

Comme le montre l’exemple, l’utilisateur/groupe est désormais passé de nobody à root.

Comportement d’autres utilisateurs et groupes (non racine)

Azure NetApp Files prend en charge les utilisateurs et groupes locaux (créés localement sur le client NFS et représentés par les ID d’utilisateur et de groupe) et les autorisations correspondantes associées aux fichiers ou dossiers dans les volumes NFSv4.1. Toutefois, le service ne résout pas automatiquement le mappage des utilisateurs et des groupes locaux sur les clients NFS. Les utilisateurs et les groupes créés sur un hôte peuvent ou non exister sur un autre client NFS (ou exister avec différents ID d’utilisateur et de groupe) et ne sont donc pas mappés correctement comme indiqué dans l’exemple ci-dessous.

Dans l’exemple suivant, Host1 a trois comptes d’utilisateur (testuser01, testuser02, testuser03) :

Capture d’écran montrant que Host1 a trois comptes d’utilisateur de test.

Sur Host2, aucun compte d’utilisateur correspondant n’existe, mais le même volume est monté sur les deux hôtes :

Configuration résultante pour NFSv4.1

Pour résoudre ce problème, créez les comptes manquants sur le client NFS ou configurez vos clients NFS pour utiliser le serveur LDAP utilisé par Azure NetApp Files pour les identités UNIX gérées de manière centralisée.

Étapes suivantes