OpenLDAP : configurer le LDAPS pour sécuriser les connexions (Red Hat 9 / Debian 13)
Ce tutoriel vous montre comment configurer LDAPS, la version sécurisée du protocole LDAP sur votre serveur OpenLDAP. Grâce au certificat TLS généré, les requêtes entre le client et le serveur OpenLDAP seront chiffrées.
Il est nécessaire d’avoir un serveur OpenLDAP d’installé et configuré. Si ce n’est pas le cas, je vous redirige vers mon tutoriel pour l’installation d'OpenLDAP et sa configuration.
- Installer votre annuaire OpenLDAP sur Linux (Red Hat 9 / Debian 13)
- Configurer OpenLDAP sur Linux (Red Hat 9 / Debian 13) : préparer l’annuaire LDAP
Pour rappel, le protocole LDAP ne bénéficie pas du chiffrement des communications, ce qui signifie que les flux transitent en clair sur le réseau. Un pirate, capturant le trafic avec un sniffer réseau, aura la capacité de lire le contenu des communications.
Afin de sécuriser LDAP, il est nécessaire d’activer LDAPS à l’aide d’un certificat TLS :
- soit émis par une autorité de certification (CA) reconnue (une CA d'entreprise, par exemple) ;
- soit auto-signé, mais dans ce cas il devra être distribué manuellement sur les clients et installé parmi les certificats racine de confiance.
Pour ce tutoriel, nous utiliserons un certificat auto-signé. Notez toutefois que la configuration reste identique avec un certificat émis par une autorité de certification à quelques adaptations près.
Les commandes peuvent changer entre les distributions Debian et Red Hat, vous serez notifié lorsque les commandes diffèrent.
Attention : durant ce tutoriel, je vous invite à faire attention à la syntaxe des fichiers créés. Le système Linux est assez capricieux en général avec ce sujet et le moindre espace en trop pourrait provoquer une erreur. Soyez vigilant !
Sommaire
Génération de la clé privée et du certificat avec OpenSSL
OpenSSL est un outil très répandu qui permet de gérer tout ce qui touche au chiffrement et à la sécurité du réseau, notamment :
- Génération des clés privées et paires de clés.
- Création des certificats numériques (auto-signés ou demandes de certificat).
- Activation et test du chiffrement TLS/SSL (HTTPS, LDAPS, etc.).
- Chiffrement et déchiffrement des fichiers…
Nous allons procéder à son installation afin de créer une paire de clés et générer le certificat auto-signé. Les commandes diffèrent selon votre famille de distribution, choisissez la partie correspondant à votre système.
Nous allons commencer par mettre à jour les paquets, puis installer le paquet OpenSSL.
Sous Debian:
sudo apt-get update
sudo apt-get install openssl -ySous Red Hat :
sudo dnf update -y
sudo dnf install openssl -yNous allons ensuite créer un répertoire temporaire qui nous servira pour générer nos différents fichiers :
mkdir ssl-ldap
cd ssl-ldapPuis, nous allons générer la clé privée dans le répertoire. Cette clé aura les propriétés suivantes :
- Type : l’algorithme de chiffrement de la clé est RSA, qui est réputé pour sa robustesse grâce aux formules mathématiques utilisées.
- Taille : la clé aura une longueur de 4096 bits pour une meilleure sécurité.
- Nom de la clé : vous pouvez la nommer comme vous le souhaitez mais je vous recommande FQDN.key pour une meilleure lisibilité.
sudo openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ldap.it-connect.local.keyUne fois la commande terminée, tapez la commande ls pour voir votre répertoire. La clé devrait être présente.
Il faut générer un deuxième composant nécessaire pour le certificat : le CSR.
Un CSR (Certificate Signing Request) est un fichier de demande de certificat. Il contient :
- La clé publique du serveur.
- Les informations d’identification (nom de domaine, organisation, pays…).
- Il est signé avec la clé privée pour prouver que le serveur en est bien le propriétaire.
On va générer ce fichier grâce à OpenSSL en lui indiquant la durée de validité du certificat et la clé privée.
Attention : si vous effectuez une demande auprès de votre autorité de certification, la durée maximale pour un certificat TLS/SSL est de 398 jours. Elle peut même être réduite en fonction de la CA. Soyez vigilant.
sudo openssl req -new -days 365 -key ldap.it-connect.local.key -out ldap.it-connect.local.csrUne série de questions va être posée afin de générer le CSR. Chaque champ correspond à une information qui sera inscrite dans la demande de certificat.
Faites attention, si vous souhaitez émettre votre CSR à une autorité de certification, certaines informations marquées « Facultatif » pourraient être demandées.
- Country Name (2 letter code) : Obligatoire - Code ISO du pays (ex : FR, US, DE).
- State or Province Name (full name) : Facultatif - Correspond à la région ou l’état d’un pays (ex : Île-de-France, California).
- Locality Name (eg, city) : Facultatif mais recommandé - Ville (ex : Paris, Lyon).
- Organization Name (eg, company) : Obligatoire - Nom de l’organisation (ex : it-connect).
- Organizational Unit Name (eg, section) : Facultatif - Département ou service (ex : Service IT).
- Common Name (CN) : Obligatoire - Le nom de domaine ou FQDN pour lequel le certificat sera valable (ex : ldap.it-connect.local)
- Email Address : Facultatif - Adresse mail de contact.
- Challenge password : Facultatif - L’idée originale était d’inscrire un mot de passe dans le CSR à une autorité de certification (CA) pour pouvoir l’utiliser comme une preuve d’authentification. Cependant, peu de CA utilisent ce mécanisme.
- Optional company name : Facultatif - Champ prévu pour ajouter un deuxième nom d’organisation (par exemple une maison-mère, une société partenaire, ou un alias commercial).
Effectuez de nouveau un ls, le fichier .csr est présent dans le répertoire.
Dans le cas où vous souhaitez demander votre certificat auprès d’une CA (publique ou privée), il faudra leur fournir le contenu de votre fichier CSR. Une fois validée, la CA vous retourne votre certificat.
Dans notre cas, nous allons générer un certificat x509 auto-signé, valable 1 an, à partir du CSR et de la clé privée grâce à la commande ci-dessous.
sudo openssl x509 -days 365 -in ldap.it-connect.local.csr -req -signkey ldap.it-connect.local.key -out ldap.it-connect.local.crtUne fois le traitement de la commande fini, le fichier .crt doit être présent.
Configuration LDAPS sur OpenLDAP
Maintenant que nous avons nos différents fichiers, nous allons pouvoir paramétrer OpenLDAP pour utiliser LDAPS.
La première étape va consister à donner les droits à OpenLDAP de lire la clé privée et le certificat du serveur afin de pouvoir établir des connexions sécurisées en LDAPS.
Pour cela, nous allons copier la clé privée et le certificat dans le répertoire de configuration de OpenLDAP. L’emplacement de ce répertoire change en fonction des distributions.
- Sous Debian :
Créez le répertoire certs dans /etc/ldap/ :
sudo mkdir /etc/ldap/certs
sudo cp ldap.it-connect.local.crt ldap.it-connect.local.key /etc/ldap/certs/- Sous Red Hat :
sudo cp ldap.it-connect.local.key ldap.it-connect.local.crt /etc/openldap/certs/Il faut maintenant changer les permissions pour ajouter les droits à OpenLDAP d’utiliser le certificat et la clé privée.
Nous allons tout d’abord utiliser chown -R pour changer le propriétaire et le groupe de la clé et du certificat (par défaut root) par OpenLDAP.
- Sous Debian :
sudo chown -R openldap:openldap /etc/ldap/certs- Sous Red Hat :
sudo chown -R ldap:ldap /etc/openldap/certsVérifiez avec ls -l que l’utilisateur ldap (sous Red Hat) ou openldap (sous Debian), dispose bien des droits en lecture et écriture sur la clé et le certificat.
ls -l <le répertoire>
Supprimez le répertoire ssl-ldap pour éviter de garder une clé privée et un certificat dans le home directory de l’utilisateur.
rm -r /home/timmy/ssl-ldapNous allons maintenant utiliser un fichier LDIF pour donner à OpenLDAP le certificat et la clé privée générée à utiliser pour chiffrer les communications LDAP.
Créez le fichier tls-ldap.ldif avec nano :
nano tls-ldap.ldifPuis copiez le contenu suivant selon votre distribution :
- Pour Debian :
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/certs/ldap.it-connect.local.crt
dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.it-connect.local.key- Pour Red Hat :
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap.it-connect.local.crt
dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.it-connect.local.keyAppliquez le fichier avec ldapmodify :
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls-ldap.ldifLa commande doit vous renvoyer que les deux entrées ont bien été modifiées.
Ensuite, il faut procéder à la configuration du service slapd afin qu’OpenLDAP écoute sur le port 636 en plus du port 389 et du socket local.
Si vous souhaitez n’utiliser que le protocole LDAPS pour vos communications et enlever le protocole LDAP classique, ne laissez que la partie ldaps://// dans vos fichiers.
La manipulation n’est pas la même en fonction des distributions. Suivez bien la partie correspondante.
- Sous Debian :
Éditez le fichier slapd avec nano :
nano /etc/default/slapdDans le paramètre SLAPD_SERVICES, ajoutez ldaps:///.
Redémarrez le service :
sudo systemctl restart slapdVous pouvez vérifier le résultat de la commande avec la commande ss suivante :
sudo ss -tulpen | grep slapdOn remarque que le serveur écoute sur les ports 389 et 636 en IPv4 (0.0.0.0) et IPv6 ([ ::]).
Passez à la configuration du fichier ldap.conf.
- Sous Red Hat :
Il est nécessaire de créer un « override systemd », il s’agit d’un fichier lié à un service que systemd va lire avant d’exécuter le service. Dans notre cas, nous allons lui demander à slapd d’écouter le port 636 pour recevoir les requêtes LDAPS.
Tapez la commande suivante :
sudo systemctl edit slapdAjoutez-y le contenu ci-dessous.
Le premier ExecStart= vide sert à effacer la commande de démarrage originale, pour que seule la nouvelle ligne ExecStart=/usr/sbin/slapd… soit utilisée par systemd.
[Service]
ExecStart=
ExecStart=/usr/sbin/slapd -u ldap -h "ldap:/// ldapi:/// ldaps:///"Redémarrez le service :
sudo systemctl restart slapdVous pouvez vérifier le résultat obtenu avec la commande ss suivante :
sudo ss -tulpen | grep slapdOn remarque que le serveur écoute sur les ports 389 et 636 en IPv4 (0.0.0.0) et IPv6 ([ ::]).
Nous allons maintenant modifier le fichier ldap.conf qui permet de définir la configuration par défaut des outils clients LDAP (comme ldapsearch, ldapadd, ldapmodify…).
Dans ce fichier, nous allons spécifier l’emplacement du certificat à utiliser pour établir la connexion TLS.
Modifiez le fichier ldap.conf.
- Sous Debian :
sudo nano /etc/ldap/ldap.confAjoutez ceci :
TLS_CACERT /etc/ldap/certs/ldap.it-connect.local.crt
TLS_REQCERT demand- Sous Red Hat :
sudo nano /etc/openldap/ldap.confAjoutez ceci :
TLS_CACERT /etc/openldap/certs/ldap.it-connect.local.crt
TLS_REQCERT demand
Redémarrez le service avec systemctl pour appliquer la configuration :
sudo systemctl restart slapdDésormais, configurez le pare-feu pour autoriser les connexions entrantes sur le port 636.
- Sous Debian :
sudo ufw allow ldaps
sudo ufw reload- Sous Red Hat :
sudo firewall-cmd --permanent --add-service=ldaps
sudo firewall-cmd --reloadLa configuration est finie, testons-là.
Validation de la configuration
En local
Faisons tout d’abord un test sur le serveur avec la commande ldapsearch comportant l’option -H pour définir sur quel serveur LDAP se connecter mais surtout avec quel protocole. Ici LDAPS :
ldapsearch -x -H ldaps://ldap.it-connect.local -b "dc=it-connect,dc=local"La commande doit vous renvoyer l’intégralité du contenu de votre annuaire :
Windows - Ldp.exe
Nous allons utiliser l’outil ldp.exe de Microsoft, sur une VM Windows 11 cliente, qui permet de se connecter à un annuaire LDAP et d’explorer son contenu.
Comme il s’agit d’un certificat auto-signé, il faut transférer le certificat ldap.it-connect.local.crt de votre machine Linux à votre machine Windows à l’aide de WinSCP par exemple. Une fois que le certificat est sur la machine, double-cliquez dessus.
Cliquez sur le bouton "Installer un certificat", choisissez "Ordinateur local" puis cliquez sur le bouton "Suivant".
Suivez l'assistant en veillant à placer ce certificat dans le magasin nommé "Autorités de certification racines de confiance". Cliquez sur le bouton "Parcourir" pour sélectionner ce magasin.
Finalisez l'importation.
Ouvrez l’application ldp.exe puis cliquez sur « Connexion » et « Se connecter » :
Indiquez ldap.it-connect.local en tant que serveur, spécifiez le numéro de port "636" et cochez la case "SSL". Cliquez sur "OK" pour tenter une connexion.
Un message devrait apparaitre pour vous dire que la connexion est établie :
Vous pouvez considérer que la connexion LDAPS est opérationnelle !
Client Linux
Nous allons pour finir tester la configuration sur un client Linux en nous authentifiant avec un utilisateur de notre annuaire.
Attention : le schéma nis doit être importé dans votre configuration LDAP, sinon cela ne fonctionnera pas. De la même manière, vos utilisateurs et groupes doivent posséder les attributs systèmes nécessaires (uid, gidNumer…).
Je vous recommande vivement d’installer les outils clients LDAP, indispensables pour tester et interroger votre serveur OpenLDAP, ainsi que pour diagnostiquer d’éventuels problèmes.
- Debian :
sudo apt-get install ldap-utils -y- Red Hat :
sudo dnf install openldap-clients -yComme pour la machine Windows, vous devez transférer le certificat auto-signé vers votre machine Linux, soit avec WinSCP, soit directement avec la commande scp afin de l’importer dans le magasin de certificats.
Si vous utilisez scp, pensez à adapter l’utilisateur, l’adresse IP du serveur OpenLDAP ainsi que le chemin exact où se trouve le certificat.
- Sous Debian :
sudo scp timmy@192.168.1.1:/home/timmy/ldap.it-connect.local.crt /usr/local/share/ca-certificates/- Sous Red Hat :
sudo scp timmy@192.168.1.1:/home/timmy/ldap.it-connect.local.crt /etc/pki/ca-trust/source/anchors/Puis, mettez à jour le magasin.
- Sous Debian :
sudo update-ca-certificates- Sous Red Hat :
sudo update-ca-trust extractEnfin, pour que la connexion TLS fonctionne, modifiez le fichier ldap.conf et ajoutez-y le contenu suivant, en adaptant le nom de votre certificat :
- Debian :
TLS_CACERT /usr/local/share/ca-certificates/ldap.it-connect.local.crt
TLS_REQCERT demand- Red Hat :
TLS_CACERT /etc/pki/ca-trust/source/anchors/ldap.it-connect.local.crt
TLS_REQCERT demandMaintenant que le certificat est importé, vous pouvez vérifier avec la commande ldapsearch suivante que l’intégralité de votre annuaire s’affiche.
ldapsearch -H ldaps://ldap.it-connect.local -x -b "dc=it-connect,dc=local" -D "cn=admin,dc=it-connect,dc=local" -W
Pour permettre aux utilisateurs de bénéficier d’un home directory, nous allons configurer le service SSSD.
SSSD est le service Linux qui gère l'authentification, l'autorisation et les informations des utilisateurs et des groupes provenant de diverses sources réseau (dont le protocole ldap). C’est grâce à lui que le home directory pourra être généré.
Créez ou modifiez le fichier sssd.conf.
sudo nano /etc/sssd/sssd.confAjoutez (si le fichier est vide) ou modifiez le contenu ci-dessous en fonction de votre configuration. Ce fichier va imposer l’utilisation de LDAPS pour s’authentifier sur le système.
[sssd]
services = nss, pam
config_file_version = 2
domains = it-connect.local
[nss]
[domain/it-connect.local]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.it-connect.local
cache_credentials = True
ldap_user_search_base = ou=Utilisateurs,dc=it-connect,dc=local
ldap_group_search_base = ou=Groupes,dc=it-connect,dc=local
ldap_id_use_start_tls = false
override_shell = /bin/bash
use_fully_qualified_names = TruePuis redémarrez le service sssd pour appliquer les changements :
sudo systemctl restart sssdSSSD est configuré. Vous pouvez maintenant tester de vous connecter à l’un de vos utilisateurs avec la commande :
su - [email protected]
Votre utilisateur est connecté et bénéficie d’un home directory !
Analyse Wireshark
Si nous capturons les échanges entre le serveur OpenLDAP et le client, avec une application telle que Wireshark, nous pouvons voir que les échanges LDAP sont chiffrés à l'aide de TLS.
Conclusion
Grâce à ce tutoriel, vous avez mis en place LDAPS sur votre serveur OpenLDAP, garantissant ainsi la confidentialité et l’intégrité des échanges entre le serveur et les clients LDAP. Vous disposez désormais d’un serveur OpenLDAP sécurisé et prêt à être intégré dans un environnement professionnel conforme aux bonnes pratiques de sécurité !
Les authentifications de vos utilisateurs Linux sont désormais chiffrées, et selon votre choix de configuration, seul le protocole LDAPS est autorisé, renforçant encore davantage la sécurité de vos communications.
Je vous remercie pour votre lecture, n’hésitez pas à laisser votre avis dans les commentaires.
