Partager via

Configurer le domaine d’ID NFSv4.1 pour Azure NetApp Files

  • Article

NFSv4 introduit le concept d’un domaine d’authentification d’ID. Azure NetApp Files utilise la valeur defaultv4iddomain.com d’entrée 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 squashing l’utilisateur et le groupe configurés dans le idmapd.conf fichier (généralement, personne :99) et un événement est 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 localdomain par défaut pour le domaine d’authentification d’ID, différent de la configuration par défaut d’Azure NetApp Files.defaultv4iddomain.com

Screenshot of file directory output.

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 services de domaine Active Directory (AD DS), vous pouvez configurer leurs clients Linux pour utiliser 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 services de domaine Active Directory (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 d’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 CLIaz 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, sélectionnez la zone en regard d’Utiliser le domaine defaultv4iddomain.comd’ID NFSv4 par défaut. Pour utiliser un autre domaine, annulez case activée la zone de texte et indiquez le nom du domaine d’ID NFSv4.1.

    Screenshot with field to set NFSv4 domain.

  4. Sélectionnez 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 defaultv4iddomain.com par défaut en spécifiant Domain = defaultv4iddomain.com, ou spécifiez le domaine d’ID NFSv4.1 tel qu’il 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 montrent la configuration initiale d’avant /etc/idmapd.conf 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 montre la configuration mise à jour des volumes non LDAP NFSv4.1 pour le domaine defaultv4iddomain.compar défaut :

    [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 keyring 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 :

Screenshot that shows an example of the resulting user/group change.

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

Comportement d’autres utilisateurs et groupes (nonroot)

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, , testuser02testuser03) :

Screenshot that shows that Host1 has three existing test user accounts.

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

Resulting configuration for 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