« Installation et configuration de OpenLDAP » : différence entre les versions

De Linux Server Wiki
Aller à la navigation Aller à la recherche
(Page créée avec « =1. Installation= Pour installer OpenLDAP :</p> <pre># aptitude install ldap-server ldap-client</pre> La configuration de openldap se fait dans <code>/etc/ldap/</code>. Le da... »)
 
Aucun résumé des modifications
Ligne 1 : Ligne 1 :
=1. Installation=
=Installation=
Pour installer OpenLDAP :</p>
Pour installer OpenLDAP :
<pre># aptitude install ldap-server ldap-client</pre>
<pre># aptitude install ldap-server ldap-client</pre>
La configuration de openldap se fait dans <code>/etc/ldap/</code>. Le daemon OpenLDAP s'appèle slapd. Voici un exemple de fichier <a href="slapd.conf">slapd.conf</a></p>
La configuration de openldap se fait dans <code>/etc/ldap/</code>. Le daemon OpenLDAP s'appèle slapd. Voici un exemple de fichier <code>slapd.conf</code> :
<pre><nowiki>
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.


=2. Configuration globale=
#######################################################################
# Global Directives:


==2.1. Les schémas==
# Features to permit
C'est la première chose à définir, a savoir, quels schémas le serveur doit supporter. Les schémas sont placés dans <code>/etc/ldap/schema</code>. Voici ceux que j'utilise :</p>
 
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=csnu,dc=org"
rootdn          "cn=admin,dc=csnu,dc=org"
rootpw {SSHA}HJsgK682kFZk
directory      "/srv/ldap/csnu/"
#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=csnu,dc=org" 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=csnu,dc=org"
        by dn="cn=pfoo,ou=users,dc=csnu,dc=org" write
        by * none
 
access to dn="ou=users,dc=csnu,dc=org"
        by * none
 
access to dn="ou=addressbook,dc=csnu,dc=org"
        by dn.children="ou=users,dc=csnu,dc=org" read
        by * none
 
access to dn="dc=csnu,dc=org"
        by dn="cn=admin,dc=csnu,dc=org" write
by dn.children="ou=users,dc=csnu,dc=org" read
        by * none
 
access to *
        by dn="cn=admin,dc=csnu,dc=org" 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"
</nowiki></pre>
 
=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 <code>/etc/ldap/schema</code>. Voici ceux que j'utilise :
<pre>
<pre>
include        /etc/ldap/schema/core.schema
include        /etc/ldap/schema/core.schema
Ligne 15 : Ligne 125 :
</pre>
</pre>


==2.2. Log et exécution==
==Log et exécution==
Pour que slapd log les actions effectués, il faut définir le niveau de log avec la directive <code>loglevel</code>. Voici un petit tableau récapitulant les différents loglevels :</p>
Pour que slapd log les actions effectués, il faut définir le niveau de log avec la directive <code>loglevel</code>. Voici un petit tableau récapitulant les différents loglevels :
<pre>
<pre>
Niveau Description
Niveau Description
-1 enable all debugging
-1 enable all debugging
Ligne 35 : Ligne 144 :
2048 print entry parsing debugging
2048 print entry parsing debugging
</pre>
</pre>
Vous pouvez additionner les différents niveaux de log pour bénéficier de plusieurs options de log.<br></br>
 
Pour que les logs fonctionnent, ajoutez la ligne suivante dans <code>/etc/syslog.conf</code> puis redémarrez syslog (<code>/etc/init.d/sysklogd restart</code>) :</p>
Vous pouvez additionner les différents niveaux de log pour bénéficier de plusieurs options de log.<br />
Pour que les logs fonctionnent, ajoutez la ligne suivante dans <code>/etc/syslog.conf</code> puis redémarrez syslog (<code>/etc/init.d/sysklogd restart</code>) :
<pre>local4.*        /var/log/ldap.log</pre>
<pre>local4.*        /var/log/ldap.log</pre>
D'autres directives doivent être définies :</p>
D'autres directives doivent être définies :
<ul><li>pidfile filename : spécifie le fichier dans lequel le pid de slapd sera stocké.</li>
* <code>pidfile filename</code> : spécifie le fichier dans lequel le pid de slapd sera stocké.
* <code>argsfile filename</code> : spécifie le fichier où les arguments qu'il faut passer à slapd lors de son lancement sont stockés.
* <code>schemacheck on|off</code> : spécifie s'il faut vérifier la conformité de toutes les entrées aux schémas configurés


<li>argsfile filename : spécifie le fichier où les arguments qu'il faut passer à slapd lors de son lancement sont stockés.</li>
Dans mon cas :
<li>schemacheck on|off : spécifie s'il faut vérifier la conformité de toutes les entrées aux schémas configurés</li></ul>
Dans mon cas :</p>
<pre>
<pre>
pidfile        /var/run/slapd/slapd.pid
pidfile        /var/run/slapd/slapd.pid
Ligne 52 : Ligne 162 :


==2.3. Autres options==
==2.3. Autres options==
<ul><li>modulepath : spécifie où sont stockés les modules.</li>
* <code>modulepath</code> : spécifie où sont stockés les modules.
<li>moduleload : spécifie les modules à loader.</li>
* <code>moduleload</code> : spécifie les modules à loader.
<li>sizelimit : spécifie le nombre maximum d'entrée retourné lors d'une recherche</li></ul>
* <code>sizelimit</code> : spécifie le nombre maximum d'entrée retourné lors d'une recherche


Ma configuration :</p>
Ma configuration :
<pre>
<pre>
modulepath      /usr/lib/ldap
modulepath      /usr/lib/ldap
Ligne 62 : Ligne 172 :
sizelimit 500
sizelimit 500
</pre>
</pre>


==2.4. SSL==
==2.4. SSL==
slapd permet de sécuriser les transactions en SSL. Voici la configuration que j'utilise:</p>
slapd permet de sécuriser les transactions en SSL. Voici la configuration que j'utilise :
<pre>
<pre>
TLSCertificateFile      /etc/ldap/ssl/ldap.pem
TLSCertificateFile      /etc/ldap/ssl/ldap.pem
Ligne 73 : Ligne 182 :
</pre>
</pre>


Définition des directives :</p>
Définition des directives :
* <code>TLSCertificateFile</code>: spécifie l'emplacement du certificat du serveur.
* <code>TLSCertificateKeyFile</code>: spécifie l'emplacement de la clé privée du certificat.
* <code>TLSCACertificateFile</code>: spécifie l'emplacement du certificat de la CA qui a permit de signer le certificat de slapd.
* <code>TLSCipherSuite</code>: spécifie les spécifications de chiffrement


<ul><li>TLSCertificateFile: spécifie l'emplacement du certificat du serveur.</li>
La section du fichier de configuration de openssl correspondante :
<li>TLSCertificateKeyFile: spécifie l'emplacement de la clé privée du certificat.</li>
<li>TLSCACertificateFile: spécifie l'emplacement du certificat de la CA qui a permi de signer le certificat de slapd.</li>
<li>TLSCipherSuite: spécifie les specifications de chiffrement</li>
</ul>
 
La section du fichier de configuration de openssl correspondante :</p>
<pre>
<pre>
[LDAP]
[OPENLDAP]
basicConstraints = critical, CA:FALSE
nsComment                      = "OpenLDAP Certificate"
subjectKeyIdentifier = hash
subjectKeyIdentifier            = hash
keyUsage = digitalSignature, keyEncipherment
authorityKeyIdentifier          = keyid,issuer:always
extendedKeyUsage = serverAuth, clientAuth
issuerAltName                  = issuer:copy
nsCertType = server
basicConstraints               = critical,CA:FALSE
nsComment = "OpenLDAP certificat"
keyUsage                       = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                     = server
extendedKeyUsage                = serverAuth
</pre>
</pre>


Ligne 95 : Ligne 204 :


==2.6. Autres options de sécurité==
==2.6. 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 :<br></br>
*<code>password-hash</code> : 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<br></br>
** <code>{CRYPT}</code> : utilise la fonction crypt() de unix
- {MD5} : hachage par MD5<br></br>
** <code>{MD5}</code> : hachage par MD5
- {SHA} : hachage en SHA-1<br></br>
** <code>{SHA}</code> : 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.</p>
** <code>{SSHA}</code> : (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 :<br></br>
*<code>require</code> : spécifie les conditions d'accès au serveur. Les options possibles sont :
- none<br></br>
** <code>none</code>
- authc : tout client doit s'authentifier</p>
** <code>authc</code> : tout client doit s'authentifier
* <code>allow</code> et <code>disallow</code> : permet d'autoriser ou de ne pas autoriser certaines fonctions.


allow et disallow : permet d'authoriser ou de ne pas authoriser certaines fonctions.</p>
Ma configuration :
Ma configuration :</p>
<pre>
<pre>
require authc
require authc
Ligne 113 : Ligne 222 :
=3. Configuration de la base de donnée=
=3. Configuration de la base de donnée=
==3.1. Ajout d'une base==
==3.1. Ajout d'une base==
Dans mon exemple, j'ajoute les lignes suivantes au fichier <code>/etc/ldap/slapd.conf</code> :</p>
Dans mon exemple, j'ajoute les lignes suivantes au fichier <code>/etc/ldap/slapd.conf</code> :


<pre>
<pre>
Ligne 129 : Ligne 238 :
# replogfile    /var/lib/ldap/replog
# replogfile    /var/lib/ldap/replog
</pre>
</pre>
Une petite explication :</p>
<ul><li>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.</li>
<li>suffix : spécifie la racine de la base</li>
<li>rootdn : défini le super-utilisateur de la base de donnée. C'est lui qui aura tous les pouvrois.</li>
<li>rootpw : défini le mot-de-passe du super-utilisateur. Pour générer le mot-de-passe, utilisez la commande <code>/usr/sbin/slappasswd -h '{SSHA}' -s password -v</code> où password est le mot-de-passe souhaité.</li>
<li>directory : spécifie le dossier dans lequel la base de donnée sera créée.</li>


<li>dbconfig set_cachesize : spécifie la taille du cache</li>
Une petite explication :
<li>index : spécifie les options d'indexation pour accélérer les recherches. Les types d'index supportés sont :
* <code>database bdb</code> : 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.
<ul><li> approx (approximate)</li>
* <code>suffix</code> : spécifie la racine de la base
    <li> eq (equality)</li>
* <code>rootdn</code> : défini le super-utilisateur de la base de donnée. C'est lui qui aura tous les pouvrois.
    <li> pres (presence)</li>
* <code>rootpw</code> : défini le mot-de-passe du super-utilisateur. Pour générer le mot-de-passe, utilisez la commande <code>/usr/sbin/slappasswd -h '{SSHA}' -s password -v</code> où password est le mot-de-passe souhaité.
    <li>sub (substring)</li>
* <code>directory</code> : spécifie le dossier dans lequel la base de donnée sera créée.
 
* <code>dbconfig set_cachesize</code> : spécifie la taille du cache
</ul></li>
* <code>index</code> : spécifie les options d'indexation pour accélérer les recherches. Les types d'index supportés sont :
<li>lastmod : spécifie s'il faut garder en mémoire la dernière modification des entrées</li>
**approx (approximate)
<li>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</li></ul>
**eq (equality)
**pres (presence)
**sub (substring)
* <code>lastmod</code> : spécifie s'il faut garder en mémoire la dernière modification des entrées
* <code>replogfile</code> : 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


==3.2. Configuration des ACLs de la base==
==3.2. Configuration des ACLs de la base==
Les ACLs définissent qui a accès à quoi dans la base de donnée.</p>
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.</p>
Tout d'abord, on va définir les accès aux mots-de-passes.
<pre>
<pre>
# The userPassword by default can be changed
# The userPassword by default can be changed
Ligne 162 : Ligne 269 :
         by * none
         by * none
</pre>
</pre>
Petite explication :</p>
Petite explication :
* <code>access to</code> : spécifie pour quoi on défini des accès. Dans le cas présent, c'est l'accès aux mots-de-passes
* <code>by dn="cn=admin,dc=csnu,dc=org" write</code> : autorise l'accès en écriture par le super-utilisateur admin. L'accès en écriture signifie un accès complet.
* <code>by anonymous auth</code> : autorise aux utilisateurs anonymes de se loguer
* <code>by self write</code> : autorise l'utilisateur à changer son propre mot-de-passe
* <code>by * none</code> : restreint l'accès à tous les autres utilisateurs.


<ul><li>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</li>
<li>by dn="cn=admin,dc=csnu,dc=org" write : authorise l'accès en écriture par le super-utilisateur admin. L'accès en écriture signifie un accès complet.</li>
<li>by anonymous auth : authorise aux utilisateurs anonymes de se loguer</li>
<li>by self write : authorise l'utilisateur à changer son propre mot-de-passe</li>
<li>by * none : restreint l'accès à tous les autres utilisateurs.</li></ul>
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
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 <code>by * none</code> à la première ligne, les lignes suivantes n'auraient
à tous le monde en dernier, mais les permissions précédentes restent valides. Si on avait interdit l'accès en ajoutant une ligne <code>by * none</code> à la première ligne, les lignes suivantes n'auraient
pas été appliqué.</p>
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 :</p>
Maintenant, on va définir les accès à la structure de la base. Voici la structure qu'on va mettre en place :


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


<li>A la racine, nous allons aussi créer un <code>ou</code> users qui contiendra les utilisateurs de la base de donnée</li>
A la racine, nous allons aussi créer un <code>ou</code> users qui contiendra les utilisateurs de la base de donnée
</ul>
 
Voici les permissions correspondantes pour cette structure :</p>
Voici les permissions correspondantes pour cette structure :
<pre>
<pre>
access to dn.subtree="ou=pfoo,ou=addressbook,dc=csnu,dc=org"
access to dn.subtree="ou=pfoo,ou=addressbook,dc=csnu,dc=org"
Ligne 202 : Ligne 309 :
         by * none
         by * none
</pre>
</pre>
En détail :</p>
<ul><li>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.<br></br>
La directive <code>dn.subtree</code> permet de définir l'accès pour le <code>ou</code> pfoo et toute l'arborescence en dessou de ce <code>ou</code><br></br>


On donne un accès en écriture à l'utilisateur pfoo (défini par la directive <code>cn</code> qui se situe dans le <code>ou>users</code></li>
En détail :
<li>Dans le deuxième paragraphe, on défini les accès au <code>ou</code> users. On ne donne l'accès à personne étant donné qu'on y stocke les utilisateurs et leurs mot-de-passes.</li>
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.<br />
<li>Dans le troisième paragraphe, on défini l'accès au <code>ou</code> addressbook.<br></br>
* La directive <code>dn.subtree</code> permet de définir l'accès pour le <code>ou</code> pfoo et toute l'arborescence en dessou de ce <code>ou</code>.
La directive <code>dn.children</code> permet de donner l'accès (en lecture) à tous les utilisateurs de la <code>ou</code> users. On refuse l'accès à tous les autres.</li>
* On donne un accès en écriture à l'utilisateur pfoo (défini par la directive <code>cn</code> qui se situe dans le <code>ou>users</code>.


<li>Dans le quatrième paragraphe, on défini les accès à la racine de la base<br></br>
Dans le deuxième paragraphe, on défini les accès au <code>ou</code> users. On ne donne l'accès à personne étant donné qu'on y stocke les utilisateurs et leurs mot-de-passes.
On donne un accès au <code>cn</code> admin ainsi qu'à tous les <code>cn</code> stockés dans le <code>ou</code> users et on refuse l'accès aux autres.</li>
 
<li>Dans le dernier paragraphe, on précise les permissions pour la totalité de la base<br></br>
Dans le troisième paragraphe, on défini l'accès au <code>ou</code> addressbook.
On ne donne un accès que au <code>cn</code> admin et on refuse l'accès à tous les autres</li></ul>
* La directive <code>dn.children</code> permet de donner l'accès (en lecture) à tous les utilisateurs de la <code>ou</code> 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 <code>cn</code> admin ainsi qu'à tous les <code>cn</code> stockés dans le <code>ou</code> 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 <code>cn</code> admin et on refuse l'accès à tous les autres


=4. Insertion de la structure dans la base=
=4. 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.<br></br>
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.</p>
Ouvrez votre éditeur de texte, collez les lignes suivantes dedans et enregistrez le nom avec le nom que vous voulez.
<pre>
<pre>
#Racine de la base
#Racine de la base
Ligne 254 : Ligne 364 :
ou:    pfoo
ou:    pfoo
</pre>
</pre>
Une fois de plus, le mot-de-passe crypté de la ligne <code>userPassword:</code> de l'utilisateur pfoo peut être trouvé en utilisant la commande suivante :</p>
Une fois de plus, le mot-de-passe crypté de la ligne <code>userPassword:</code> de l'utilisateur pfoo peut être trouvé en utilisant la commande suivante :
<pre># /usr/sbin/slappasswd -h '{SSHA}' -s password -v</pre>
<pre>/usr/sbin/slappasswd -h '{SSHA}' -s password -v</pre>


Une fois le fichié créé et enregistré, il ne reste plus qu'à l'ajouter à la base de donnée:</p>
Une fois le fichié créé et enregistré, il ne reste plus qu'à l'ajouter à la base de donnée:
<pre># ldapadd -x -W -D "cn=admin,dc=csnu,dc=org" -f votre_fichier</pre>
<pre>ldapadd -x -W -D "cn=admin,dc=csnu,dc=org" -f votre_fichier</pre>


=5. Modification du fichier /etc/default/slapd pour les ports à écouter=
=5. 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.<br></br>
Une petite modification est nécessaire pour que slapd écoute bien le port par défaut pour les connexions SSLs.
Ouvrez le fichier <code>/etc/default/slapd</code> et ajoutez y les lignes suivantes :</p>
Ouvrez le fichier <code>/etc/default/slapd</code> et ajoutez y les lignes suivantes :
<pre>
<pre>
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldap://213.186.47.110:389/ ldaps://213.186.47.110:636/"
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldap://213.186.47.110:389/ ldaps://213.186.47.110:636/"
</pre>
</pre>
Si une autre ligne <code>SLAPD_SERVICES</code> est préexistante, supprimez la.<br></br>
Si une autre ligne <code>SLAPD_SERVICES</code> est préexistante, supprimez la.<br></br>
Le démon slapd écoutera donc en local sur le port 389 (nécessaire pour utiliser une interface de gestion web comme <code>phpldapadmin</code>), ainsi que sur l'ip du serveur sur les ports
Le démon slapd écoutera donc en local sur le port 389 (nécessaire pour utiliser une interface de gestion web comme <code>phpldapadmin</code>), ainsi que sur l'ip du serveur sur les ports 389 (connexions normales) et 636 (connexions SSLs)
389 (connexions normales) et 636 (connexions SSLs)</p>


=6. Lancement=
=6. Lancement=
Il ne reste plus qu'à lancer le serveur :</p>
Il ne reste plus qu'à lancer le serveur :
 
<pre>/etc/init.d/slapd start</pre>


<pre># /etc/init.d/slapd start</pre>
Vous pouvez tester votre configuration en utilisant un client ldap. Pour ma part, j'ai fait mes tests avec le client <code>ldapbrowser</code>.
Vous pouvez tester votre configuration en utilisant un client ldap. Pour ma part, j'ai fait mes tests avec le client <a href="ldapbrowser.7z">ldapbrowser</a> (java)<br></br>
Pour vous connecter :
Pour vous connecter : </p>
* <code>Base DN</code> est la racine de votre base de donnée (dc=csnu,dc=org dans mon cas)
<ul><li>Base DN est la racine de votre base de donnée (dc=csnu,dc=org dans mon cas)</li>
* <code>User DN</code> est le chemin complet de votre utilisateur (cn=pfoo,ou=users,dc=csnu,dc=org dans mon cas)
<li>User DN est le chemin complet de votre utilisateur (cn=pfoo,ou=users,dc=csnu,dc=org dans mon cas)</li></ul>


=7. thunderbird=
=7. thunderbird=


J'utilise thunderbird en tant que client mail.<br></br>
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
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.
connexion chiffrée en SSL.<br></br>
 
Personnellement, je n'ai jamais réussi à faire marcher la réplication du carnet d'adresse. Peut-être faut-il passer par le démon slurpd, mais vu qu'aucune configuration n'est possible au niveau de
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 <code>phpldapadmin</code>).
thunderbird, je me dis que non.<br></br>
Le plus gros problème est que thunderbird est 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 <code>phpldapadmin</code>).<br></br>
S'il vous est nécessaire de pouvoir modifier votre carnet d'adresse facilement, je vous conseil le plugin <a href="http://extensions.geckozone.org/AddressbooksSynchronizer"> AddressbooksSync</a>
pour thunderbird qui permet la synchronisation en IMAP, et même en ftp ou en webdav (support du https) si vous devez partager votre carnet avec d'autres personnes.</p>

Version du 5 février 2011 à 23:01

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=csnu,dc=org"
rootdn          "cn=admin,dc=csnu,dc=org"
rootpw		{SSHA}HJsgK682kFZk
directory       "/srv/ldap/csnu/"
#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=csnu,dc=org" 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=csnu,dc=org"
        by dn="cn=pfoo,ou=users,dc=csnu,dc=org" write
        by * none

access to dn="ou=users,dc=csnu,dc=org"
        by * none

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

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

access to *
        by dn="cn=admin,dc=csnu,dc=org" 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

2.3. 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

2.4. 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

2.5. SASL

2.6. 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}

3. Configuration de la base de donnée

3.1. Ajout d'une base

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

database        bdb
suffix          "dc=csnu,dc=org"
rootdn          "cn=admin,dc=csnu,dc=org"
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

3.2. 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=csnu,dc=org" 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=csnu,dc=org" 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=csnu,dc=org"
        by dn="cn=pfoo,ou=users,dc=csnu,dc=org" write
        by * none

access to dn="ou=users,dc=csnu,dc=org"
        by * none

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

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

access to *
        by dn="cn=admin,dc=csnu,dc=org" 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

4. 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=csnu, dc=org
objectClass:    top
objectClass:    dcObject
objectClass:    organization
dc:     csnu
o:      Commandement Spatial des Nations Unies

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

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

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

# ou du carnet d'adresse de pfoo
dn:     ou=pfoo, ou=addressbook, dc=csnu, dc=org
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=csnu,dc=org" -f votre_fichier

5. 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)

6. 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=csnu,dc=org dans mon cas)
  • User DN est le chemin complet de votre utilisateur (cn=pfoo,ou=users,dc=csnu,dc=org dans mon cas)

7. 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).

Récupérée de « https://wiki.unscdf.org/index.php?title=Installation_et_configuration_de_OpenLDAP&oldid=124 »