Configurer à chaud votre serveur OpenLDAP

Magazine
Marque
GNU/Linux Magazine
Numéro
195
Mois de parution
juillet 2016
Spécialité(s)


Résumé

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.


Body

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 !



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous