Installation et configuration de OpenLDAP

Tuto plus vraiment à jour (a l'origine écrit sous debian lenny)

Installation

Pour installer OpenLDAP :

# aptitude install ldap-server ldap-client

La configuration de openldap se fait dans /etc/ldap/. Le daemon OpenLDAP s'appèle slapd. Voici un exemple de fichier slapd.conf :

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Features to permit

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/mozillaorgperson.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        296
schemacheck on

modulepath	/usr/lib/ldap
moduleload	back_bdb

sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend		bdb
checkpoint 512 30

TLSCertificateFile      /etc/ldap/ssl/ldap.pem
TLSCertificateKeyFile   /etc/ldap/ssl/ldap.key
TLSCACertificateFile    /etc/ldap/ssl/ca.pem
TLSCipherSuite          HIGH

require authc
password-hash {SSHA}
#disallow bind_v2

database        bdb
suffix          "dc=domain,dc=tld"
rootdn          "cn=admin,dc=domain,dc=tld"
rootpw		{SSHA}HJsgK682kFZk
directory       "/srv/ldap/domain/"
#cache de 2MB
dbconfig set_cachesize 0 2097152 0 
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index           objectClass eq
lastmod         on
# replogfile	/var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=domain,dc=tld" write
        by anonymous auth
        by self write
        by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work 
# happily.
#access to dn.base="" by * read

access to dn.subtree="ou=pfoo,ou=addressbook,dc=domain,dc=tld"
        by dn="cn=pfoo,ou=users,dc=domain,dc=tld" write
        by * none

access to dn="ou=users,dc=domain,dc=tld"
        by * none

access to dn="ou=addressbook,dc=domain,dc=tld"
        by dn.children="ou=users,dc=domain,dc=tld" read
        by * none

access to dn="dc=domain,dc=tld"
        by dn="cn=admin,dc=domain,dc=tld" write
	by dn.children="ou=users,dc=domain,dc=tld" read
        by * none

access to *
        by dn="cn=admin,dc=domain,dc=tld" write
        by * none

#######################################################################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database        <other>

# The base of your directory for database #2
#suffix		"dc=debian,dc=org"

Configuration globale

Les schémas

C'est la première chose à définir, a savoir, quels schémas le serveur doit supporter. Les schémas sont placés dans /etc/ldap/schema. Voici ceux que j'utilise :

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

Log et exécution

Pour que slapd log les actions effectués, il faut définir le niveau de log avec la directive loglevel. Voici un petit tableau récapitulant les différents loglevels :

Niveau 	Description
-1 	enable all debugging
0 	no debugging
1 	trace function calls
2 	debug packet handling
4 	heavy trace debugging
8 	connection management
16 	print out packets sent and received
32 	search filter processing
64 	configuration file processing
128 	access control list processing
256 	stats log connections/operations/results
512 	stats log entries sent
1024 	print communication with shell backends
2048 	print entry parsing debugging

Vous pouvez additionner les différents niveaux de log pour bénéficier de plusieurs options de log.
Pour que les logs fonctionnent, ajoutez la ligne suivante dans /etc/syslog.conf puis redémarrez syslog (/etc/init.d/sysklogd restart) :

local4.*         /var/log/ldap.log

D'autres directives doivent être définies :

• pidfile filename : spécifie le fichier dans lequel le pid de slapd sera stocké.
• argsfile filename : spécifie le fichier où les arguments qu'il faut passer à slapd lors de son lancement sont stockés.
• schemacheck on|off : spécifie s'il faut vérifier la conformité de toutes les entrées aux schémas configurés

Dans mon cas :

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        296
schemacheck on

Autres options

• modulepath : spécifie où sont stockés les modules.
• moduleload : spécifie les modules à loader.
• sizelimit : spécifie le nombre maximum d'entrée retourné lors d'une recherche

Ma configuration :

modulepath      /usr/lib/ldap
moduleload      back_bdb
sizelimit 500

SSL

slapd permet de sécuriser les transactions en SSL. Voici la configuration que j'utilise :

TLSCertificateFile      /etc/ldap/ssl/ldap.pem
TLSCertificateKeyFile   /etc/ldap/ssl/ldap.key
TLSCACertificateFile    /etc/ldap/ssl/ca.pem
TLSCipherSuite          HIGH

Définition des directives :

• TLSCertificateFile: spécifie l'emplacement du certificat du serveur.
• TLSCertificateKeyFile: spécifie l'emplacement de la clé privée du certificat.
• TLSCACertificateFile: spécifie l'emplacement du certificat de la CA qui a permit de signer le certificat de slapd.
• TLSCipherSuite: spécifie les spécifications de chiffrement

La section du fichier de configuration de openssl correspondante :

[OPENLDAP]
nsComment                       = "OpenLDAP Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
extendedKeyUsage                = serverAuth

Autres options de sécurité

• password-hash : spécifie la méthode de cryptage des mots de passe par défaut. Les différentes options possible sont :
  • {CRYPT} : utilise la fonction crypt() de unix
  • {MD5} : hachage par MD5
  • {SHA} : hachage en SHA-1
  • {SSHA} : (Salted Secure Hash Algorithm) hachage en SHA-1 avec un meilleur support du seed. C'est l'option recommandée.
• require : spécifie les conditions d'accès au serveur. Les options possibles sont :
  • none
  • authc : tout client doit s'authentifier
• allow et disallow : permet d'autoriser ou de ne pas autoriser certaines fonctions.

Ma configuration :

require authc
password-hash {SSHA}

Configuration de la base de donnée

Ajout d'une base

Dans mon exemple, j'ajoute les lignes suivantes au fichier /etc/ldap/slapd.conf :

database        bdb
suffix          "dc=domain,dc=tld"
rootdn          "cn=admin,dc=domain,dc=tld"
rootpw          {SSHA}Xe7Lb0SZi8B7F4CiqwRV8t3cm0R2XdYc
directory       "/srv/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index           objectClass eq
lastmod         on
# replogfile    /var/lib/ldap/replog

Une petite explication :

• database bdb : spécifie qu'on créé une base de donnée de type bdb (berkeley DB). Toute les lignes suivant celle-ci s'appliqueront à cette base de donnée jusqu'à ce qu'une autre base de donnée soit définie par la même directive.
• suffix : spécifie la racine de la base
• rootdn : défini le super-utilisateur de la base de donnée. C'est lui qui aura tous les pouvrois.
• rootpw : défini le mot-de-passe du super-utilisateur. Pour générer le mot-de-passe, utilisez la commande /usr/sbin/slappasswd -h '{SSHA}' -s password -v où password est le mot-de-passe souhaité.
• directory : spécifie le dossier dans lequel la base de donnée sera créée.
• dbconfig set_cachesize : spécifie la taille du cache
• index : spécifie les options d'indexation pour accélérer les recherches. Les types d'index supportés sont :
  • approx (approximate)
  • eq (equality)
  • pres (presence)
  • sub (substring)
• lastmod : spécifie s'il faut garder en mémoire la dernière modification des entrées
• replogfile : spécifie le dossier où sont stockés les logs de réplication. C'est fonction est utile si vous faite de la réplication entre plusieurs serveurs ldap

Configuration des ACLs de la base

Les ACLs définissent qui a accès à quoi dans la base de donnée. Tout d'abord, on va définir les accès aux mots-de-passes.

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=domain,dc=tld" write
        by anonymous auth
        by self write
        by * none

Petite explication :

• access to : spécifie pour quoi on défini des accès. Dans le cas présent, c'est l'accès aux mots-de-passes
• by dn="cn=admin,dc=domain,dc=tld" write : autorise l'accès en écriture par le super-utilisateur admin. L'accès en écriture signifie un accès complet.
• by anonymous auth : autorise aux utilisateurs anonymes de se loguer
• by self write : autorise l'utilisateur à changer son propre mot-de-passe
• by * none : restreint l'accès à tous les autres utilisateurs.

Les permissions d'accès se définissent dans l'ordre de haut en bas. Les premières permissions doivent être les plus précises, et les dernières les plus générales. Par exemple, ici, on interdit l'accès à tous le monde en dernier, mais les permissions précédentes restent valides. Si on avait interdit l'accès en ajoutant une ligne by * none à la première ligne, les lignes suivantes n'auraient pas été appliqué. Maintenant, on va définir les accès à la structure de la base. Voici la structure qu'on va mettre en place :

Précédemment, on a défini la racine de notre base avec la directive suffix On va définir un ou addressbook. Un ou peut s'apparenter à un sous-dossier Ensuite, on va définir dans le ou addressbook d'autres ou pour chaque utilisateurs.

A la racine, nous allons aussi créer un ou users qui contiendra les utilisateurs de la base de donnée

Voici les permissions correspondantes pour cette structure :

access to dn.subtree="ou=pfoo,ou=addressbook,dc=domain,dc=tld"
        by dn="cn=pfoo,ou=users,dc=domain,dc=tld" write
        by * none

access to dn="ou=users,dc=domain,dc=tld"
        by * none

access to dn="ou=addressbook,dc=domain,dc=tld"
        by dn.children="ou=users,dc=domain,dc=tld" read
        by * none

access to dn="dc=domain,dc=tld"
        by dn="cn=admin,dc=domain,dc=tld" write
        by dn.children="ou=users,dc=domain,dc=tld" read
        by * none

access to *
        by dn="cn=admin,dc=domain,dc=tld" write
        by * none

En détail : Le premier paragraphe défini les accès pour le ou pfoo, qui lui même se situe dans le ou addressbook, qui lui même se situe à la racine de la base.

• La directive dn.subtree permet de définir l'accès pour le ou pfoo et toute l'arborescence en dessou de ce ou.
• On donne un accès en écriture à l'utilisateur pfoo (défini par la directive cn qui se situe dans le ou>users.

Dans le deuxième paragraphe, on défini les accès au ou users. On ne donne l'accès à personne étant donné qu'on y stocke les utilisateurs et leurs mot-de-passes.

Dans le troisième paragraphe, on défini l'accès au ou addressbook.

• La directive dn.children permet de donner l'accès (en lecture) à tous les utilisateurs de la ou users. On refuse l'accès à tous les autres.

Dans le quatrième paragraphe, on défini les accès à la racine de la base.

• On donne un accès au cn admin ainsi qu'à tous les cn stockés dans le ou users et on refuse l'accès aux autres.

Dans le dernier paragraphe, on précise les permissions pour la totalité de la base :

• On ne donne un accès que au cn admin et on refuse l'accès à tous les autres

Insertion de la structure dans la base

Bien que la base de donnée et ses accès soient configurés, elle reste pour l'instant vide. Nous allons la remplir en utilisant un fichier au format LDIF. Ouvrez votre éditeur de texte, collez les lignes suivantes dedans et enregistrez le nom avec le nom que vous voulez.

#Racine de la base
dn:     dc=domain, dc=tld
objectClass:    top
objectClass:    dcObject
objectClass:    organization
dc:     domain
o:      your domain

# ou des utilisateurs de la base
dn: ou=users,dc=domain,dc=tld
objectClass: top
objectClass: organizationalunit
ou: users

# utilisateur pfoo de la base
dn: cn=pfoo,ou=users,dc=domain,dc=tld
cn: pfoo
objectClass: top
objectClass: person
userPassword: {SSHA}HfdHKgf64gJdNk953FDj6GHsdJhD57I
sn: pfoo

# ou du carnet d'adresse global
dn:     ou=addressbook, dc=domain, dc=tld
objectClass:    top
objectClass:    organizationalUnit
ou:     addressbook

# ou du carnet d'adresse de pfoo
dn:     ou=pfoo, ou=addressbook, dc=domain, dc=tld
objectClass:    top
objectClass:    organizationalUnit
ou:     pfoo

Une fois de plus, le mot-de-passe crypté de la ligne userPassword: de l'utilisateur pfoo peut être trouvé en utilisant la commande suivante :

/usr/sbin/slappasswd -h '{SSHA}' -s password -v

Une fois le fichié créé et enregistré, il ne reste plus qu'à l'ajouter à la base de donnée:

ldapadd -x -W -D "cn=admin,dc=domain,dc=tld" -f votre_fichier

Modification du fichier /etc/default/slapd pour les ports à écouter

Une petite modification est nécessaire pour que slapd écoute bien le port par défaut pour les connexions SSLs. Ouvrez le fichier /etc/default/slapd et ajoutez y les lignes suivantes :

SLAPD_SERVICES="ldap://127.0.0.1:389/ ldap://213.186.47.110:389/ ldaps://213.186.47.110:636/"

Si une autre ligne SLAPD_SERVICES est préexistante, supprimez la.
Le démon slapd écoutera donc en local sur le port 389 (nécessaire pour utiliser une interface de gestion web comme phpldapadmin), ainsi que sur l'ip du serveur sur les ports 389 (connexions normales) et 636 (connexions SSLs)

Lancement

Il ne reste plus qu'à lancer le serveur :

/etc/init.d/slapd start

Vous pouvez tester votre configuration en utilisant un client ldap. Pour ma part, j'ai fait mes tests avec le client ldapbrowser. Pour vous connecter :

• Base DN est la racine de votre base de donnée (dc=domain,dc=tld dans mon cas)
• User DN est le chemin complet de votre utilisateur (cn=pfoo,ou=users,dc=domain,dc=tld dans mon cas)

thunderbird

J'utilise thunderbird en tant que client mail. Pour configurer votre annuaire LDAP, il suffit d'aller dans le carnet d'adresse, de faire fichier > nouveau > annuaire LDAP puis de configurer les différents champs. Utilisez biensur de préférence une connexion chiffrée en SSL.

Le plus gros problème est que thunderbird est à l'heure ou j'écris ces lignes incapable d'écrire dans le carnet d'adresse LDAP. Vous serrez donc obligé de modifier votre carnet d'adresse à la main (ou en utilisant une interface d'administration comme phpldapadmin).