Le serveur d’annuaire OpenLDAP a déjà fait l'objet de nombreux articles dans GLMF, expliquant son installation, sa prise en main, la mise en place d'index ou d'ACL. Concentrons-nous aujourd'hui sur la « nouvelle » façon de modifier la configuration du serveur OpenLDAP à chaud.
La configuration à chaud
Un annuaire LDAP est un annuaire électronique, composé d’un ou de plusieurs arbres de données qui centralisent les informations de l’entreprise. Cette structure hiérarchique est appelée DIT (Directory Information Tree). Chaque entrée de l’arbre est un ensemble d’attributs et dispose d’un identifiant unique : son DN (Distinguished Name).
Dans les versions récentes d’OpenLDAP (supérieures à la version 2.4), la configuration n’est plus stockée dans un fichier de configuration plat, mais réside directement dans la base de données elle-même, au sein d’une DIT spécifique. C’est la fonctionnalité OLC (On-Line Configuration), également connue sous le nom de cn=config.
Cette approche consistant à stocker « en ligne » la configuration du serveur pourrait paraître complexe mais elle a été rendue nécessaire pour les gros serveurs d’annuaire, dont les redémarrages à chaque modification de configuration nécessitaient des temps d’arrêt trop longs.
La documentation sur Internet n'est pas toujours à jour sur ce point de vue. Évitez donc tout tutoriel commençant par quelque chose du genre : « modifier le fichier slapd.conf… ». Préférez l’usage des commandes ldapmodify ou ldapadd que nous allons étudier dans les paragraphes suivants.
L'objectif
Cet article va vous guider dans les premières étapes de la configuration d'un serveur OpenLDAP en utilisant la fonctionnalité de configuration à chaud « OLC ».
Les outils
- un serveur CentOS (version 6 de préférence),
- les paquets openldap-servers et openldap-clients,
- le paquet gnutls pour la génération des certificats.
Étape 1 - Préparation du serveur
L’installation d’un serveur OpenLDAP ayant déjà été décrite, nous considérons que vous disposez d’un serveur OpenLDAP fonctionnel. Si ce n’est pas le cas, les quelques instructions suivantes devraient vous permettre de débuter. Tous les exemples de cet article sont issus d’une distribution CentOS 6 mais pourront facilement être adaptés aux autres distributions.
$ sudo yum install openldap-servers openldap-clients
$ sudo cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
$ sudo chown ldap:ldap /var/lib/ldap/DB_CONFIG
$ sudo chkconfig slapd on
$ sudo service slapd start
Pensez à modifier au fur et à mesure de cet article votre fichier /etc/openldap/ldap.conf qui contient les options nécessaires au bon fonctionnement des commandes d’administration du serveur :
#
# LDAP Defaults
#
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldaps://ldap.example.com:636
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERTDIR /etc/openldap/certs
Je vous invite également à visualiser l’arborescence du répertoire /etc/openldap/slapd.d/ (et constatez qu’il n’y a pas de fichier slapd.conf mais un fichier cn=config.ldif qu’il ne faut surtout pas modifier ;-)).
$ sudo tree /etc/openldap/slapd.d/
|-- cn=config
| |-- cn=schema # les schémas disponibles
| | |-- cn={10}ppolicy.ldif
| | |-- cn={1}core.ldif
| | |-- cn={2}cosine.ldif
| | |-- cn={5}inetorgperson.ldif
| | |-- cn={8}nis.ldif
| | |-- cn={9}openldap.ldif
| |-- cn=schema.ldif # le schéma du serveur
| |-- olcDatabase={0}config.ldif
| |-- olcDatabase={-1}frontend.ldif
| |-- olcDatabase={1}monitor.ldif
| |-- olcDatabase={2}bdb.ldif
|-- cn=config.ldif # configuration globale du serveur
Il est intéressant de constater que notre DIT est contenu dans un fichier olcDatabase={2}bdb.ldif.
Sur un serveur CentOS 6, le format par défaut est effectivement le format BDB (Berkeley DataBase), mais cela pourrait différer, l’évolution de BDB étant le HDB (Hierarchical Database).
Étape 2 - Modifier le suffixe LDAP
Le suffixe représente la racine de l’organisation, il est donc l’identité même de l’entreprise. Il correspond habituellement au suffixe DNS.
Le suffixe étant défini à l’installation, il ne faut pas l’ajouter mais le modifier !
Pour modifier ce suffixe, nous allons utiliser la commande ldapmodify. Comme la commande est lancée directement depuis le serveur par une socket sécurisée UNIX (ldapi:///), nous pouvons utiliser le mécanisme SASL EXTERNAL (authentification system) :
$ sudo ldapmodify -Y EXTERNAL -H ldapi:///
dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=glmf,dc=lan
Comme vous pouvez le constater, la modification à chaud de la configuration du serveur n’est pas beaucoup plus complexe que par les fichiers plats mais nécessite toutefois un peu de compréhension du format LDIF et des quelques options de la commande ldapmodify :
- Ligne 1 : la commande ldapmodify permet d’utiliser plusieurs méthodes d’authentification, dont une authentification SASL. L’utilisation du protocole ldapi:/// est nécessaire pour utiliser l’authentification externe ;
- Ligne 2 : nous allons changer la configuration de notre DIT principale, donc le dn: olcDatabase={2}bdb,cn=config. Si dans votre cas, le serveur utilise une base hdb, il faudra en tenir compte ici ;
- Ligne 3 : il existe plusieurs types de changement au niveau de l’objet : ajouter (add), supprimer (delete) ou modifier (modify), … ;
- Ligne 4 : nous demandons à modifier un objet de l’annuaire. Nous pouvons donc ajouter (add), supprimer (delete) ou remplacer (replace) un attribut. Il est bien entendu possible de faire plusieurs actions sur les attributs avec une seule commande LDIF ;
- Ligne 5 : le nouveau suffixe sera dans notre exemple : dc=glmf,dc=lan. Notez que le nom de l’attribut a été suffixé d’un olc pour devenir olcSuffix ;
- Ligne 6 : pour que la commande ldapmodify soit exécutée, il vous faudra saisir une ligne vide à la fin du contenu au format LDIF.
Maintenant que vous maîtrisez les rudiments de la commande ldapmodify, vous allez pouvoir modifier les autres éléments importants de la configuration du serveur : olcRootDN et olcRootPW.
Étape 3 - Modifier le RootDN et son mot de passe
L’entrée RootDN contient le DN de l’utilisateur autorisé à faire des modifications de l’annuaire. Son mot de passe est défini par RootPW.
Pour rappel, un mot de passe SSHA pour OpenLDAP est généré par la commande slappasswd :
$ /usr/sbin/slappasswd
New password:
Re-enter new password:
{SSHA}Eke0fnWgD90xzWPT/UivZEBjzBgC/z+r
Le mot de passe RootPW n’étant pas défini à l’installation, il ne faut pas le modifier mais cette fois-ci l’ajouter !
De manière identique au changement du suffixe vu précédemment, configurez avec la commande ldapmodify le nouveau rootDN et son mot de passe :
$ sudo ldapmodify -Y EXTERNAL -H ldapi:///
dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,dc=glmf,dc=lan
-
add: olcRootPW
olcRootPW: {SSHA}Eke0fnWgD90xzWPT/UivZEBjzBgC/z+r
Notez que les deux actions (le remplacement puis l’ajout) ont été effectuées depuis le même appel à la commande ldapmodify, en les séparant par une ligne contenant un simple tiret.
Un RootDN et son mot de passe ayant maintenant été définis dans la DIT dc=glmf,dc=lan, il est possible de les utiliser pour se connecter et tester les modifications effectuées :
$ ldapsearch -x -D cn=admin,dc=glmf,dc=lan -b dc=glmf,dc=lan -W
Enter LDAP Password:
...
Il n’est pas nécessaire de préciser le serveur à contacter (options -H ou -h), la commande ldapmodify utilisera les informations du fichier /etc/openldap/ldap.conf qui aura été renseigné au préalable.
Étape 4 - Modifier le niveau de verbosité des journaux
Durant votre mise en œuvre du serveur OpenLDAP, vous serez très certainement amenés à surveiller les logs du service. Ceux-ci pouvant devenir très verbeux, il n’est pas conseillé de laisser un haut niveau de log en permanence. L’utilisation de l’OLC va s’avérer particulièrement pertinente dans ce cas puisqu’il ne sera pas nécessaire de relancer le serveur à chaque modification de la verbosité des logs.
OpenLDAP envoie par défaut ses logs vers syslog avec le label local4.
Le service rsyslog devra être configuré pour prendre en compte ces logs. Créez le fichier /etc/rsyslog.d/slapd.conf et ajoutez les lignes suivantes :
# Enregistrer les logs LDAP
local4.* /var/log/sldapd.log
La configuration de rsyslog ayant été modifiée, il faut relancer le service :
$ sudo service rsyslog restart
Les logs peuvent maintenant être suivis :
$ sudo tail -f /var/log/sldapd.log
Feb 13 08:27:55 serveur slapd[4232]: @(#) $OpenLDAP: slapd 2.4.39 (Oct 15 2014 09:45:30) $#012#011mockbuild@c6b8.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/build-servers/servers/slapd
Il est possible de modifier la verbosité des logs :
$ sudo ldapmodify -Y EXTERNAL -H ldapi:///
dn: cn=config
replace: olcLogLevel
olcLogLevel: 8
La valeur du log est calculée en additionnant les valeurs ci-dessous :
Valeur |
Mot Clef |
Information fournie |
-1 |
any |
Affichage de toutes les informations. |
|
|
Aucun affichage. |
1 |
trace |
Liste des appels de fonctions. |
2 |
packets |
Affichage du traitement des paquets. |
4 |
args |
Affichage détaillé des appels. |
8 |
conns |
Affichage des connexions. |
16 |
BER |
Affichage des paquets reçus et émis. |
32 |
filter |
Affichage du traitement d’un filtre. |
64 |
config |
Affichage du traitement du fichier de configuration. |
128 |
ACL |
Affichage du traitement des permissions de chaque opération (très utile pour la mise au point des règles d’autorisation). |
256 |
stats |
Affichage du résultat des opérations. |
512 |
stats2 |
Affichage des statistiques. |
1024 |
shell |
Affichage des communications avec les backends de type shell. |
2048 |
parse |
Affichage du traitement des entrées. |
16384 |
sync |
Affichage des opérations syncrepl. |
La modification précédente active donc l’affichage des connexions. Pour afficher en plus le traitement des ACL, la commande pourrait par exemple être modifiée par :
$ sudo ldapmodify -Y EXTERNAL -H ldapi:///
dn: cn=config
replace: olcLogLevel
olcLogLevel: conns ACL # ou 136 (8+128)
Étape 5 - Sécuriser le service avec TLS
Un serveur d’annuaire n’en est pas un sans l’activation du TLS (en startTLS sur le port 389 ou en ldaps sur le port 636).
Avant de pouvoir configurer le TLS sous OpenLDAP, il convient de disposer du certificat et de la clef pour le serveur ainsi que le certificat de l’autorité de certification, qui est indispensable au bon fonctionnement d’OpenLDAP.
Pour créer ces certificats, il est possible d’utiliser easy-rsa, l’outil certtool du paquet gnutls-utils ou pourquoi pas Let’s encrypt (voir Linux Pratique n°94).
Si l’accès au serveur LDAP se fait via le FQDN ldap.glmf.lan, il faudra impérativement créer le certificat qui répondra à ce nom. Il ne sera plus possible par la suite de se connecter en LDAPS ou en starttls via l’adresse de loopback localhost. Ajoutez au besoin une entrée dans votre fichier /etc/hosts pour vous assurer de la bonne résolution du nom et n’oubliez pas de modifier le fichier /etc/openldap/ldap.conf.
5.1 Création des certificats avec certtools
Installer le paquet gnutls-utils :
$ sudo yum install gnutls-utils
Dans le cas d’un certificat autosigné, il faut dans un premier temps créer une clef privée pour l’autorité de certification :
$ sudo certtool --generate-privkey --outfile /etc/pki/CA/private/ca-key.key
Et décliner cette clef privée en certificat public :
$ sudo certtool --generate-self-signed --load-privkey /etc/pki/CA/private/ca-key.key --outfile /etc/pki/CA/certs/ca-cert.pem
Il faut ensuite générer un certificat privé pour le serveur (ldap.glmf.lan par exemple) :
$ sudo certtool --generate-privkey --outfile /etc/pki/tls/private/ldap.key
Puis son certificat public signé par la clef privée de l’autorité de certification créée ci-dessus :
$ sudo certtool --generate-certificate --load-privkey /etc/pki/tls/private/ldap.key --outfile /etc/pki/tls/certs/ldap.pem --load-ca-certificate /etc/pki/CA/certs/ca-cert.pem --load-ca-privkey /etc/pki/CA/private/ca-key.key
Positionnez les droits sur les certificats :
$ sudo chmod 640 /etc/pki/tls/certs/ldap.pem
$ sudo chmod 640 /etc/pki/tls/private/ldap.key
$ sudo chmod 644 /etc/pki/CA/certs/ca-cert.pem
$ sudo chgrp ldap /etc/pki/tls/certs/ldap.pem
$ sudo chgrp ldap /etc/pki/tls/private/ldap.key
$ sudo chgrp ldap /etc/pki/CA/certs/ca-cert.pem
5.2 Prendre en compte les certificats
Créez le fichier /tmp/tls.ldif :
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/ldap.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/pki/CA/certs/ca-cert.pem
Modifiez à chaud la configuration du serveur (en fournissant à la commande ldapmodify le fichier ldif) :
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/tls.ldif
La chaîne de connexion du fichier /etc/openldap/ldap.conf doit également être mise à jour :
BASE dc=glmf,dc=lan
URI ldaps://ldap.glmf.lan
TLS_CACERTDIR /etc/pki/CA/certs/
TLS_REQCERT try
La commande cacertdir_rehash permet de créer un lien symbolique vers le certificat de la CA dont le nom correspond au hash de ce certificat. Ceci est nécessaire au fonctionnement d’openLDAP en TLS ! Chez Debian, il faudra se tourner vers la commande update-ca-certificates.
$ sudo cacertdir_rehash /etc/pki/CA/certs
$ ls -l /etc/pki/CA/certs
-rw-r--r--. 1 root root 1281 4 déc. 10:52 ca-cert.pem
lrwxrwxrwx. 1 root root 11 4 déc. 10:54 ce6a8cab.0 -> ca-cert.pem
Par défaut, le service slapd n’écoute pas sur le port 636 (ldaps) et il faut privilégier le startTLS sur le port 389.
Pour activer le ldaps :
SLAPD_LDAPS=yes
Sans oublier de relancer le serveur :
$ sudo service slapd restart
5.3 Tester la connexion
La commande openssl permet de tester la connexion uniquement sur le port 636 :
$ openssl s_client -connect ldap.glmf.lan:636 -showcerts
Vous pouvez également utiliser l’option -ZZ de la commande ldapsearch pour forcer le TLS :
ldapsearch -x -D cn=admin,dc=glmf,dc=lan -b dc=glmf,dc=lan -W -ZZ
Au besoin, pensez à ouvrir votre pare-feu…
Résultat
Nous voici au terme de cet article. Le serveur est opérationnel et les transactions sont sécurisées par TLS. Comme vous avez pu le constater, utiliser les possibilités de configuration à chaud du serveur OpenLDAP est accessible. Nous en avons également profité pour donner quelques astuces sur la configuration du TLS sur une CentOS 6, c'est toujours bon à prendre !
Merci à Patrick Finet et Xavier Sauvignon pour leur précieuse relecture !