Cet article décrit comment utiliser HA Proxy en tant que Proxy LDAP pour assurer de l'équilibrage de charge et de la haute-disponibilité. Dans notre cas, on utilise un container sous Rocky9 pour notre proxy.

Le proxy va également porter le certificat LDAPS.

Environnement cible

On aura 3 serveurs :

• haldap.id-num.fr : le proxy LDAP / LDAPS
• odj1.id-num.fr : serveur LDAP sous OpenDJ
• odj2.id-num.fr : serveur LDAP sous OpenDJ

Les 2 serveurs LDAP écoutent sur les ports 1389 (LDAP) et 1636 (LDAPS).

De notre côté, en frontal, le proxy écoutera sur les ports standards : 389 (LDAP) et 636 (LDAPS).

On aura auparavant généré un certificat avec une PKI.

Installation de HA Proxy

Le serveur qui va servir de proxy est sous Rocky 9 Linux. La version de HA Proxy est 2.4.22.

On fait d'abord les mises à jours du système :

yum update

Puis on installe haproxy :

yum install -y haproxy

Configuration

La configuration s'effectue dans le fichier /etc/haproxy/haproxi.cfg. Dans notre cas, nous n'avons pas besoin de la configuration http.

global
    log         127.0.0.1:514 local0 info

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

    # utilize system-wide crypto-policies
    ssl-default-bind-ciphers PROFILE=SYSTEM
    ssl-default-server-ciphers PROFILE=SYSTEM

defaults
    mode                tcp
    log                 global
    option              tcplog  
    option              dontlognull
    option              redispatch
    retries             3
    timeout connect     5s
    timeout client      1m
    timeout server      1m
    maxconn             3000

Dans notre cas (version 2.4 de haproxy), nous avons ajouté un fichier ldap.cfg dans le répertoire /etc/haproxy/conf.d :

# Configuration LDAP HA Proxy

frontend ldap
     bind *:389
     mode tcp
     log global
     option tcplog
     default_backend ldap_servers_ssl

 backend ldap_servers
     mode tcp
     balance first
     option ldap-check
     server ldap1 odj1.id-num.fr:1389 
     server ldap2 odj2.id-num.fr:1389

 frontend ldap_ssl
     bind *:636 ssl crt /etc/haproxy/certs/haldap.id-num.fr.crt
     mode tcp
     log global
     option tcplog
     default_backend ldap_servers_ssl

 backend ldap_servers_ssl
     mode tcp
     balance first
     option ldap-check
     server ldap1 odj1.id-num.fr:1636 check-ssl ssl verify none ca-file /etc/haproxy/certs/ca.id-num.crt
     server ldap2 odj2.id-num.fr:1636 check-ssl ssl verify none ca-file /etc/haproxy/certs/ca.id-num.crt

Dans le répertoire /etc/haproxy/certs on a copié le certificat correspondant à notre proxy, et la clé privée :

$ ls -l certs/haldap.id-num.fr.crt*
-rw-r--r-- 1 root root 6180 Oct 14 13:00 certs/haldap.id-num.fr.crt
-rw-r--r-- 1 root root 1708 Oct 14 12:10 certs/haldap.id-num.fr.crt.key

La configuration définit donc 2 ports possibles (dans le bloc frontend) :

• 389 pour le protocole LDAP, qui redirige vers les ports 1389 sur les serveurs cibles
• 636 pour le protocole LDAPS, qui redirige vers les ports 1636 sur les serveurs cibles.

On utilise l'algorithme first qui permet de gérer un mode failover : les requêtes sont toujours adressées au premier serveur, et basculent sur le second uniquement si le premier ne répond plus.

Dans notre cas, l'option verify none est utilisé car les serveurs utilisent des certificats auto-signés.

Si les certificats étaient générés par une PKI, on pourrait utiliser l'option verify required avec le chemin du certificat de l'autorité de confiance.

Configuration des Logs - rsyslog

Pour envoyer les logs dans un fichier spécifique, il faut également modifier la configuration rsyslog, dans /etc/rsyslog.conf :

# Logging UDP pour HA Proxy
      $ModLoad imudp
      $UDPServerAddress *
      $UDPServerRun 514
local0.*        /var/log/haproxy.log

Il faut ensuite relancer rsyslog et haproxy pour récupérer les messages.

systemctl restart haproxy
systemctl restart rsyslog

tail /var/log/haproxy.log

Oct 14 14:57:52 localhost haproxy[1481]: 10.10.27.1:42176 [14/Oct/2025:14:57:52.365] ldap_ssl~ ldap_servers_ssl/ldap1 13/8/35 103 -- 1/1/0/0/0 0/0
Oct 14 15:03:30 localhost haproxy[1481]: 10.10.27.1:34144 [14/Oct/2025:15:03:30.036] ldap_ssl~ ldap_servers_ssl/ldap1 24/5/46 104 -- 1/1/0/0/0 0/0
Oct 14 15:03:31 localhost haproxy[1481]: 10.10.27.1:34156 [14/Oct/2025:15:03:31.090] ldap_ssl~ ldap_servers_ssl/ldap1 13/4/42 105 -- 1/1/0/0/0 0/0
Oct 14 15:03:32 localhost haproxy[1481]: 10.10.27.1:49420 [14/Oct/2025:15:03:32.146] ldap_ssl~ ldap_servers_ssl/ldap2 20/5/39 102 -- 1/1/0/0/+1 0/0
Oct 14 15:03:33 localhost haproxy[1481]: 10.10.27.1:49428 [14/Oct/2025:15:03:33.217] ldap_ssl~ ldap_servers_ssl/ldap2 29/4/47 412 -- 1/1/0/0/+1 0/0
Oct 14 15:03:34 localhost haproxy[1481]: 10.10.27.1:49436 [14/Oct/2025:15:03:34.284] ldap_ssl~ ldap_servers_ssl/ldap2 25/2/44 412 -- 1/1/0/0/+1 0/0

On constate bien que lorsque le serveur ldap1 est arrêté (15:03:31), les flux sont orientés vers le serveur ldap2.