Comprendre l’utilisation de LDAP avec Azure NetApp Files
Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole d’accès aux annuaires standard développé par un comité international appelé Internet Engineering Task Force (IETF). LDAP est destiné à 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 le répertoire, décrire les objets du magasin et la sécurité utilisée pour accéder au répertoire. LDAP autorise 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 LDAP initiaux se sont concentrés sur l’utilisation du protocole LDAP comme magasin d’annuaires pour les applications telles que les e-mails et les applications web et pour stocker des informations sur les employés. De nombreuses entreprises remplacent ou ont remplacé le service d’informations réseau (NIS) par 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é. Cette prise en charge inclut à la fois services de domaine Active Directory (AD DS) et 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 le répertoire pour obtenir des informations sur l’utilisateur et le groupe, telles que les noms, les ID numériques, les chemins d’accès au répertoire de base, les chemins d’accès de l’interpréteur de commandes de connexion, les appartenances aux groupes et bien plus encore.
LDAP peut stocker les informations suivantes utilisées dans l’accès NAS double protocole :
- Noms d’utilisateurs
- Noms de groupes
- ID d’utilisateur numériques (UID) et ID de groupe (GID)
- Répertoires de base
- Interpréteur de commandes de connexion
- Groupes net, noms DNS et adresses IP
- Appartenance au groupe
Actuellement, Azure NetApp Files utilise uniquement LDAP pour les informations d’utilisateur et de groupe : aucune information netgroup ou hôte.
LDAP offre différents avantages pour vos utilisateurs et groupes UNIX en tant que source d’identité.
- LDAP est une preuve future.
À 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 de clients et de 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 S Mo et NFS simplifie considérablement la vie des administrateurs de stockage, non seulement dans le présent, mais pour des années à venir. - 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 à la fois pour une mise à l’échelle des performances et de la résilience. - LDAP est sécurisé.
LDAP offre une sécurité sous la forme de 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)
- Authentification simple et couche de sécurité (SASL) : méthodes de liaison chiffrées, notamment TLS, SSL, Kerberos, et ainsi de suite. Azure NetApp Files prend en charge LDAP via TLS, signature LDAP (à l’aide de Kerberos), LDAP via SSL.
- LDAP est robuste.
Les fichiers NIS, NIS+et locaux offrent des informations de base telles que UID, GID, password, home directories, etc. Toutefois, LDAP offre ces attributs et bien plus encore. Les attributs supplémentaires que LDAP utilise rendent la gestion du double protocole beaucoup plus intégrée avec LDAP et NIS. Seul 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 LDAP.
Par défaut, Microsoft Active Directory utilise un serveur principal LDAP pour ses entrées d’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 Identity Management 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 LDAP comme back-end, il rend LDAP 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 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 recherches avec le schéma sur le serveur LDAP.
Les clients LDAP lancent des requêtes par le biais d’une liaison LDAP, qui est essentiellement 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, ils sont des échanges de nom d’utilisateur et de mot de passe en texte brut (simple). Dans d’autres cas, les liaisons sont sécurisées via des méthodes d’authentification simple et de couche de sécurité (
sasl) telles que Kerberos ou LDAP via TLS. Azure NetApp Files utilise le compte d’ordinateur S Mo 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 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 une forme 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 net. Toutefois, Azure NetApp Files ne peut actuellement pas utiliser la fonctionnalité netgroup dans LDAP sur Windows Active Directory.
LDAP dans Azure NetApp Files fonctionne sur le port 389. Actuellement, ce port ne peut pas être modifié pour utiliser un port personnalisé, tel que le port 636 (LDAP sur SSL) ou le port 3268 (recherches dans le catalogue global Active Directory).
Les communications LDAP chiffrées peuvent être obtenues à l’aide du protocole LDAP via TLS (qui fonctionne sur le port 389) ou de la signature LDAP, qui peuvent être configurées 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, envisagez de spécifier une étendue de recherche LDAP pour filtrer les requêtes pour 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 demandes. 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 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 SRV. Vous pouvez interroger manuellement des enregistrements de service LDAP dans DNS à partir d’un client à l’aide
nslookupoudigaux commandes.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.yLes serveurs LDAP peuvent également être utilisés pour effectuer un mappage de noms personnalisé pour les utilisateurs. Pour plus d’informations, consultez 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 effectuées en temps voulu. Si une requête LDAP échoue en raison d’un délai d’expiration, l’utilisateur et/ou la recherche de groupe échouent et l’accès au volume Azure NetApp Files peut être refusé, en fonction des paramètres d’autorisation du volume. Reportez-vous à Créer et gérer des connexions Active Directory pour comprendre les 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 divisées en deux types principaux : symétriques et asymétriques.
- Le mappage de noms symétriques est un mappage de noms implicite entre les utilisateurs UNIX et Windows qui utilisent le même nom d’utilisateur. Par exemple, l’utilisateur
CONTOSO\user1Windows mappe à l’utilisateuruser1UNIX . - Le mappage de noms asymétriques est le mappage de noms entre les utilisateurs UNIX et Windows qui utilisent des noms d’utilisateur différents . Par exemple, l’utilisateur
CONTOSO\user1Windows mappe à l’utilisateuruser2UNIX .
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, envisagez de configurer les objets utilisateur LDAP pour les utiliser.
Mappage de noms personnalisé à l’aide du protocole LDAP
LDAP peut être une ressource de mappage de noms, si les attributs de schéma LDAP sur le serveur LDAP ont été renseignés. Par exemple, pour mapper les utilisateurs UNIX aux noms d’utilisateurs Windows correspondants qui ne correspondent pas à un à un (c’est-à-dire asymétriques), vous pouvez spécifier une valeur différente dans uid l’objet utilisateur que ce qui est configuré pour le nom d’utilisateur Windows.
Dans l’exemple suivant, un utilisateur a un nom Windows et asymmetric doit être mappé à une identité UNIX de UNIXuser. Pour ce faire, dans Azure NetApp Files, ouvrez une instance de la console MMC Utilisateurs et ordinateurs Active Directory. Ensuite, recherchez l’utilisateur souhaité et ouvrez la zone de propriétés. (Cela nécessite l’activation de l’éditeur d’attributs). Accédez à l’onglet Éditeur d’attributs et recherchez le champ UID, puis renseignez le champ UID avec le nom UNIXuser d’utilisateur UNIX souhaité, puis cliquez sur Ajouter et OK pour confirmer.
Une fois cette action effectuée, les fichiers écrits à partir de Windows S Mo partages par l’utilisateur Windows sont détenus par UNIXuser l’utilisateur asymmetric NFS.
L’exemple suivant montre le propriétaire asymmetricde Windows S Mo :
L’exemple suivant montre le propriétaire UNIXuser NFS (mappé à partir de l’utilisateur asymmetric Windows à 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
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 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 retourner aucune donnée et les demandes d’authentification peuvent échouer.
Par exemple, si un numéro UID (tel que root=0) doit être interrogé par Azure NetApp Files, l’attribut de schéma RFC 2307 uidNumber Attribute est utilisé. Si aucun numéro 0 UID n’existe dans LDAP dans le uidNumber champ, 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 des posixGrouprecherches dynamiques pour les groupes auxiliaires à l’aide de l’attribut uniqueMember , au lieu 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 (DN) d’un autre objet dans la base de données LDAP. Par conséquent, les groupes peuvent avoir d’autres groupes en tant que membres, ce qui permet l’imbrication de groupes. La prise en charge de RFC 2307bis ajoute également la prise en charge de la classe groupOfUniqueNamesd’objets.
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 extrayent les informations de groupe supplémentaires nécessaires à partir de l’attribut Windows habituel et recherchent automatiquement les GID numériques.