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.

L'installation du paquet slapd est généralement peu interactive, et le résultat ne répond que rarement aux besoins. Heureusement, il suffit de lancer la commande dpkg-reconfigure slapd pour reconfigurer la base de données LDAP plus en détail :

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.
Faut-il autoriser LDAPv2 ? Non, ce n'est pas la peine. Tous les outils que nous employons connaissent LDAPv3.

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 sub
# filter: (objectclass=*)
# requesting: ALL
#

# falcot.com
dn: dc=falcot,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Falcot SA
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	`ldap://ldap.falcot.com`
Nom distinctif de la base de recherche	`dc=falcot,dc=com`
Version de LDAP à utiliser	`3`
La base demande-t-elle un login ?	Non
Faut-il donner les privilèges de superutilisateur local au compte administrateur LDAP ?	Oui
Doit-on rendre le fichier de configuration lisible et modifiable uniquement par son propriétaire ?	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

Il faut ensuite modifier le fichier /etc/nsswitch.conf pour lui indiquer d'employer le module ldap fraîchement installé.

Exemple 11.26. Fichier /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: ldap compat
group: ldap compat
shadow: ldap compat

hosts: files dns ldap
networks: ldap files

protocols: ldap db files
services: ldap db files
ethers: ldap db files
rpc: ldap db files

netgroup: ldap 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

La première étape consiste à créer une biclé (clé publique et clé privée) pour LDAP. Pour cela, les administrateurs de Falcot réutilisent easy-rsa (voir la Section 10.2.1.1, « Infrastructure de clés publiques easy-rsa »). L'exécution de la commande ./build-key-server ldap.falcot.com pose plusieurs questions banales (lieu, nom de l'organisation, etc.). Il est impératif de répondre à la question Common Name par le nom complet du serveur LDAP ; en l'occurrence il s'agit donc de ldap.falcot.com.

La commande précédente a généré un certificat dans le fichier keys/ldap.falcot.com.crt et la clé privée correspondante est stockée dans keys/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 keys/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
# mv newcert.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.27. 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.28. 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 keys/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.29. 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