IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Annuaires LDAP avec OpenLDAP


précédentsommairesuivant

V. Configuration des serveurs OpenLDAP

Dans ce chapitre nous étudierons comment configurer les serveurs de la suite logicielle Openldap.

V-A. Le serveur slapd

V-A-1. Présentation du serveur slapd

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.

V-A-2. Configuration du serveur slapd

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

V-B. Détail du fichier de configuration

V-B-1. Structure générale

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

 
Sélectionnez
# 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 :

 
Sélectionnez
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.

Les fichiers sont très utiles pour séparer la définition du schéma de l'annuaire, ou les permissions, du reste du fichier de configuration.

Il est possible d'inclure à nouveau un fichier dans un fichier déjà inclus. Néanmoins aucune vérification de boucle n'est faite. Il faut donc se méfier des boules infinies.

V-B-2. Directives générales

loglevel <entier>

 

Cette directive est un entier qui indique le niveau de débogage du serveur. Sa valeur indique le type d'informations qui vont être transmises au système (dans syslogd). La valeur de la directive est une combinaison additive de valeurs de base, dont les plus utiles sont les suivantes (la liste complète est dans le manuel d'OpenLdap)

 

-1

Permet d'affichage toutes les valeurs de débogage, ce qui peut très vite se montrer illisible

 

0

Aucune valeur de débogage

 

32

Affiche le processus de recherche d'un filtre

 

64

Affiche le processus de parsage du fichier de configuration

 

128

Affiche le calcul des permissions de chaque opération. Cette valeur est évidemment très utilisée lorsqu'on met en place les permissions pour valider le bon déroulement des accès, en lecture comme en écriture, aux objets de la base

 

256

Affiche le résultat de chaque opération (succès, échec, permission refusée, etc.)

referral <URI>

 

Cette directive donne le referral qui sera retourné aux clients lorsque le serveur ne peut pas répondre à une requête qui lui est soumise. Cela arrive lorsqu'une requête s'exécute à partir d'un nœud qui n'est pas dans les suffixes gérés par le serveur.

Sur un annuaire en production, il est préférable de ne pas laisser un niveau de log trop élevé. Certains niveaux de log trop bavards, comme le 128, peuvent en certaines circonstances ralentir l'annuaire à cause d'écritures trop fréquentes et trop importantes dans le fichier syslog.

V-B-3. Directives sur la sécurité

 
Sélectionnez
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.

 
Sélectionnez
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.

 
Sélectionnez
access to "clause d'accès"

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

V-B-4. Directives sur les schémas

 
Sélectionnez
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.

 
Sélectionnez
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.

V-B-5. Gestion des ressources

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

 
Sélectionnez
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.

 
Sélectionnez
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.

 
Sélectionnez
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).

V-B-6. Directives des sections backend

 
Sélectionnez
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 :

bdb

Backend base de données transactionnelle Berkeley

ldbm

Backend basé sur des fichiers de format DBM, ou GDBM, le plus facile à installer

dnssrv

Ce backend retourne des referrals en se basant sur le champ SRV des enregistrements DNS

ldap

Backend proxy, qui transmet les requêtes entrantes à un autre LDAP serveur. Un server proxy permet de mutualiser entre les différents clients les connexions à un serveur distant

meta

Backend similaire au backend ldap, mais offrant des possibilités supplémentaires pour présenter aux clients un ensemble de serveur LDAP comme étant un seul serveur LDAP grâce à des mécanismes de traduction du nom des objets

monitor

Le backend monitor n'est pas vraiment un backend. Il permet d'accéder à des informations sur le serveur

passwd

Backend qui s'appuie sur le fichier /etc/passwd. Il n'est utilisé qu'à des fins de démonstration

perl, shell

Ces deux backends exécutent chaque commande ldap, soit par l'intermédiaire d'un objet perl, soit par un programme externe quelconque

sql

Backend qui s'appuie sur une base de données SQL, de type ODBC. Ce backend nécessite beaucoup de configuration pour transformer les requêtes ldap en requêtes SQ

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

V-B-7. Directives d'une section database

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.

 
Sélectionnez
suffix DN

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

 
Sélectionnez
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.

 
Sélectionnez
readonly on | off

Cette option met la base en lecture seule.

 
Sélectionnez
rootdn <DN>

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

 
Sélectionnez
rootpw <mot de passe>

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

V-B-8. Directives de réplication

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

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

V-C. Sécurisation des serveurs OpenLDAP

Dans ce chapitre nous étudierons comment sécuriser les serveurs de la suite logicielle OpenLDAP.

V-C-1. Utiliser un utilisateur sans privilèges pour faire tourner openldap

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

 
Sélectionnez
/etc/init.d/slapd stop

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

 
Sélectionnez
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

 
Sélectionnez
mkdir -p /var/run/slapd

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

 
Sélectionnez
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

 
Sélectionnez
# 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

 
Sélectionnez
/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

 
Sélectionnez
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).

V-C-2. Crypter les communications

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.

V-C-3. Choisir un hashage fort pour les mots de passe

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

précédentsommairesuivant

Copyright (c) 2005, Michaël Parienti Maire. This work is licensed under the Creative Commons Attribution-Share Alike License. Modifications, reproductions, diffusions autorisées à condition de mentionner le nom de l'auteur original et de conserver les termes de cette licence Creative Commons.