Comprendre l’utilisation du protocole LDAP avec Azure NetApp Files

Article
06/17/2024

Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole standard d’accès aux annuaires développé par le groupe de travail IETF (Internet Engineering Task Force). Le protocole LDAP est conçu pour fournir un service d’annuaire à usage général basé sur le réseau que vous pouvez utiliser sur plusieurs plateformes hétérogènes pour localiser des objets réseau.

Les modèles LDAP définissent comment communiquer avec le magasin d’annuaires LDAP, rechercher un objet dans l’annuaire, décrire les objets du magasin et la sécurité utilisée pour accéder à l’annuaire. Le protocole LDAP permet la personnalisation et l’extension des objets décrits dans le magasin. Par conséquent, vous pouvez utiliser un magasin LDAP pour stocker de nombreux types d’informations diverses. Bon nombre des déploiements initiaux du protocole LDAP se sont concentrés sur son utilisation comme magasin d’annuaires pour des applications telles que les e-mails et les applications web, ainsi que pour stocker des informations sur les employés. De nombreuses entreprises remplacent ou ont remplacé le service NIS (Network Information Service) par le protocole LDAP en tant que magasin d’annuaires réseau.

Un serveur LDAP fournit des identités d’utilisateur et de groupe UNIX à utiliser avec des volumes NAS. Dans Azure NetApp Files, Active Directory est le seul serveur LDAP actuellement pris en charge qui peut être utilisé. Ce support inclut la prise en charge d’Active Directory Domain Services (AD DS) et de Microsoft Entra Domain Services.

Les requêtes LDAP peuvent être divisées en deux opérations principales.

Les liaisons LDAP sont des connexions au serveur LDAP à partir d’un client LDAP. La liaison est utilisée pour s’authentifier auprès du serveur LDAP avec un accès en lecture seule pour effectuer des recherches LDAP. Azure NetApp Files agit en tant que client LDAP.
Les recherches LDAP sont utilisées pour interroger l’annuaire pour obtenir des informations d’utilisateur et de groupe, telles que des noms, des ID numériques, des chemins d’accès d’annuaire de base, des chemins d’interpréteur de commandes de connexion, des appartenances aux groupes, etc.

Le protocole LDAP peut stocker les informations suivantes utilisées dans l’accès NAS double protocole :

Noms d’utilisateur
Noms de groupe
ID numériques d’utilisateur (UID) et ID de groupe (GID)
Répertoires de base
Interpréteur de commandes de connexion
Groupes réseau, noms DNS et adresses IP
Appartenance au groupe

Actuellement, Azure NetApp Files utilise uniquement le protocole LDAP pour les informations d’utilisateur et de groupe, mais pas pour les groupes réseau ou informations d’hôte.

Le protocole LDAP offre différents avantages pour vos utilisateurs et groupes UNIX en tant que source d’identité.

Le protocole LDAP est durable.
À mesure que d’autres clients NFS ajoutent la prise en charge de NFSv4.x, les domaines d’ID NFSv4.x qui contiennent une liste à jour d’utilisateurs et de groupes accessibles à partir des clients et du stockage sont nécessaires pour garantir une sécurité optimale et un accès garanti lorsque l’accès est défini. Avoir un serveur de gestion des identités qui fournit des mappages de noms un à un pour les utilisateurs SMB et NFS simplifie considérablement la vie des administrateurs de stockage, non seulement aujourd’hui, mais pour les années à venir.
Le protocole LDAP est évolutif.
Les serveurs LDAP offrent la possibilité de contenir des millions d’objets utilisateur et de groupe, et avec Microsoft Active Directory, plusieurs serveurs peuvent être utilisés pour répliquer sur plusieurs sites, pour une mise à l’échelle des performances et de la résilience.
Le protocole LDAP est sécurisé.
Le protocole LDAP assure la sécurité par la façon dont un système de stockage peut se connecter au serveur LDAP pour effectuer des demandes d’informations utilisateur. Les serveurs LDAP offrent les niveaux de liaison suivants :
- Anonyme (désactivé par défaut dans Microsoft Active Directory, non pris en charge dans Azure NetApp Files)
- Mot de passe simple (mots de passe en texte brut, non pris en charge dans Azure NetApp Files)
- SASL (Simple Authentication and Security Layer) : méthodes de liaison chiffrées, notamment TLS, SSL, Kerberos, et ainsi de suite. Azure NetApp Files prend en charge LDAP via TLS, la signature LDAP (à l’aide de Kerberos) et LDAP via SSL.
Le protocole LDAP est robuste.
NIS, NIS+ et les fichiers locaux offrent des informations de base : UID, GID, mot de passe, annuaires de base, etc. Toutefois, le protocole LDAP offre ces attributs et bien plus encore. Les attributs supplémentaires que le protocole LDAP utilise rendent la gestion du double protocole beaucoup plus intégrée avec le protocole LDAP par rapport à NIS. Seul le protocole LDAP est pris en charge en tant que service de nom externe pour la gestion des identités avec Azure NetApp Files.
Microsoft Active Directory repose sur le protocole LDAP.
Par défaut, Microsoft Active Directory utilise un serveur principal LDAP pour ses entrées utilisateur et de groupe. Toutefois, cette base de données LDAP ne contient pas d’attributs de style UNIX. Ces attributs sont ajoutés lorsque le schéma LDAP est étendu via Gestion des identités pour UNIX (Windows 2003R2 et versions ultérieures), Service pour UNIX (Windows 2003 et versions antérieures) ou des outils LDAP tiers tels que Centrify. Étant donné que Microsoft utilise le protocole LDAP comme protocole principal, c’est la solution idéale pour les environnements qui choisissent d’exploiter des volumes à double protocole dans Azure NetApp Files.

Remarque

Actuellement, Azure NetApp Files prend uniquement en charge Microsoft Active Directory natif pour les services LDAP.

Principes de base du protocole LDAP dans Azure NetApp Files

La section suivante décrit les principes de base du protocole LDAP en ce qui concerne Azure NetApp Files.

Les informations LDAP sont stockées dans des fichiers plats dans un serveur LDAP et sont organisées par le biais d’un schéma LDAP. Vous devez configurer les clients LDAP de manière à coordonner leurs requêtes et leurs recherches avec le schéma sur le serveur LDAP.
Les clients LDAP lancent des requêtes par le biais d’une liaison LDAP, ce qui revient à une connexion au serveur LDAP à l’aide d’un compte disposant d’un accès en lecture au schéma LDAP. La configuration de liaison LDAP sur les clients est configurée pour utiliser le mécanisme de sécurité défini par le serveur LDAP. Parfois, ce sont des échanges de noms d’utilisateur et de mots de passe en texte brut (simple). Dans d’autres cas, les liaisons sont sécurisées par des méthodes de SASL (sasl) telles que Kerberos ou LDAP via TLS. Azure NetApp Files utilise le compte d’ordinateur SMB pour établir une liaison à l’aide de l’authentification SASL pour une sécurité optimale.
Les informations d’utilisateur et de groupe stockées dans le protocole LDAP sont interrogées par les clients à l’aide de requêtes de recherche LDAP standard définies dans RFC 2307. De plus, les mécanismes plus récents, tels que RFC 2307bis, permettent de simplifier les recherches d’utilisateurs et de groupes. Azure NetApp Files utilise un formulaire de RFC 2307bis pour ses recherches de schémas dans Windows Active Directory.
Les serveurs LDAP peuvent stocker les informations d’utilisateur et de groupe, et le groupe réseau. Toutefois, Azure NetApp Files ne peut actuellement pas utiliser la fonctionnalité groupe réseau du protocole LDAP sur Windows Active Directory.
Le protocole LDAP dans Azure NetApp Files fonctionne sur le port 389. Ce port ne peut actuellement pas être modifié pour utiliser un port personnalisé, tel que le port 636 (LDAP via SSL) ou le port 3268 (recherches dans le catalogue global Active Directory).
Les communications LDAP chiffrées peuvent être obtenues à l’aide de LDAP via TLS (qui fonctionne sur le port 389) ou la signature LDAP, qui peuvent être configurés sur la connexion Active Directory.
Azure NetApp Files prend en charge les requêtes LDAP qui ne prennent pas plus de 3 secondes. Si le serveur LDAP a de nombreux objets, ce délai d’expiration peut être dépassé et les demandes d’authentification peuvent échouer. Dans ce cas, il est possible de spécifier une étendue de recherche LDAP pour filtrer les requêtes afin d’obtenir de meilleures performances.
Azure NetApp Files prend également en charge la spécification de serveurs LDAP préférés pour accélérer les requêtes. Utilisez ce paramètre si vous souhaitez vous assurer que le serveur LDAP le plus proche de votre région Azure NetApp Files est utilisé.

Si aucun serveur LDAP préféré n’est défini, le nom de domaine Active Directory est interrogé dans le DNS pour les enregistrements de service LDAP afin de remplir la liste des serveurs LDAP disponibles pour votre région située dans cet enregistrement de service. Vous pouvez interroger manuellement des enregistrements de service LDAP dans le DNS d’un client à l’aide des commandes nslookup ou dig.

Par exemple :

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

Les serveurs LDAP peuvent également être utilisés pour effectuer un mappage de noms personnalisé pour les utilisateurs. Pour plus d’informations, consultez la section mappage de noms personnalisé à l’aide du protocole LDAP.
Délais d'expiration des requêtes LDAP

Par défaut, les requêtes LDAP expirent si elles ne peuvent pas être exécutées dans les délais. Si une requête LDAP échoue en raison d'un délai d'attente, la recherche d'utilisateur et/ou de groupe échouera et l'accès au volume Azure NetApp Files pourra être refusé, en fonction des paramètres d'autorisation du volume. Reportez-vous à la section Créer et gérer des connexions Active Directory pour prendre connaissance des paramètres de délai d’expiration des requêtes LDAP Azure NetApp Files.

Types de mappage de noms

Les règles de mappage de noms peuvent être symétriques ou asymétriques.

Le mappage de noms symétrique est un mappage de noms implicite entre les utilisateurs UNIX et Windows qui utilisent le même nom d’utilisateur. Par exemple, l’utilisateur Windows CONTOSO\user1 est mappé à l'utilisateur UNIX user1.
Le mappage de noms asymétrique est un mappage de noms entre les utilisateurs UNIX et Windows qui utilisent des noms d’utilisateur différents. Par exemple, l’utilisateur Windows CONTOSO\user1 est mappé à l'utilisateur UNIX user2.

Par défaut, Azure NetApp Files utilise des règles de mappage de noms symétriques. Si des règles de mappage de noms asymétriques sont requises, vous pouvez configurer les objets utilisateur LDAP pour les utiliser.

Mappage de noms personnalisé à l’aide du protocole LDAP

Si les attributs de schéma LDAP sur le serveur LDAP ont été renseignés, le protocole LDAP peut être une ressource de mappage de noms. Par exemple, pour mapper les utilisateurs UNIX aux noms d’utilisateurs Windows correspondants qui ne sont pas identiques (autrement dit, asymétriques), vous pouvez spécifier une valeur différente pour uid dans l’objet utilisateur que ce qui est configuré pour le nom d’utilisateur Windows.

Dans l’exemple suivant, un utilisateur a un nom Windows (asymmetric) et doit être mappé à une identité UNIX (UNIXuser). Pour ce faire, dans Azure NetApp Files, ouvrez une instance de Microsoft Management Console Utilisateurs et ordinateurs Active Directory. Ensuite, recherchez l’utilisateur souhaité et ouvrez la boîte de propriétés. (Cela nécessite l’activation de l’éditeur d’attribut). Accédez à l’onglet éditeur d’attribut et recherchez le champ UID, puis renseignez le champ UID avec le nom d’utilisateur UNIX souhaité UNIXuser, puis cliquez sur Ajouter et OK pour confirmer.

Une fois cette action effectuée, les fichiers écrits à partir de partages SMB Windows par l’utilisateur Windows asymmetric sont détenus par UNIXuser du côté NFS.

L'exemple suivant montre le propriétaire Windows SMB asymmetric :

L’exemple suivant montre le protocole NFS UNIXuser (mappé à partir de l’utilisateur Windows asymmetric à l’aide du protocole LDAP) :

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

Autoriser les utilisateurs NFS locaux avec LDAP

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 le protocole LDAP dans une tentative de résolution des appartenances aux groupes pour l’utilisateur plutôt que de passer les appartenances aux groupes dans un paquet RPC. En raison de ce comportement, si cet ID numérique ne peut pas être résolu dans le protocole LDAP, la recherche échoue et l’accès est refusé, 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 de « 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 n’est effectuée. 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, mais peut avoir un impact sur l’affichage de la propriété de l’utilisateur/du groupe (traduction de noms) 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 arriveront 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 dans son fichier idmapd.conf le nom de l’utilisateur anonyme spécifié. L’activation de l’option « autoriser les utilisateurs NFS locaux avec LDAP » n’affecte pas l’accès NFSv4.1, car elle revient au comportement NFSv3 standard, sauf si Azure NetApp Files peut résoudre un ID numérique en 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 (v3 et v4.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 le protocole LDAP ou si ce dernier est mal configuré, le mappage de noms UNIX sur Windows tenté sera 1001@contoso.com. Dans la plupart des cas, les utilisateurs portant ce nom n’existent pas, l’authentification échoue et l’accès est refusé. De même, si l’ID numérique 1001 est résolu au nom d’utilisateur incorrect (par exemple, utilisateur2), alors la requête NFS est mappée à un utilisateur Windows inattendu et les autorisations pour l’utilisateur se serviront des contrôles d’accès « utilisateur2 ».

Activer « autoriser les utilisateurs NFS locaux avec LDAP » désactive toutes les traductions LDAP d’ID numériques vers des noms d’utilisateur, ce qui 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 fortement déconseillée.

Schémas LDAP

Les schémas LDAP sont la façon dont les serveurs LDAP organisent et collectent des informations. Les schémas de serveur LDAP suivent généralement les mêmes normes, mais différents fournisseurs de serveur LDAP peuvent avoir des variantes sur la façon dont les schémas sont présentés.

Quand Azure NetApp Files interroge le protocole LDAP, les schémas sont utilisés pour accélérer la recherche de noms, car ils permettent d’utiliser des attributs spécifiques pour trouver des informations sur un utilisateur, telles que l’UID. Les attributs de schéma doivent exister dans le serveur LDAP pour qu’Azure NetApp Files puisse trouver l’entrée. Sinon, les requêtes LDAP peuvent ne retourner aucune donnée et les demandes d’authentification peuvent échouer.

Par exemple, si un numéro UID (par ex. racine=0) doit être interrogé par Azure NetApp Files, l’attribut de schéma RFC 2307 uidNumber Attribute est utilisé. Si aucun numéro UID 0 n’existe dans le protocole LDAP dans le champ uidNumber, la demande de recherche échoue.

Le type de schéma actuellement utilisé par Azure NetApp Files est une forme de schéma basé sur RFC 2307bis et ne peut pas être modifié.

RFC 2307bis est une extension de RFC 2307 et ajoute la prise en charge de posixGroup, ce qui permet des recherches dynamiques pour les groupes auxiliaires à l’aide de l’attribut uniqueMember, plutôt que d’utiliser l’attribut memberUid dans le schéma LDAP. Au lieu d’utiliser uniquement le nom de l’utilisateur, cet attribut contient le nom unique complet d’un autre objet dans la base de données LDAP. Par conséquent, des groupes peuvent être membres d’autres groupes, ce qui permet l’imbrication de groupes. La prise en charge de RFC 2307bis ajoute également la prise en charge de la classe d’objets groupOfUniqueNames.

Cette extension RFC s’adapte parfaitement à la façon dont Microsoft Active Directory gère les utilisateurs et les groupes via les outils de gestion habituels. Cela est dû au fait que lorsque vous ajoutez un utilisateur Windows à un groupe (et si ce groupe a un GID numérique valide) à l’aide des méthodes de gestion Windows standard, les recherches LDAP extraient les informations de groupe supplémentaires nécessaires à partir de l’attribut Windows habituel et recherchent automatiquement les GID numériques.

Partager via