10. Communication TLS avec notre serveur LDAP

10.1. TLS : Pourquoi ?

Vous le savez peut-être, par défaut les communications avec notre serveur LDAP se font en clair. Il suffit de "sniffer" le réseau (non switché) pour s'en rendre compte. Une personne mal intentionnée pourrait donc intercepter toutes les informations qu'elle désire, y compris les mots de passe de nos utilisateurs (même chiffrés, ceux-ci sont précieux... On trouve de nombreux outils pour les "casser"...) ! Une manière simple de sécuriser nos transactions est de passer par TLS (Transport Layer Security, anciennement SSLv3.0, renommé et normalisé par l'IETF, cf. RFC2246), qui assurera le chiffrement des données.

Je ne vais pas rentrer dans les détails d'une communication via TLS, ceci dépasserait le cadre du sujet. Sachez simplement que TLS repose sur la couche 4 (Transport) du modèle OSI, ce qui lui permet de sécuriser les communications réseau de manière transparente pour les applications. Il repose sur l'utilisation de clefs symétriques et asymétriques, et introduit la notion de certificat délivré par un tiers, qui assure alors l'authenticité des clefs.

10.2. Les clefs et les certificats

Une paire de clefs est composée d'une clef privée et d'une clef publique. Elles ont la particularité d'être inséparables, car ce que chiffre l'une, l'autre peut la déchiffrer. Voilà pourquoi on parle de clefs asymétriques. La clef privée est destinée à être gardée précieusement par son propriétaire, alors que la clef publique pourra être diffusée. Le principe général consiste alors à chiffrer les données avec la clef publique du destinataire afin qu'il puisse la déchiffrer avec sa clef privée et être ainsi le seul à pouvoir comprendre le message.

Le certificat vient juste introduire la notion d'authenticité des clefs. Comment être sûr qu'une clef publique est bien celle de la personne à qui l'on veut envoyer des données ? Le certificat nous offre une réponse : une société tierce (de confiance, une autorité de certification : CA) va certifier que la clef publique appartient bien à cette personne. Ainsi, plus de doute, la clef est la bonne... nous évitons ainsi de nous faire piéger par une personne qui voudrait intercepter nos données (le fameux "homme du milieu")...

10.3. La pratique

Nous allons implémenter TLS sur notre serveur LDAP maître pour que les communications Samba-LDAP soient chiffrées (pour être complets nous pourrions aussi mettre en place ce chiffrement pour la réplication LDAP). Cette manoeuvre ajoute juste une commande de type STARTTLS qui permet, si on le désire, de démarrer une transaction sécurisée sur le port standard LDAP. Il restera toujours possible de communiquer "en clair" avec notre serveur. OpenLDAP doit être compilé avec l'option --with-tls et OpenSSL doit être installé.

Dans la pratique, la mise en place de TLS se traduit par trois étapes :

- La génération des clefs/certificats côté serveur
- La mise en place de TLS côté serveur
- La mise en place de TLS côté client

10.3.1. Génération des clefs et du certificat

Nous allons dans cette étape préparer notre serveur à l'utilisation de TLS. Il va falloir générer notre paire de clefs et faire signer notre clef publique par une Autorité de Certification.

Dans le répertoire /etc/ldap, créer un répertoire 'cert' qui contiendra les clefs et le certificat :
- mkdir /etc/ldap/cert

Dans ce répertoire, générez la clef privée du serveur :
- openssl genrsa -out serverkey.pem 1024
Puis la clef publique et la demande de certificat (dans cert.req) :
- openssl req -new -key serverkey.pem -out servercert.req
Complétez correctement les informations qui vous sont demandées. Pensez à bien renseigner le CN (Common Name) par le FQDN (nom dns complet) de votre serveur, celui qui sera utilisé lors de l'interrogation de la base LDAP par les clients.

Pour l'étape suivante, vous avez le choix : soit vous envoyez la demande de certificat à une CA reconnue qui vous enverra le certificat, soit vous certifiez vous-même votre clef en vous faisant passer pour une CA. Nous allons voir comment faire...

Mettons-nous dans à la place d'une CA. Générez la clef privée de la CA :
- openssl genrsa -out cakey.pem 1024
Puis son certificat propre (qui est alors autocertifié : on ne fait pas appel à une autre CA) :
- openssl req -new -x509 -key cakey.pem -out cacert.pem -days 365
La encore, complétez correctement les champs demandés. N'oubliez pas que vous êtes la CA...

Enfin, signature par la CA de la clef publique de notre serveur :
- openssl x509 -req -in servercert.req -out servercert.pem -CA cacert.pem -CAkey cakey.pem -days 365 -CAcreateserial

Suppression des fichiers temporaires :
- rm *.req
- rm *.srl

Suppression de la clef privée de la CA :
- rm cakey.pem

Réglage des droits :
La clef privée ne doit pouvoir être lue que par root :
- chown root:root serverkey.pem ; chmod 400 serverkey.pem

Voilà, vous disposez désormais des fichiers nécessaires pour mettre en place TLS sur le serveur. Nous allons voir les modifications à apporter dans le fichier slapd.conf...

10.3.2. Mise en place côté serveur

- Sur ldap1.martymac.com, modifier /etc/ldap/slapd.conf et ajouter les chemins vers les différentes clefs et le certificat :

# TLS
# Chemin vers le certificat du serveur LDAP
TLSCertificateFile      /etc/ldap/cert/servercert.pem
# Chemin vers la clef privée du serveur LDAP
TLSCertificateKeyFile   /etc/ldap/cert/serverkey.pem
# Chemin vers le certificat de la CA
TLSCACertificateFile    /etc/ldap/cert/cacert.pem

10.3.3. Mise en place côté client

Nous allons mettre en place TLS au niveau de notre PDC. Inspirez-vous de cet exemple pour le BDC, il s'agit de la même démarche...

La configuration des outils LDAP, de libnss-ldap et de libpam-ldap se fait, comme précédemment, via le fichier ldap.conf. N'hésitez pas, pour libnss-ldap et libpam-ldap, à consulter le fichier exemple fourni dans les tarball disponibles sur le site http://www.padl.com.

Pour autoriser les communications TLS, il faut modifier le fichier ldap.conf. Deux types de directives existent : les directives OpenLDAP pures et les directives ajoutées par libpam_ldap et libnss_ldap. Elles sont supplémentaires, l'oubli de l'une ou l'autre fera que l'application qui l'utilise ne fonctionnera pas. Ceci peut conduire à des erreurs difficiles à diagnostiquer ! Ajoutez ceci au fichier ldap.conf du PDC :

#Directive SSL OpenSSL (pour ldapsearch notamment)
TLS_CACERT /etc/ldap/cert/cacert.pem

#Directives SSL libnss et libpam
# Activation SSL brute (port 636)
# ssl yes
# Acivation SSL via commande starttls (port standard 389)
ssl start_tls
#Verifie certificat serveur
tls_checkpeer yes
# Emplacement certificat CA
tls_cacertfile /etc/ldap/cert/cacert.pem

10.3.4. Testons notre connexion sécurisée

Testons d'abord, depuis notre PDC, si les outils clients OpenLDAP fonctionnent :
- ldapsearch -b 'dc=martymac,dc=com' -ZZ -xh ldap1.martymac.com

L'ajout de -ZZ force la communication en TLS. Vous devriez voir apparaître l'arborescence que nous avions déjà auparavant. Si vous avez une erreur, vérifiez bien que le nom du serveur utilisé pour la requête est bien le nom passé dans le CN lors de la demande de certificat du serveur !

Testons ensuite la bonne configuration de libnss-ldap : exécutons 'getent passwd' et voir si nos utilisateurs LDAP sont bien listés...

Si tout cela fonctionne, c'est déjà un bon point, cependant, est-ce bien chiffré ? Pour s'en assurer, nous allons sniffer (écouter) le réseau avec tcpdump :

Sur le serveur LDAP, on écoute les connexions provenant de notre PDC :
- tcpdump -s0 -xX ip host pdc.martymac.com and host ldap1.martymac.com
Sur le PDC, on rapatrie les entrées utilisateurs avec :
- getent passwd ou ldapsearch -b 'dc=martymac,dc=com' -ZZ -xh ldap1.martymac.com

Le PDC va contacter le serveur LDAP pour y lire les informations nécessaires. On voit alors plusieurs segments TCP affichés avec tcpdump, mais rien n'est compréhensible... Si l'on réitère l'opération en commentant les lignes concernant la configurationn SSL, on pourra distinguer les informations rapatriées par notre PDC, la preuve que le flux de données est bien chiffré !

10.3.5. Mise en place pour Samba

Le but de tout ceci étant de pouvoir intégrer TLS aux communications entre Samba et notre serveur LDAP, terminons ce chapitre en voyant comment modifier le fichier smb.conf du PDC :

; SAMBA-LDAP declarations
ldap suffix = dc=martymac,dc=com
ldap admin dn = cn=Manager,dc=martymac,dc=com
; Attention ! Comme d'habitude, il faut utiliser
; le nom de serveur donné en tant que CN pour le certificat
ldap server = ldap1.martymac.com
; ldap ssl = No
ldap ssl = start_tls
ldap port = 389