Installation et configuration d’un annuaire OpenLDAP

1. LDAP in a nutshell

Un annuaire est une base de données contenant différents types d’objets. Ces objets sont formés de couples attribut/valeur. Par exemple, je pourrais me définir par l’attribut Nom ayant pour valeur Greneche et l’attribut Prénom ayant comme valeur Nicolas. Les attributs composant un objet sont normés par des schémas. Les applications clientes de l’annuaire sont multiples (serveur de messagerie, terminal de téléphonie sur IP, authentification des ouvertures de sessions, portail WiFi, etc.) et elles doivent toutes utiliser la même façon d’interroger l’annuaire. Un effort de standardisation a donc été fourni pour aboutir au protocole LDAP (Lightweight Directory Access Protocol). Ce protocole permet d’interagir avec les objets stockés dans l’annuaire.

La dernière chose à savoir est que cet annuaire est stocké de façon hiérarchique. C'est-à-dire que nous avons une racine et des feuilles. Chaque objet est identifié par un attribut DN (Distinguished Name) qui reflète son positionnement dans l'annuaire. Dans notre exemple, nous allons créer une racine correspondant au domaine DNS calcul.univ-paris13.fr. Dans le monde LDAP, cela se traduirait par le DN suivant : dc=calcul,dc=univ-paris13,dc=fr. Un DC est un composant du domaine (Domain Component). Nous allons également créer deux feuilles sous cette racine afin d'y stocker les utilisateurs et les groupes UNIX en vue de les distribuer sur le réseau. Ces deux feuilles seront des OU (Organizational Unit), c'est-à-dire des sortes de boites où on peut mettre des choses (en l’occurrence, les utilisateurs et les groupes) pour aboutir à l'annuaire présenté en figure 1. Ne vous inquiétez pas, ces notions vont vite se concrétiser dans la suite. Toutes les manipulations de cet article sont réalisées sous Debian Buster.

2. Installation d’OpenLDAP

Un service d’annuaire traditionnel est composé de deux éléments : un processus réseau qui attend les requêtes et une base de données stockée sur le système de fichiers. À la réception d’une requête LDAP émise depuis un client de l'annuaire, le processus va lire ou écrire (selon la nature de la requête) dans cette base de données. Dans le monde OpenLDAP, le processus réseau se nomme slapd et les fichiers composant la base de données sont dans /var/lib/ldap. Un utilisateur système est souvent lié à slapd. Sous Debian, il s’agit de l’utilisateur openldap. Le processus slapd va donc tourner avec l’identité openldap et par conséquent le répertoire /var/lib/ldap doit lui appartenir.

Nous disposons de deux machines pour monter l’environnement de test de notre article. Le serveur slapd sera installé sur la machine nommée 'serveur' et la machine nommée 'client' sera cliente de cet annuaire. Commençons par installer le service slapd :

Le premier élément DEBIAN_FRONTEND=noninteractive peut vous interpeller. Il faut savoir qu'avec l'interpréteur de commande Bash, il est possible de passer des variables d’environnement au processus fils généré par l'invocation de la commande (ici, apt-get). Cette variable précise que l'installation du paquet (ici, slapd) va se faire en mode non interactif. Les paramètres -yq précisent également que l'installation devra se faire en mode silencieux. Le paquet sera donc installé sans aucune action de post-configuration.

3. Configuration initiale

Pour créer un squelette de configuration de slapd, nous allons utiliser la commande dpkg-reconfigure comme suit :

À l'invocation de cette commande, une suite de menus en ncurses vont se succéder pour configurer le paquet slapd. Il faut utiliser tabulation pour se déplacer dans ces menus et la touche [Entrée] pour valider. Deux captures suivent pour vous présenter l'aspect des menus ncurses. Le premier menu nous demande si on veut omettre la configuration de slapd, il faut évidemment répondre non (figure 2).

La question suivante sert à fixer la racine de l'annuaire LDAP. Comme vu dans la partie 1, cette racine va correspondre au domaine DNS. Nous entrons donc calcul.univ-paris13.fr (figure 3).

À l'issue de cette étape, la racine dc=calcul,dc=univ-paris13,dc=fr est créée. L'étape suivante est liée, il s'agit de fixer l'attribut organization pour cette racine. Traditionnellement, on laisse le domaine DNS, donc calcul.univ-paris13.fr. Ensuite, dpkg-reconfigure demande d'affecter un mot de passe à l'administrateur de la racine. Cet administrateur est identifié par le DN cn=admin,dc=calcul,dc=univ-paris13,dc=fr. En lisant le DN, on voit sans ambiguïté qu'il est placé directement sous la racine. L'étape suivante est de fixer le moteur de base de données de l'annuaire. Nous choisirons MDB qui est le standard actuel. L'avant-dernière question concerne le comportement en cas de purge du paquet. La purge intervient lorsque l'on utilise l'option --purge à la suppression d'un paquet avec apt-get. La purge détruit également les fichiers de configuration, logs, bases de données, etc., liés au paquet. Ici c'est à vous de décider, le choix le plus conservateur étant non. Enfin, dpkg-reconfigure demande s’il doit bouger la base de données actuelle pour la sauvegarder, idem c'est à vous de voir. Le choix le plus conservateur est évidemment oui. Nous avons maintenant un slapd opérationnel !

4. Tests fonctionnels

Les deux premières choses à faire sont respectivement d'activer slapd au démarrage et de le lancer. Ces actions se font avec systemctl :

Puis :

Regardons sur quel port réseau écoute slapd :

On voit que slapd attend les requêtes LDAP sur le port TCP 389. Regardons avec quels arguments s’exécute le service :

Le paramètre -h indique les modalités d'accès à slapd : ldap et ldapi. L'accès en mode ldap sous-entend des requêtes en clair (ou en start_tls, mais nous n'avons pas encore configuré les certificats). Cet accès se fait via le port TPC 389 observé ci-dessus. L'accès en ldapi se fait par un socket UNIX (donc local à la machine, non exposé sur le réseau) et le contrôle se fait en se basant sur l'UID de l’initiateur de la connexion. En gros si l'accès à la socket se fait depuis le compte root local ça marche, sinon non. Les options -g (groupe) et -u (utilisateur) définissent l'identité sous laquelle tourne le processus slapd. Enfin, -F donne l'emplacement de la configuration de slapd. Nous n'allons jamais taper directement dans les fichiers de ce répertoire, car la configuration de slapd se fait désormais directement dans la base LDAP elle-même pour une configuration à chaud sans redémarrage.

Le test ultime est de tenter un affichage des données de l'annuaire. Pour ce faire, nous allons installer l'outil ldapsearch contenu dans le paquet ldap-utils :

Et l’exécuter :

Reprenons les arguments de ldapsearch. L'option -x indique que nous utilisons une connexion type simple bind. C'est-à-dire que nous utilisons un compte défini à l’intérieur de la base LDAP pour accéder à l'annuaire. Pour garder cette requête la plus simple possible, nous ne spécifions pas de compte, ce qui sous-entend un accès anonyme (anonymous binding). L'option -H avec la valeur ldap://serveur.calcul.univ-paris13.fr indique que l'accès se fait en ldap (et non en ldapi) sur la machine serveur.calcul.univ-paris13.fr. Enfin, le -b définit la racine à parcourir, donc ici 'dc=calcul,dc=univ-paris13,dc=fr'. En résultat, on voit bien qu'on retrouve les deux entrées créées au moment du dpkg-reconfigure, à savoir les deux DN dc=calcul,dc=univ-paris13,dc=fr (la racine) et cn=admin,dc=calcul,dc=univ-paris13,dc=fr (le compte administrateur de cette racine).

5. Peuplement de l'annuaire

Nous allons peupler l'annuaire en créant les deux OU puis un compte système avec son groupe primaire. Dans le monde LDAP, les données à ajouter à l'annuaire peuvent être inscrites dans un fichier rédigé au format LDIF (LDAP Data Interchange Format). Ce format présente les objets à manipuler dans l'annuaire accompagnés de leurs attributs. Par exemple, pour nos deux OU le fichier se présente de la façon suivante :

Nous avons deux OU : posixaccounts (qui va contenir les comptes UNIX) et posixgroups (qui va contenir les groupes UNIX). L'OU étant un objet assez simple, il va contenir que deux attributs : le DN qui positionne sans ambiguïté l'objet dans l'arbre (ici juste sous la racine) et l'objectclass qui indique que l'objet à ajouter est de type OrganizationalUnit. Les objectclass sont définis dans les schémas et un objet de l'annuaire peut appartenir à plusieurs objectclass pour multiplier les attributs possibles. Ajoutons-les à l'annuaire via la commande ldapadd :

Par rapport à la commande ldapadd de tout à l'heure, deux nouveaux attributs se sont positionnés : -D avec la valeur 'cn=admin,dc=calcul,dc=univ-paris13,dc=fr' qui sert à préciser quel compte on va utiliser pour se connecter à slapd (ici l'administrateur de la racine concernée par l'ajout) et -W qui indique à la commande de demander le mot de passe associé interactivement. Nous avons également un -f pour indiquer le fichier LDIF à traiter. Il nous reste à ajouter le compte avec le groupe primaire :

Si on examine ce fichier LDIF, on se rend compte qu'il contient deux objets : le compte système 'uid=nicolas.greneche,ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr' (objectclass posixAccount) et le groupe primaire associé 'cn=nicolas.greneche,ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr' (objectclass posixGroup), chacun rangé dans son OU respective. On notera que les attributs de ces deux objets coïncident avec les informations qu'on trouverait dans les fichiers /etc/passwd, /etc/shadow et /etc/group.

Pour créer l'empreinte du mot de passe userPassword, il est possible d'utiliser la commande slappasswd comme suit :

Ajoutons les deux objets :

6. Sécurisation avec SSL

SSL (Secure Socket Layer) est une couche additionnelle à TCP ajoutant une propriété de confidentialité à la connexion en chiffrant les échanges lors de son établissement. La sécurisation de notre serveur LDAP va se résumer à activer l'accès en ldaps (en plus du ldap et ldapi mentionnés ci-dessus). Pour autoriser l'accès en ldaps, il faut modifier les paramètres de lancement du service ldap pour ajouter ldaps à ldap et ldapi et générer un certificat. Commençons par le certificat.

6.1 Création des certificats

Le plus simple est de créer un sous-répertoire ssl où mettre le certificat et de se placer dedans :

Puis d'utiliser la commande openssl pour générer un certificat autosigné :

Cette commande va créer deux fichiers : key.pem (clé privée) et cert.pem (certificat contenant la clé publique). Comme le certificat est autosigné, le fichier cert.pem fait également office de CA (Certificate Authority). En résumé, ce qui est chiffré avec la clé privée est déchiffrable avec la clé publique et ce qui est chiffré avec la clé publique est déchiffrable par la clé privée. En conséquence, slapd présentera le certificat au client souhaitant se connecter en ldaps (LDAP over SSL). Le client extraira la clé publique du certificat et utilisera cette clé pour discuter de façon chiffrée avec le serveur afin de se mettre d'accord sur les modalités d'établissement d'une session SSL par laquelle faire passer les données. Les données circuleront donc chiffrées sur le réseau. Une fois cette commande validée, elle nous demande un certain nombre d'informations :

On peut répondre ce qu'on veut partout SAUF la dernière concernant le Common Name. Il faut absolument mettre le nom d'hôte complet (FQDN) de la machine faisant office de serveur LDAP. C'est une vérification basée sur DNS pour le client qui valide (dans la limite de l'intégrité possible avec DNS) que le certificat est bien distribué pour la machine au bout de l'IP contactée. On change ensuite les permissions sur les deux fichiers générés. Les fichiers doivent appartenir à l'utilisateur openldap (identité utilisée par slapd) :

La clé privée ne doit être accessible que par root :

6.2 Configuration de slapd

Il faut ajouter deux directives dans la configuration de slapd pour qu'il trouve le couple clé/certificat à utiliser lors de l'établissement d'une connexion SSL d'un client. La configuration se fait via un fichier LDIF modifiant la racine cn=config de l'annuaire LDAP. Cette racine contient tous les éléments de configuration. Voici le fichier à utiliser :

Dans ce fichier, on informe que c'est une modification (changetype : modify) qui va porter sur la racine cn=config pour le remplacement des valeurs de trois attributs (olcTLSCACertificateFile, olcTLSCertificateFile et olcTLSCertificateKeyFile) avec celles correspondant aux emplacements des fichiers générés avec la commande openssl. Pour appliquer les modifications induites par le fichier LDIF, nous allons passer par l'accès en ldapi, car il n'y a pas de compte administrateur associé à la racine cn=config :

L'argument -x a donc disparu au profit de -Y EXTERNAL pour s'authentifier via l'UID. L'option -H a comme valeur ldapi:/// qui pointe sur la socket UNIX gérée par slapd.

La dernière étape est de modifier le fichier /etc/default/slapd pour lui dire qu'il doit maintenant gérer la méthode d'accès ldaps et plus de ldap et ldapi :

Il ne reste plus qu'à redémarrer slapd (on a pas fait que modifier la configuration, on a également ajouté un socket SSL à gérer, donc redémarrage) :

Vérification :

Nous avons le service slapd qui écoute bien en SSL sur le port 636. Le serveur est fin prêt, passons au client.

7. Configuration du client

La configuration du client va se faire en deux temps. Premièrement, nous allons raccorder le client au serveur LDAP. Nous allons vérifier que la connexion entre les deux permet la consultation de l'annuaire depuis le client. Ensuite, nous allons installer la partie cliente qui va augmenter la base des comptes locaux avec celle contenue dans la base LDAP. Nous pourrions nous passer de la première étape, mais elle permet de bien valider l'accès au serveur LDAP en cas de soucis avec la seconde.

7.1 Raccordement au LDAP

Avant tout, il faut installer le paquet ldap-utils pour disposer des commande ldap* (ldapsearch, ldapadd, etc.) :

Commençons par vérifier que le client peut bien se connecter au port TCP/636 en SSL sur le serveur et consulter le certificat :

Cette commande devrait vous renvoyer les données du certificat créé précédemment. Nous devons ensuite envoyer le certificat du serveur vers le client pour qu'à la connexion le client puisse valider qu'il s'adresse bien à la bonne machine :

Enfin, il nous faut configurer le fichier /etc/ldap/ldap.conf pour y insérer les informations de connexion au serveur LDAP :

Ce fichier contient les 3 paramètres essentiels à la connexion : la racine (BASE, synonyme de l'option -b des commandes clientes ldap*), l'emplacement et la méthode d'accès au service d'annuaire (URI, synonyme de l'option -H) et l'emplacement du certificat permettant de vérifier celui présenté par le serveur. Il ne reste plus qu'à tester avec une commande ldapsearch depuis le client :

Cette commande nous renvoie bien les 6 entrées de l'annuaire (racine + 2 OU + administrateur de la racine + compte + groupe). On voit qu'elle est bien plus courte qu'avant, car les applications clientes LDAP vont chercher leurs valeurs par défaut dans le fichier ldap.conf.

7.2 Complétion des comptes locaux avec LDAP

Le programme gérant les bases de comptes utilisables par un système Linux se nomme NSS (Name Switching Service). Il va s'appuyer sur un service nommé SSSD (System Security Services Daemon) qui pointe sur le serveur LDAP et lui présente les comptes qui y sont stockés. Commençons par installer le service SSSD :

Regardons la configuration du programme NSS à la suite de cette installation :

On voit que le programme NSS va interroger le service SSSD (sss) en vue de compléter la base locale (files) pour ce qui concerne les bases passwd, group et shadow. La dernière étape sur le client est de configurer le service SSSD avec les informations de notre serveur LDAP. La configuration se passe dans le fichier sssd.conf :

Ce fichier configure le service sssd. La ligne services indique que SSSD sera utilisé pour la gestion des comptes (nss) et l'authentification (pam). La ligne domains prend deux valeurs : LOCAL et LDAP. LOCAL correspond aux comptes locaux de la machine (/etc/passwd, /etc/shadow et /etc/group) et LDAP à ceux stockés dans le LDAP. Dans la section domain/LDAP, nous retrouvons les paramètres du ldap.conf ainsi que la spécification du protocole LDAP comme méthode d'accès au compte (id_provider) et credentials d'authentification (auth_provider). Activons et démarrons le service SSSD :

Vérification :

La commande getent prend comme paramètre une base NSS (passwd, group ou shadow) et en affiche le contenu. Nous demandons la base passwd et en résultat nous obtenons bien le compte nicolas.greneche qui est défini dans le LDAP. La base de comptes locaux est donc bien complétée avec les utilisateurs définis dans l'annuaire LDAP. Créons un home pour notre utilisateur :

Positionnons les droits appropriés :

On se déconnecte du client :

On s’authentifie avec l'identifiant créé dans le LDAP :

La commande id affiche l'identité en cours d'utilisation. Notre utilisateur est bien reconnu sur le système, mission accomplie !

Conclusion

Avec cet article, nous avons déployé une configuration OpenLDAP de base solide. Pour lui faire passer le cap de la production, j'invite le lecteur à investiguer du côté de deux technologies. La première est intégrée à OpenLDAP, il s'agit des modules syncprov et accesslog destinés à faire de la réplication entre plusieurs services slapd afin de disposer de plusieurs machines hébergeant la base de données. La seconde est externe et se nomme HAProxy. L'idée est de placer une machine HAProxy en frontal de notre ferme de serveurs slapd pour équilibrer la charge (évidemment, il faudra redonder le HAProxy).