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

Quarkus : applications Java pour conteneurs

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

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

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

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

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

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 58 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous