Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsqu’un utilisateur tente d’accéder à un volume Azure NetApp Files via NFS, la requête est contenue dans un ID numérique. Par défaut, Azure NetApp Files prend en charge les appartenances aux groupes étendues aux utilisateurs NFS (pour aller au-delà de la limite standard de groupe de 16). Par conséquent, Azure NetApp Files tente de prendre cet ID numérique et de le rechercher dans protocole LDAP (Lightweight Directory Access Protocol) dans une tentative de résolution des appartenances aux groupes pour l’utilisateur plutôt que de passer les appartenances au groupe dans un paquet RPC. En raison de ce comportement, si cet ID numérique ne peut pas être résolu en LDAP, la recherche échoue et l’accès est refusé. Ce déni se produit même si l’utilisateur demandeur a l’autorisation d’accéder au volume ou à la structure de données.
L’option autoriser les utilisateurs NFS locaux avec LDAP dans les connexions Active Directory sert à désactiver ces recherches LDAP pour les requêtes NFS en désactivant la fonctionnalité de groupe étendue. Elle ne permet pas la fonctionnalité « création/gestion d’utilisateurs locaux » dans Azure NetApp Files.
Lorsque l’option « autoriser les utilisateurs NFS locaux avec LDAP » est activée, les ID numériques sont transmis à Azure NetApp Files et aucune recherche LDAP ne se produit. Cela crée un comportement variable pour différents scénarios, comme indiqué ci-dessous.
NFSv3 avec des volumes de style de sécurité UNIX
Les ID numériques n’ont pas besoin d’être traduits en noms d’utilisateur. L’option « Autoriser les utilisateurs NFS locaux avec LDAP » n’affecte pas l’accès au volume. Elle peut affecter la façon dont la propriété utilisateur/groupe (traduction de noms) s’affiche sur le client NFS. Par exemple, si un ID numérique de 1001 est utilisateur1 dans le protocole LDAP, mais qu’il est utilisateur2 sur le fichier passwd local du client NFS, le client « utilisateur2 » sera affiché comme propriétaire du fichier lorsque l’ID numérique est 1001.
NFSv4.1 avec des volumes de style de sécurité UNIX
Les ID numériques n’ont pas besoin d’être traduits en noms d’utilisateur. Par défaut, NFSv4.1 utilise des chaînes de noms (user@CONTOSO.COM) pour son authentification. Toutefois, Azure NetApp Files prend en charge l’utilisation d’ID numériques avec NFSV4.1, ce qui signifie que les requêtes NFSv4.1 arrive au serveur NFS avec un ID numérique. S’il n’existe aucun ID numérique pour la traduction de noms d’utilisateur dans les fichiers locaux ou les services de noms comme le protocole LDAP pour le volume Azure NetApp Files, le nombre est présenté au client. Si un ID numérique est traduit par un nom d’utilisateur, la chaîne de nom est utilisée. Si la chaîne de nom ne correspond pas, le client écrase le nom par l'utilisateur anonyme spécifié dans le fichier idmapd.conf du client. L’activation de l’option « Autoriser les utilisateurs NFS locaux avec LDAP » n’affecte pas l’accès NFSv4.1. Access revient au comportement NFSv3 standard, sauf si Azure NetApp Files peut résoudre un ID numérique en un nom d’utilisateur dans sa base de données utilisateur NFS locale. Azure NetApp Files a un ensemble d’utilisateurs UNIX par défaut qui peuvent être problématiques pour certains clients et écraser un utilisateur « personne » si les chaînes d’ID de domaine ne correspondent pas.
- Les utilisateurs locaux incluent : racine (0), pcuser (65534), personne (65535).
- Les groupes locaux incluent : racine (0), démon (1), pcuser (65534), personne (65535).
Souvent, la racine peut généralement s’afficher incorrectement dans les montages clients NFSv4.1 lorsque l’ID de domaine NFSv4.1 est mal configuré. Pour plus d’informations sur le domaine d’ID NFSv4.1, consultez la section configuration du domaine d’ID NFSv4.1 pour Azure NetApp Files.
Les listes de contrôle d’accès NFSv4.1 peuvent être configurées à l’aide d’une chaîne de nom ou d’un ID numérique. Si des ID numériques sont utilisés, aucune traduction de nom n’est requise. Si une chaîne de nom est utilisée, la traduction de noms est requise pour une résolution de liste de contrôle d’accès appropriée. Lorsque vous utilisez des listes de contrôle d’accès NFSv4.1, activer « autoriser les utilisateurs NFS locaux avec LDAP » peut entraîner un comportement de liste de contrôle d’accès NFSv4.1 incorrect en fonction de la configuration de la liste de contrôle d’accès.
NFS (NFSv3 et NFSv4.1) avec des volumes de style de sécurité NTFS dans des configurations à double protocole
Les volumes de style de sécurité UNIX tirent parti des autorisations de style UNIX (bits de mode et listes de contrôle d’accès NFSv4.1). Pour ces types de volumes, NFS utilise uniquement l’authentification de style UNIX en tirant parti d’un ID numérique ou d’une chaîne de nom, selon les scénarios répertoriés ci-dessus.
Toutefois, les volumes de style de sécurité NTFS utilisent des autorisations de style NTFS. Ces autorisations sont attribuées à l’aide d’utilisateurs et de groupes Windows. Lorsqu’un utilisateur NFS tente d’accéder à un volume avec une autorisation de style NTFS, un mappage de noms UNIX vers Windows doit est indispensable pour garantir des contrôles d’accès appropriés. Dans ce scénario, l’ID numérique NFS est toujours transmis au volume NFS Azure NetApp Files, mais il est nécessaire que l’ID numérique soit traduit en nom d’utilisateur UNIX afin qu’il puisse ensuite être mappé à un nom d’utilisateur Windows pour l’authentification initiale. Par exemple, si l’ID numérique 1001 tente d’accéder à un montage NFS avec des autorisations de style de sécurité NTFS qui autorisent l’accès à l’utilisateur Windows « utilisateur1 », alors 1001 doit être résolu dans le protocole LDAP avec le nom d’utilisateur « utilisateur1 » pour obtenir l’accès attendu. Si aucun utilisateur avec l’ID numérique « 1001 » n’existe dans LDAP, ou si LDAP est mal configuré, le mappage de noms UNIX sur Windows termine la tentative avec 1001@contoso.com. Dans la plupart des cas, les utilisateurs portant ce nom n’existent pas. Par conséquent, l’authentification échoue et l’accès est refusé. De même, si l’ID numérique 1001 se résout au nom d’utilisateur incorrect (par exemple, utilisateur2), la requête NFS est mappée à l’utilisateur Windows incorrect (dans ce scénario, l’utilisateur1 a l’accès accordé à l’utilisateur2).
L’activation de l’option « Autoriser les utilisateurs NFS locaux avec LDAP » désactive toutes les traductions LDAP d’ID numériques aux noms d’utilisateur. Cette action interrompt efficacement l’accès aux volumes de style de sécurité NTFS. Par conséquent, l’utilisation de cette option avec des volumes de style de sécurité NTFS est déconseillée.