Installation de OpenLDAP

Une fois tous ces composants installés, nous pouvons passer à l’installation du serveur OpenLDAP.

La dernière version de OpenLDAP peut être téléchargée à partir de l’adresse : http://www.openldap.org/

Après avoir décompressé le fichier, l’installation s’effectue avec les commandes :

# ./configure [options]

Dans notre cas, nous avons utilisé les options :

./configure –-prefix=/usr tls –-enable-slapd –-with-cyrus-sasl –-enable-crypt –-enable-ldbm –-enable-bdb=no

On procède ensuite à l’installation :

# make

# make depend

# make install

Une fois l’installation effectuée, il faut éditer les fichiers /etc/openldap/slpad.conf et /etc/openldap/ldap.conf pour paramétrer l’annuaire.

3.2.4.1 Configuration du fichier ldap.conf :

Certaines modifications doivent être apportées au fichier ldap.conf :

¾ Configuration du nom d’hôte du serveur hébergeant l’annuaire :

# Your LDAP server. Must be resolvable without using LDAP.

HOST mci-0475e2d1ae.int-evry.fr

¾ Configuration de la base LDAP

# The distinguished name of the search base.

base dc=int-evry,dc=fr

¾ Ports pour accéder à l’annuaire (en mode normal, SSL ou TLS)

# The port.

# Optional: default is 389.

port 389 # normal et TLS

port 636 # SSL

¾ Activer cryptage TLS/SSL (pointer vers les certificats créés pour notre CA)

# OpenLDAP SSL mechanism

# start_tls mechanism uses the normal LDAP port, LDAPS typically 636 ssl start_tls

# OpenLDAP SSL options

# Require and verify server certificate (yes/no)

# Default is "no"

tls_checkpeer yes

# CA certificates for server certificate verification

# At least one of these are required if tls_checkpeer is "yes"

tls_cacertfile /etc/openldap/certs/cacert.pem

#tls_cacertdir /etc/ssl/certs

¾ Désactiver l’authentification du client par TLS/SSL

# Client certificate and key

# Use these, if your server requires client authentication.

#tls_cert

#tls_key ssl no

(Le fichier ldap.conf que nous avons utilisé est donné en annexe C)

3.2.4.2 Configuration du fichier slapd.conf :

Certaines modifications doivent être apportées au fichier sladp.conf :

¾ Ajouter le schéma Kerberos V pour l’authentification

include /etc/openldap/schema/krb5-kdc.schema

¾ Configurer la référence vers l’annuaire LDAP

# Do not enable referrals until AFTER you have a working

# directory service AND an understanding of referrals.

referral ldap://mci-0475e2d1ae.int-evry.fr

¾ Ajouter les chemins d’accès aux certificats OpenSSL pour l’utilisation du cryptage SSL/TLS :

#

# The next three lines allow use of TLS for connections using a

# dummy test certificate, but you should generate a proper

# certificate by changing to /usr/share/ssl/certs, running

# "make slapd.pem", and fixing permissions on TLSCipherSuite HIGH:MEDIUM:+SSLv2

TLSCertificateFile /etc/openldap/certs/server.crt.pem TLSCertificateKeyFile /etc/openldap/certs/server.key.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSVerifyClient never

¾ Activation de la méthode d’authentification SASL, avec déclaration du

« royaume » (reaml) Kerberos et l’adresse du serveur LDAP :

sasl-realm INT-EVRY.FR

sasl-host mci-0475e2d1ae.int-evry.fr

¾ Définitions des listes d’accès et des droits utilisateur :

# Write access to principals Manager and */admin , default read

# access for everything else access to *

by dn="uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" write by dn="uid=Manager\+(realm=INT-EVRY\.FR)?" write

by * read

¾ Paramétrage de l’annuaire et de l’administrateur :

database ldbm

suffix "dc=int-evry,dc=fr"

#suffix "o=My Organization Name,c=US"

rootdn "cn=Manager,dc=int-evry,dc=fr"

#rootdn "cn=Manager,o=My Organization Name,c=US"

# Cleartext passwords, especially for the rootdn, should

# be avoided. See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

# rootpw manager

# rootpw {crypt}ijFYNcSNctBYg

3.2.4.3 Lancement du serveur LDAP :

LDAP est un service tournant sur le poste, par conséquent il peut être démarré à l’aide de la commande :

[root@mci-0475e2d1ae root]# /sbin/service ldap start

Mais il peut également être lancé avec la commande :

[root@mci-0475e2d1ae root]# slapd start

On peut également spécifier le port d’écoute (389 en normal ou avec TLS, 636 avec SSL) à l’aide de l’option « -h » :

Normal/TLS: [root@mci-0475e2d1ae root]# slapd –h ldap:///

SSL: [root@mci-0475e2d1ae root]# slapd –h ldaps:///

Une méthode efficace pour vérifier si le service est bien en écoute sur le port souhaité est d’utiliser la commande nmap :

[root@mci-0475e2d1ae root]# nmap localhost

3.2.4.4 Création d’un principal LDAP dans la base Kerberos

De façon à permettre l’authentification des utilisateurs de l’annuaire LDAP à travers Kerberos, il faut créer un principal correspond au service LDAP dans la base Kerberos avec l’utilitaire kadmin :

kadmin : addprinc -randkey ldap/mci-0475e2d1ae.int-evry.fr

La clé privée du service est générée de façon aléatoire et stockée dans le fichier cache krb5.keytab sur le serveur LDAP ainsi que sur le serveur Kerberos :

kadmin : ktadd –k /etc/krb5.keytab ldap/mci-0475e2d1ae.int-evry.fr

De plus sur on doit ajouter dans le fichier krb5.keytab du serveur LDAP les

« principals » des hôtes autorisés à se connecter à l’annuaire :

kadmin : ktadd –k /etc/krb5.keytab host/ mci-0475e84aa8.int-evry.fr

3.2.4.5 Initialisation de la base LDAP :

On initialise la base LDAP à l’aide d’un fichier init.ldif :

# Racine de la base

# Définition de l’administrateur dn: cn=Manager,dc=int-evry,dc=fr objectclass: organizationalRole cn: Manager

# Ajout d’un utilisateur

dn: uid=jdupond,ou=people,dc=int-evry,dc=fr

telephoneNumber: +33 6 01 01 98 title: DSI

uid: jdupond

userPassword: 1r2ewu65ZEm9ePs56

Le fichier init.ldif est importé dans la base à l’aide de la commande :

ldapadd -H ldap://mci-0475e2d1ae.int-evry.fr/ -I -f init.ldif

Cette commande d’ajout ne fonctionnera que si l’utilisateur s’est authentifié auprès de Kerberos (et dispose donc d’un ticket TGT valide).

De plus, l’utilisateur doit disposer de droits suffisants au niveau des listes d’accès (voir partie suivante sur les listes d’accès LDAP). D’après notre fichier slpad.conf nous autorisons l’accès en écriture à la base pour les « principals » : Manager@INT-EVRY.FR et < * >/admin@INT-Manager@INT-EVRY.FR.

Explicitons les arguments de cette commande ldapadd :

o -H ldap://mci-0475e2d1ae.int-evry.fr/ : spécifie l’annuaire LDAP vers lequel la requête doit être envoyée. L’option –ZZ pourrait être ajoutée afin de crypter la requête avec TLS. De même, si l’on avait spécifié l’adresse ldaps://mci-0475e2d1ae.int-evry.fr/ nous aurions

utilisé le cryptage SSL (à noter qu’il ne faut pas spécifier l’option –ZZ dans ce cas).

o –I : Active l’authentification par SASL

o -f init.ldif : spécifie que c’est le contenu du fichier init.ldif qui doit être ajouté la base LDAP.

3.2.4.6 A propos des listes d’accès de la base LDAP :

Les listes d’accès à la base LDAP sont définies dans le fichier slapd.conf. Nous aurions également pu définir ces règles dans un fichier myldap.access et ajouter un lien vers ce fichier dans splad.conf avec la commande : include /../…/myldap.access Par défaut (c'est-à-dire s’il l’on modifie par les listes d’accès) tous les utilisateurs, authentifiés ou non, ont accès en lecture sur la base et seul l’administrateur a un accès en écriture.

Les listes d’accès sont définies selon le modèle : Quoi ?

Qui ? Quel accès ? Qui ? Quel accès ?

…

Selon la syntaxe :

Access to <partie de l’annuaire>

by <utilisateur> <read/write/auth/none/…>

by <utilisateur> <read/write/auth/none/…>

…

L’utilisateur correspond à la personne qui se connecte à la base, si aucune authentification n’est demandée à l’utilisateur ce dernier est considéré comme anonymous.

Lorsque nous utilisons Kerberos/SASL pour l’authentification, les utilisateurs disposant de tickets TGT valides sont authentifiés et autorisés à accéder à la base.

Mais ces derniers n’étant pas connus par l’annuaire (sous le format : principal@REAML.KRB), ils sont considérés comme anonymes au niveau de LDAP et ne disposent que de droits en lecture.

Il faut donc, au niveau des listes d’accès effectuer un mappage entre le principal Kerberos et les utilisateurs LDAP :

access to *

by dn="uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" write by dn="uid=Manager\+(realm=INT-EVRY\.FR)?" write

by *

Dans la commande précédente « uid=Manager\+(realm=INT-EVRY\.FR)? » réalise ce mappage entre le « principal » Kerberos : Manager, et un utilisateur authentifié dans LDAP.

De même, "uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" représente tous les

« principals » définis comme <nom>/admin@INT-EVRY.FR.