11.7. Annuaire LDAP

OpenLDAP implémente le protocole LDAP ; ce n'est qu'une base de données adaptée pour gérer des annuaires. Son intérêt est multiple : l'emploi d'un serveur LDAP aide à centraliser la gestion des comptes des utilisateurs et des droits associés. De plus, la base de données LDAP est facile à dupliquer, ce qui permet de mettre en place plusieurs serveurs synchronisés. En cas de croissance rapide du réseau, il sera aisé de monter en puissance en répartissant la charge sur plusieurs serveurs.

Les données LDAP sont structurées et hiérarchisées. Les « schémas » définissent les objets que la base peut stocker avec la liste de tous les attributs possibles. La syntaxe qui permet de désigner un objet de la base traduit cette structure, même si elle n'est pas facile à maîtriser.

11.7.1. Installation

Le paquet slapd contient le serveur OpenLDAP. Le paquet ldap-utils renferme des utilitaires en ligne de commande pour interagir avec les serveurs LDAP.

Installing slapd usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple dpkg-reconfigure slapd will let you reconfigure the LDAP database with more details:

Faut-il ignorer la configuration de slapd ? Non, bien sûr, nous allons configurer ce service.
Quel est le nom de domaine ? « falcot.com ».
Quel est le nom de l'organisation ? « Falcot SA ».
Il faut saisir un mot de passe administrateur pour la base de données.
Quel est le module de base de données à utiliser ? « MDB ».
La base doit-elle être supprimée si le paquet slapd est supprimé ? Non. Mieux vaut éviter de perdre ces données suite à une mauvaise manipulation.
Faut-il déplacer l'ancienne base de données ? Cette question n'est posée que si l'on déclenche une nouvelle configuration alors qu'une base de données existe déjà. Ne répondre « oui » que si l'on veut effectivement repartir d'une base propre, par exemple si l'on exécute dpkg-reconfigure slapd juste après l'installation initiale.

Une base de données minimale est maintenant configurée, ce qu'on peut vérifier en l'interrogeant directement :

$ ldapsearch -x -b dc=falcot,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=falcot,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# falcot.com
dn: dc=falcot,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Falcot Corp
dc: falcot

# admin, falcot.com
dn: cn=admin,dc=falcot,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

La requête a renvoyé deux objets : l'organisation dans son ensemble et l'administrateur.

11.7.2. Remplissage de l'annuaire

La base de données vide n'ayant pas grand intérêt, il s'agit maintenant d'y intégrer l'ensemble des annuaires existants, notamment les utilisateurs, groupes, services et hôtes.

Le paquet Debian migrationtools offre un ensemble de scripts qui permettent justement de récupérer les informations depuis les annuaires Unix standards (/etc/passwd, /etc/group, /etc/services, /etc/hosts, etc.), puis de les intégrer dans la base de données LDAP.

Après installation du paquet, il faut éditer le fichier /etc/migrationtools/migrate_common.ph pour activer les options IGNORE_UID_BELOW et IGNORE_GID_BELOW (qu'il suffit de décommenter) et mettre à jour DEFAULT_MAIL_DOMAIN/DEFAULT_BASE.

La mise à jour à proprement parler se fait en exécutant la commande migrate_all_online.sh comme suit :

# cd /usr/share/migrationtools
# LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

Le script migrate_all_online.sh pose plusieurs questions auxquelles il faut répondre correctement pour indiquer la base de données LDAP dans laquelle les données vont être intégrées. Le Tableau 11.1 résume les réponses données dans le cas de Falcot.

Tableau 11.1. Réponses aux questions du script migrate_all_online.sh

Question	Réponse
X.500 naming context	`dc=falcot,dc=com`
LDAP server hostname	`localhost`
Manager DN	`cn=admin,dc=falcot,dc=com`
Bind credentials	Le mot de passe administrateur
Create DUAConfigProfile	Non

La migration du fichier /etc/aliases est volontairement ignorée parce que le schéma standard (installé par Debian) ne comprend pas les structures employées par ce script pour décrire les alias de courrier électronique. S'il est nécessaire d'intégrer cette information dans la base de données LDAP, il faudra ajouter le fichier /etc/ldap/schema/misc.schema comme schéma standard.

On peut également noter l'emploi de l'option -c de la commande ldapadd lui demandant de ne pas s'interrompre en cas d'erreur. Elle est nécessaire car la conversion du fichier /etc/services génère quelques erreurs que l'on peut ignorer sans soucis.

11.7.3. Utiliser LDAP pour gérer les comptes

Maintenant que la base de données LDAP contient des informations, il est temps de les utiliser. Cette section explique comment paramétrer un système Linux afin que les différents annuaires système emploient la base de données LDAP de manière transparente.

11.7.3.1. Configuration de NSS

NSS (Name Service Switch, ou multiplexeur de service de noms, voir encadré POUR ALLER PLUS LOIN Base de données système et NSS) est un système modulaire pour définir ou récupérer les informations des annuaires système. Pour utiliser LDAP comme une source de données NSS, il faut mettre en place le paquet libnss-ldap. Son installation pose plusieurs questions dont les réponses sont résumées dans le Tableau 11.2.

Tableau 11.2. Configuration du paquet libnss-ldap

Question	Réponse
URI du serveur LDAP	`ldapi://ldap.falcot.com`
Nom distinctif de la base de recherche	`dc=falcot,dc=com`
Version de LDAP à utiliser	`3`
Compte LDAP pour le super-utilisateur (root)	`cn=admin,dc=falcot,dc=com`
Mot de passe du compte super-utilisateur LDAP	Le mot de passe administrateur
Allow LDAP admin account behave like local root?	`yes`
La base demande-t-elle un login ?	Non

The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration.

Exemple 11.23. Fichier /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:                files ldap
shadow:                files ldap
group:                files ldap

# consult DNS first, we will need it to resolve the LDAP host. (If we
# can't resolve it, we're in infinite recursion, because libldap calls
# gethostbyname(). Careful!)
hosts:                dns ldap

# LDAP is nominally authoritative for the following maps.
services:   ldap [NOTFOUND=return] files
networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files

# no support for netmasks, bootparams, publickey yet.
netmasks:   files
bootparams: files
publickey:  files
automount:  files

# I'm pretty sure nsswitch.conf is consulted directly by sendmail,
# here, so we can't do much here. Instead, use bbense's LDAP
# rules ofr sendmail.
aliases:    files
sendmailvars:   files

# Note: there is no support for netgroups on Solaris (yet)
netgroup:   ldap [NOTFOUND=return] files

Le module ldap, systématiquement ajouté au début, est donc consulté en premier. Le service hosts fait exception puisque pour contacter le serveur LDAP, il faut consulter le DNS au préalable (pour résoudre ldap.falcot.com). Sans cette précaution, une requête de résolution de nom de machine consulterait le serveur LDAP, ce qui déclencherait une résolution du nom du serveur LDAP, etc., produisant une boucle infinie.

Si l'on souhaite que le serveur LDAP soit la référence unique (et ne pas prendre en compte les fichiers locaux employés par le module files), il est possible de configurer chaque service avec la syntaxe suivante :

service: ldap [NOTFOUND=return] files.

Si l'entrée demandée n'existe pas dans le serveur LDAP, la réponse sera « n'existe pas » même si la ressource existe dans l'un des fichiers locaux, qui ne seront employés que lorsque le service LDAP sera hors d'usage.

11.7.3.2. Configuration de PAM

La configuration de PAM (voir l'encadré EN COULISSES /etc/environment et /etc/default/locale) proposée dans cette section permettra aux applications d'effectuer les authentifications nécessaires à partir des données de la base LDAP.

Il faut installer le module LDAP pour PAM, qui se trouve dans le paquet Debian libpam-ldap. Son installation pose des questions similaires à celles de libnss-ldap et d'ailleurs, certains paramètres de configuration (comme l'URI du serveur LDAP) sont tout simplement partagés avec le paquet libnss-ldap. Les réponses sont résumées dans le Tableau 11.3.

Tableau 11.3. Configuration de libpam-ldap

Question	Réponse
Le super-utilisateur local doit-il être un administrateur de la base LDAP ?	Oui. Cela permet d'utiliser la commande `passwd` habituelle pour changer les mots de passe stockés dans la base LDAP.
La base LDAP demande-t-elle une identification ?	Non
Compte LDAP pour le super-utilisateur (root)	`cn=admin,dc=falcot,dc=com`
Mot de passe du compte super-utilisateur LDAP	Le mot de passe administrateur de la base LDAP
Algorithme de chiffrement à utiliser localement pour les mots de passe	crypt

L'installation de libpam-ldap adapte automatiquement la configuration PAM par défaut définie dans les fichiers /etc/pam.d/common-auth, /etc/pam.d/common-password et /etc/pam.d/common-account. Pour effectuer cela, le paquet s'appuie sur l'utilitaire pam-auth-update prévu à cet usage et fourni par le paquet libpam-runtime. L'administrateur peut également exécuter pam-auth-update pour activer et désactiver à sa guise les modules PAM présents sur le système.

11.7.3.3. Sécuriser les échanges de données LDAP

LDAP est par défaut transporté en clair sur le réseau, ce qui signifie que les mots de passe chiffrés circulent sans précaution particulière. Repérables, ils peuvent donc subir une attaque de type dictionnaire. Pour éviter ce désagrément, il convient d'employer une couche supplémentaire de chiffrement et cette section détaille comment procéder.

11.7.3.3.1. Configuration côté serveur

The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse easy-rsa to generate it (see Section 10.2.2, « Infrastructure de clés publiques easy-rsa »). Running ./easyrsa build-server-full ldap.falcot.com nopass will ask you about the “common name”. The answer to that question must be the fully-qualified hostname for the LDAP server; in our case, ldap.falcot.com.

This command creates a certificate in the pki/issued/ldap.falcot.com.crt file; the corresponding private key is stored in pki/private/ldap.falcot.com.key.

Maintenant que ces clés ont été installées à leur emplacement standard, il faut s'assurer que le fichier contenant leur partie privée est lisible par le serveur LDAP, qui fonctionne avec l'identité utilisateur openldap :

# adduser openldap ssl-cert
Adding user `openldap' to group `ssl-cert' ...
Adding user openldap to group ssl-cert
Done.
# mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key
# chown root:ssl-cert /etc/ssl/private/ldap.falcot.com.key
# chmod 0640 /etc/ssl/private/ldap.falcot.com.key
# ./eassyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1c  28 May 2019
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
........................................................+..........................................................................+...............................................................................+............
[...]
DH parameters of size 2048 created at /home/roland/pki/dh.pem

# mv pki/dh.pem /etc/ssl/certs/ldap.falcot.com.pem

Le démon slapd doit aussi être configuré pour utiliser ces clés de chiffrement. La configuration du serveur LDAP est gérée de manière dynamique : comme elle est stockée dans une partie dédiée de l'annuaire, elle peut être mise à jour avec des opérations LDAP normales sur cette hiérarchie cn=config (et le serveur met à jour /etc/ldap/slapd.d à la volée pour rendre cette configuration persistante). Pour modifier la configuration, on utilisera donc ldapmodify :

Exemple 11.24. Configuration de slapd pour la prise en charge du chiffrement

# cat >ssl.ldif <<END
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key
-
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

OUTIL Éditer un annuaire LDAP avec ldapvi

ldapvi permet d'afficher une représentation LDIF d'une partie de l'annuaire LDAP dans un éditeur de texte. Si l'on effectue des modifications dans cet éditeur, ldapvi les convertira en opérations LDAP et effectuera ces dernières automatiquement.

C'est donc une manière particulièrement pratique de mettre à jour la configuration du serveur LDAP, simplement en éditant la hiérarchie cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

La dernière étape pour activer la mise en place du chiffrement est de modifier la variable SLAPD_SERVICES du fichier /etc/default/slapd. Notons au passage que pour éviter tout risque, on désactive la possibilité de LDAP non sécurisé.

Exemple 11.25. Fichier /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If
# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by
# default)
SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work).  Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
# the init script will not start or restart slapd (but stop will still
# work).  Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab).  To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd
SLAPD_OPTIONS=""

11.7.3.3.2. Configuration côté client

Côté client, il faut modifier la configuration des modules libpam-ldap et libnss-ldap en utilisant une URI en ldaps://.

Les clients LDAP doivent aussi pouvoir s'assurer de l'authenticité du serveur. Dans le contexte d'une infrastructure de clés publiques X.509, les certificats publics sont signés par la clé d'une autorité de certification (certificate authority, ou CA). Les administrateurs de Falcot ont utilisé easy-rsa pour créer leur propre autorité de certification et il faut maintenant configurer le système pour qu'il fasse confiance à cette autorité. Pour cela, il suffit de placer le certificat dans /usr/local/share/ca-certificates et d'exécuter update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt
# update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....

Adding debian:falcot.pem
done.
done.

Pour terminer, il est intéressant de configurer l'URI LDAP et le DN que les divers outils de ligne de commande vont utiliser par défaut. Cela se configure dans /etc/ldap/ldap.conf et évite d'avoir à taper ces paramètres sur chaque ligne de commande.

Exemple 11.26. Fichier /etc/ldap/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE   dc=falcot,dc=com
URI    ldaps://ldap.falcot.com

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt