L'authentification LDAP (Lightweight Directory Access Protocol), qu'est-ce que c'est ?

Le protocole LDAP (Lightweight Directory Access Protocol) permet aux utilisateurs de trouver des données sur des entreprises, des personnes, etc. Ce protocole a deux objectifs principaux : stocker des données dans l'annuaire LDAP et authentifier les utilisateurs qui veulent y accéder. C'est également lui qui fournit aux applications le langage nécessaire pour échanger des informations avec les différents services d'annuaires. Ces derniers indiquent l'emplacement des informations sur les entreprises, les personnes, etc. au sein d'un réseau.

Le protocole LDAP est très souvent utilisé pour centraliser l'accès aux services d'annuaires et leur gestion. Il permet aux entreprises de stocker, gérer et sécuriser leurs informations et celles de leurs utilisateurs ainsi que d'autres ressources telles que les noms d'utilisateurs et mots de passe. Ce système simplifie l'accès au stockage grâce à la hiérarchisation des informations, ce qui peut s'avérer déterminant pour une entreprise qui se développe et acquiert toujours plus de données et ressources utilisateur.

Le protocole LDAP peut également servir de solution de gestion des identités et des accès qui cible l'authentification des utilisateurs, notamment au moyen de Kerberos et de l'authentification unique et unifiée (SSO), du système SASL (Simple Authentication Security Layer) ainsi que du protocole SSL (Secure Sockets Layer).

Comment une recherche LDAP se déclenche-t-elle, et quel est son fonctionnement ?

Le processus d'authentification LDAP suit un modèle d'authentification client-serveur qui repose sur les éléments clés suivants :

• DSA (Directory System Agent) : serveur qui exécute le protocole LDAP sur son réseau
• DUA (Directory User Agent) : utilisateur qui accède aux DSA en tant que client (p. ex. l'ordinateur portable d'un utilisateur)
• DN (Distinguished Name) : nom distinctif qui contient un chemin parcourant l'arbre DIT (Directory Information Tree) pour que le protocole LDAP puisse y accéder (p. ex. : cn=Susanne, ou=utilisateurs, o=Entreprise)
• RDN (Relative Distinguished Name) : nom distinct relatif composé de chaque élément du chemin dans le DN (p. ex. : cn=Susanne)
• API : interface de programmation d'application qui permet à un produit ou service de communiquer avec d'autres produits et services sans connaître les détails de leur mise en œuvre

Le processus débute lorsqu'un utilisateur essaie d'accéder à un programme client qui fonctionne avec le protocole LDAP, comme une application de messagerie professionnelle, sur son ordinateur. La version LDAPv3 permet aux utilisateurs d'utiliser l'une des deux méthodes suivantes : une authentification simple et basée sur des identifiants de connexion, comme le système SSO, ou une authentification SASL qui lie le serveur LDAP à un programme tel que Kerberos. La tentative de connexion envoie une demande d'authentification pour le DN de l'utilisateur. Ce DN passe ensuite par l'API ou le service utilisé pour lancer le DSA.

Tandis que le client se lie automatiquement au DSA, le protocole LDAP utilise le DN pour chercher l'objet ou l'ensemble d'objets correspondants dans sa base de données. Les RDN contenus dans le DN sont alors déterminants pour trouver la bonne personne : c'est sur eux que s'appuie chaque étape de la recherche dans le DIT. S'il manque un RDN au niveau du backend, la validité du résultat peut en être affectée. Dans ce cas, l'objet recherché correspond au compte de la personne (cn=Susanne), qui doit avoir les mêmes valeurs uid et userPassword que celles stockées dans l'annuaire pour que le protocole LDAP valide l'utilisateur. Les groupes d'utilisateurs font aussi partie des objets dans l'annuaire LDAP.

Dès que l'utilisateur reçoit une réponse (qu'elle soit positive ou non), le client supprime sa liaison au serveur LDAP. Les personnes authentifiées peuvent ensuite accéder à l'API et aux services, y compris les fichiers nécessaires, les informations sur les utilisateurs et d'autres données d'application, en fonction des autorisations accordées par l'administrateur système.

Grâce à sa structure légère et à l'utilisation d'un arbre DIT, le protocole LDAP permet d'exécuter rapidement des recherches et d'obtenir des résultats satisfaisants. Il faut maîtriser la structure de l'arbre DIT pour parcourir efficacement un serveur LDAP et comprendre le fonctionnement des recherches.

L'arbre DIT permet de passer rapidement d'un niveau de l'annuaire LDAP à l'autre afin de réduire les résultats de recherche et répondre à la requête. L'arbre part du répertoire racine puis se divise en branches pour les pays, qui se divisent ensuite en deux sous-classes : dc (Domain Component) et o (Organization Name).

dc (Domain Component)

Le dc (c'est-à-dire dc=com, dc=exemple), ou composant de domaine, utilise le mappage DNS (Domain Name System) pour localiser les noms de domaines sur Internet et les traduire en adresses IP.

La plupart des utilisateurs ne connaissent pas le nom de domaine ou l'adresse IP de la personne qu'ils recherchent. C'est pour cette raison que le protocole LDAP transforme le DN (Distinguished Name) assigné à un utilisateur en chemin qui parcourt l'arbre DIT et trouve rapidement un résultat. C'est là qu'entre en jeu la sous-classe o.

o (Organization Name)

La sous-classe o (p. ex. o-Entreprise), qui désigne le nom de l'entreprise, est l'une des sous-classes les plus générales du DN. C'est à partir d'elle que commence habituellement une recherche LDAP. Par exemple, un chemin simple commence souvent par la sous-classe o, puis se dirige vers la sous-classe ou (Organizational Unit) avant d'atteindre un compte ou un groupe d'utilisateurs.

ou (Organizational Unit)

Comme indiqué ci-dessus, la classe ou est une sous-classe de la classe o. En général, on l'associe aux valeurs ou=utilisateurs ou ou=groupe, qui contiennent respectivement une liste de comptes et une liste de groupes d'utilisateurs. Voici un exemple dans un annuaire :

• o-Entreprise

  • ou=groupes

    • cn=développeurs

  • ou=utilisateurs

    • cn=Susanne

cn (Common Name)

Un cn, ou nom commun, sert à identifier le nom d'un compte ou d'un groupe d'utilisateurs (p. ex. : cn=développeurs, cn=Susanne). Un utilisateur peut faire partie d'un groupe. Ainsi, en admettant que Susanne soit développeuse, elle peut également apparaître dans la classe cn=développeurs.

Attributs et valeurs

Chaque sous-classe de l'arbre DIT LDAP (o, ou, cn) contient des attributs et valeurs, ou des schémas donnant des informations sur la structure d'un annuaire LDAP qui permettent de réduire le champ de recherche. Les attributs ressemblent aux données qu'on pourrait trouver dans un carnet d'adresses, notamment des étiquettes telles que le nom, le numéro de téléphone et l'adresse. Ces attributs sont associés à des valeurs. Par exemple, Susanne correspond à la valeur de l'attribut nom.

Dans le compte cn=Susanne, l'identifiant de l'utilisateur (uid) et l'élément userPassword sont des attributs, tandis que les identifiants de connexion sont des valeurs. Cependant, dans un groupe comme cn=développeurs, Susanne pourrait avoir l'attribut uniqueMember (p. ex. uniqueMember=cn-Susanne,ou-utilisateurs,o-Entreprise). Ceci permet d'établir un chemin vers l'emplacement du compte de Susanne ainsi que vers les informations que recherche le protocole LDAP. L'arbre DIT se termine au niveau d'un compte utilisateur. C'est à ce point que le protocole LDAP finit par extraire les résultats dont il a besoin.

Il existe de nombreux autres types et syntaxes d'attributs qui peuvent aider à affiner une recherche, notamment l'attribut ObjectClass : organizationalPerson (structurel) ou personal (structurel). Cependant, le nombre d'attributs LDAP est limité afin de conserver la légèreté et la facilité d'utilisation du protocole.

Les administrateurs réseau d'une entreprise gèrent souvent des milliers d'utilisateurs en même temps. Ils doivent donc assigner les contrôles et politiques d'accès en fonction du rôle des utilisateurs et de leur niveau d'accès aux fichiers pour les tâches quotidiennes, par exemple pour la connexion à l'intranet de l'entreprise.

Le protocole LDAP simplifie ce processus de gestion, fait gagner un temps précieux aux administrateurs réseau et centralise le processus d'authentification. Avant de l'intégrer à votre environnement, nous vous recommandons de vous poser les questions suivantes :

• Capacité : quel volume de données de gestion des utilisateurs devez-vous stocker ? Il faut savoir si les produits qui mettent en œuvre les solutions LDAP sont capables de stocker et gérer toutes vos données.

• Fréquence de recherche : vos utilisateurs doivent-ils accéder quotidiennement à certaines données, comme l'intranet de l'entreprise, une application de messagerie ou un service ? Si oui, le protocole LDAP est sûrement fait pour vous.

• Organisation : l'arbre DIT simple du protocole LDAP sera-t-il suffisant pour organiser vos données, ou avez-vous besoin d'un système plus détaillé ?

Bien que le protocole LDAP soit souvent utilisé avec AD, il peut également servir à authentifier des utilisateurs dans d'autres outils et environnements client, notamment les solutions Red Hat Directory Server sur UNIX, ou l'application Open Source OpenLDAP sur Windows. Vous pouvez également tirer parti de cette méthode d'authentification et de ces capacités de gestion des utilisateurs pour la gestion des API, le contrôle d'accès basé sur les rôles (RBAC) ou d'autres applications et services, comme Docker et Kubernetes.

La solution Red Hat® Enterprise Linux® inclut des capacités de gestion des identités centralisée qui vous permettent d'authentifier des utilisateurs et de mettre en œuvre le RBAC, à l'aide d'une interface unique et évolutive qui couvre l'ensemble de votre datacenter.

Red Hat Enterprise Linux inclut diverses capacités d'authentification et d'autorisation pour la gestion des identités, notamment :

• Contrôleur de domaine pour Linux : centralisez la gestion des identités, des accès et des politiques pour l'ensemble des utilisateurs, services et hôtes dans ce système de stockage d'identités fiable et centralisé. Réduisez ainsi les coûts administratifs et simplifiez l'enregistrement du domaine pour créer un périmètre de sécurité fiable. Et offrez aux utilisateurs une expérience d'authentification rationalisée.

• Intégration à AD : palliez les différences entre Linux et Windows en matière d'identités des utilisateurs grâce à l'intégration native de Red Hat Enterprise Linux pour Active Directory. Utilisez Active Directory comme source unique de vérité pour les identités des utilisateurs, et appliquez des politiques personnalisées de contrôle d'accès directement dans le domaine Linux afin d'améliorer l'efficacité de l'administration et de centraliser la création des politiques.

• SSO Kerberos : simplifiez le processus d'authentification à l'aide de Kerberos (principal service d'authentification par gestion des identités) pour la prise en charge du système SSO. Étendez ensuite cette méthode à vos services pour qu'ils procèdent à l'authentification sans mots de passe et sur Internet grâce au système SSO (basé sur Keycloak).

• Rôles système : économisez du temps et des ressources à l'aide de workflows de configuration cohérents et reproductibles. L'automatisation réduit considérablement la charge technique et les tâches manuelles associées au déploiement et à l'administration des identités.

En cas de besoins plus précis, il est possible d'utiliser la solution Red Hat Directory Server disponible sous forme de module complémentaire.

Red Hat Directory Server est un annuaire basé sur le protocole LDAP qui peut s'adapter à l'échelle d'environnements vastes et variés. Remplacez vos solutions LDAP tierces et coûteuses, et gérez des topologies d'annuaires distribués et complexes grâce à un large choix d'options de réplication. Cette solution renforce la flexibilité du système, car elle offre des attributs et schémas personnalisables, adaptés aux données de votre annuaire.