Annuaires LDAP avec OpenLDAP

Slapd est le serveur LDAP de la suite logicielle Openldap. Il répond donc aux requêtes des clients LDAP, quels qu'ils soient, et quelle que soit la librairie LDAP sur laquelle ils sont construits.

Un serveur slapd est configuré pour n'écouter qu'un seul port, à la différence d'autres serveurs comme Apache. Néanmoins un même serveur slapd permet de répondre aux requêtes de plusieurs annuaires, c'est-à-dire d'annuaires qui ont des suffixes différents.

Mais dans ce cas les annuaires servis par une même instance de slapd vont partager un certain nombre de caractéristiques (permissions, index, etc.), ce qui n'est pas toujours souhaitable. Donc si l'on veut qu'une même machine serve plusieurs annuaires il est parfois nécessaire de faire tourner plusieurs instances du serveur slapd, chacun écoutant un port différent et chacun ayant son propre fichier de configuration slapd.conf.

La configuration d'un serveur slapd consiste tout d'abord à définir son identité. L'identité d'un serveur est donnée par le port que le serveur va écouter, et par les annuaires qu'il va servir, chaque annuaire étant défini par un suffixe.

La définition du schéma des données servies par un serveur, et les permissions contrôlant l'accès à ces données font partie des autres informations de configuration d'un serveur slapd.

S'il l'on voit l'intérêt de partager des schémas, des définitions d'objets, entre plusieurs annuaires, le partage de permission entre ces mêmes annuaires peut se révéler être beaucoup plus gênant.

La manière dont sont stockées les données d'un serveur slapd fait aussi partie des informations de configuration. Le stockage des données est défini par un backend. De la même façon qu'une même instance de serveur slapd peut servir plusieurs annuaires, une même instance de serveur slapd peut avoir plusieurs backends, dans lesquels elle va stocker ses différents annuaires.

Un fichier de configuration d'un serveur slapd est logiquement divisé en trois sections :

• Configuration globale
• Spécifique à un backend
• Spécifique à un annuaire

La structure d'un fichier de configuration est la suivante :

# global configuration directives
<global config directives>
 
# first backend definition
backend <typeA>
<backend-specific directives>
 
# first database definition & config directives of the first backend
database <typeA>
<database-specific directives>
 
# second database definition & config directives of the first backend
database <typeA>
<database-specific directives>
 
# second backend definition
backend <typeB>
<backend-specific directives>
 
# first database definition & config directives of the second backend
database <typeB>
<database-specific directives>
 
# second database definition & config directives of the second backend
database <typeB>
<database-specific directives>

On distingue les trois sections décrites précédemment.

Il est possible d'inclure d'autre fichier dans un fichier de configuration :

include <nom de fichier>

Cette directive permet d'inclure un fichier externe dans le fichier de configuration, à l'endroit où elle se trouve. Le fichier inclus fera partie intégrante du fichier de configuration, c'est-à-dire qu'il devra respecter la même syntaxe.

defaultaccess  { none | compare | search | read | write }

Cette directive donne l'accès accordé par défaut aux clients lorsqu'aucune clause de permission n'est présente dans le reste du fichier de configuration, ou bien lorsqu'aucune de ces clauses ne correspond.

password-hash { SSHA | SHA | SMD5 | MD5 | CRYPT }

Cette directive indique le hashage utilisé pour le stockage des mots de passe dans l'annuaire. Par défaut le hashage utilisé est SSHA.

access to "clause d'accès"

Cette directive inclut une clause d'accès. Un chapitre lui est dédié

schemacheck { On | Off }

Cette directive indique si le serveur slapd devra vérifier si les objets de l'annuaire respectent ou pas le schéma, lors d'une insertion ou d'une modification.
Il n'y a généralement aucune raison de désactiver la vérification du schéma en dehors de la phase de développement de l'annuaire, lorsque des composants ne sont pas encore finis.

attributetype <RFC2252 Attribute Type Description>,  objectclass <RFC2252 Object Class Description>

Ces deux directives permettent de définir respectivement des attributs et des classes d'objets. Avant de définir ses propres attributs et ses propres objets, il faut inclure les schémas standards. De plus les attributs doivent être définis avant les objets. La syntaxe et l'usage de ces directives seront étudiés dans un autre chapitre.

Nous allons voir dans cette section les directives qui permettent de gérer les ressources utilisées par un serveur slapd.

idletimeout

Cette directive prend pour valeur un entier qui indique le nombre de secondes qu'attendra un serveur avant de fermer de force la connexion à un client inoccupé. La valeur par défaut, 0, permet de désactiver cette option.

sizelimit

Cette directive prend pour valeur un entier qui spécifie le nombre maximum d'entrées retournées par une recherche dans l'annuaire. La valeur par défaut est 500.

timelimit

Cette directive prend pour valeur un entier qui sera la durée maximale, en secondes, que le serveur passera à répondre à une requête. Si une demande n'est pas terminée pendant ce temps, une erreur de type « exceeded timelimit » sera envoyée au client. La valeur par défaut est 3600 (une heure).

backend <backend type>

Cette directive ouvre une section dédiée à un backend particulier. Elle définit le type de backend. Les valeurs possibles sont les suivantes :

La plupart des backends nécessitent leurs propres directives pour être configuré correctement. Nous y reviendrons plus tard

Une section database commence dans le fichier de configuration par une directive database, dont la valeur est celle du backend auquel appartient la base de données.

suffix DN

Indique le nœud que la base de données va gérer.

lastmod on | off

Indique si la base de données doit enregistrer les modifications effectuées dans des attributs dédiés. Ces attributs sont les suivants: modifiersName, modifyTimestamp, creatorsName, and createTimestamp. Par défaut la valeur on. Pour certains backend il est nécessaire qu'elle soit à off.

readonly on | off

Cette option met la base en lecture seule.

rootdn <DN>

Utilisateur dont les accès ne seront pas soumis aux clauses d'accès.

rootpw <mot de passe>

Le mot de passe de l'utilisateur rootdn. Ce mot de passe peut être stocké sous forme hashé.

Les directives suivantes permettent de contrôler comment s'effectue la réplication d'un annuaire. Toutes ces directives sont spécifiques à une database.

replica host <hostname>[:<port>] [bindmethod={ simple | kerberos | sasl }]
 replogfile <filename>
 updatedn <DN>

Dans le cas où une faille existerait dans le daemon slapd, il est souhaitable d'éviter que cette faille potentielle conduise à un accès avec des droits superutilisateurs (root). Pour ce faire il est possible de faire fonctionner le daemon slapd sous une identité autre que root.

Voici comment mettre en place une telle configuration:

1. arrêter slapd s'il est en fonctionnement

/etc/init.d/slapd stop

2. créer un groupe et un utilisateur dédié

groupadd ldap
useradd -s /bin/false -d /var/lib/ldap -g ldap ldap

3. créer un sous-répertoire pour placer le fichier de pid

mkdir -p /var/run/slapd

4. modifier en conséquence les directives pidfile et argsfile dans /etc/ldap/slapd.conf

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

5. appliquer les droits nécessaires sur les répertoires utilisés par slapd

# Sur le répertoire de configuration: 
chown -R ldap:ldap /etc/ldap
# Sur le répertoire de stockage: 
chown -R ldap:ldap /var/lib/ldap
# Sur le répertoire de "fonctionnement": 
chown ldap:ldap /var/run/slapd

6. relancer slapd avec les options appropriées et/ou modifier le script de démarrage

/usr/sbin/slapd -u ldap -g ldap

7. sous Debian GNU/Linux 3.0 (openldap 2.0.23), on peut modifier le script de démarrage /etc/init.d/slapd en ajoutant ces options à la ligne suivante

start-stop-daemon --start --quiet --pidfile "$pf" --exec /usr/sbin/slapd
start-stop-daemon --start --quiet --pidfile "$pf" --exec /usr/sbin/slapd -- -u ldap -g ldap

8. Sous Debian GNU/Linux testing ou unstable (openldap 2.1.23/2.1.25) il suffit de mettre le nom de l'utilisateur et du groupe dans le fichier /etc/default/slapd (variables SLAPD_USER et SLAPD_GROUP).

Afin d'assurer la confidentialité des informations véhiculées par le protocole ldap, il peut être utile de mettre en place le système de cryptage ssl.

Une attaque pouvant être effectuée sur la base ldap elle même (fichiers db… suivant le backend choisi), il convient de stocker les mots de passe (les données à priori les plus sensibles) avec un cryptage fort et irréversible. Openldap support en standard les formats suivants (du plus sécurisé au moins sécurisé) :

• md5
• sha
• des
• clear