Configurer à chaud votre serveur OpenLDAP

Magazine
Marque
GNU/Linux Magazine
Numéro
195
Mois de parution
juillet 2016
Domaines


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.

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

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

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 !




Articles qui pourraient vous intéresser...

Répondez aux problématiques de sécurité d’accès avec OpenSSH

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Notre infrastructure est désormais stable et sécurisée tant au niveau système que réseau. Nous allons pouvoir étudier de manière un peu approfondie un logiciel particulier : OpenSSH. Ce démon réseau nous permet de nous connecter en toute sécurité sur nos serveurs via le protocole SSH. Son développement a commencé il y a plus de 20 ans chez nos amis d’OpenBSD. La liste de ses fonctionnalités est d’une longueur impressionnante. Nous allons en parcourir ensemble quelques-unes qui, je l’espère, nous permettront d’améliorer tant notre sécurité que notre productivité quotidienne.

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.

Migrez de iptables vers nftables

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Il y a cinq ans, je lisais un premier article sur nftables [1] : l’outil semblait intéressant, mais il n’était pas disponible sur ma machine. En 2019, une distribution majeure, Debian, a basculé sur nftables avec sa version 10 (Buster) [2] : il est donc temps de voir comment migrer du vénérable pare-feu iptables vers son successeur.

Sauvegardez vos données, centralisez vos logs et supervisez votre sécurité

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.

Sécurisez votre réseau

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Maintenant que notre serveur principal est déployé et que nous y avons appliqué un premier niveau de sécurisation système, occupons-nous de sa sécurisation réseau. Nous allons détailler en quoi les attaques réseau sont primordiales dans notre modèle de menace. Comme nous le verrons, l’accès distant est le risque principal qui guette nos serveurs. Nous allons mettre en œuvre une sécurité en profondeur et les mesures de protection réseau en seront une de ses dimensions importantes.