FreeRADIUS & Active Directory : corriger l’erreur « ldap: hit reconnection limit » (timeouts, pool, LDAPS)

Vous voyez « ldap: hit reconnection limit » lors des authentifications FreeRADIUS vers Active Directory ? Voici un guide concret pour diagnostiquer, corriger et durcir durablement votre chaîne RADIUS → LDAP/AD.

Sommaire

Vue d’ensemble du problème

Lorsque FreeRADIUS utilise le module rlm_ldap pour interroger Active Directory, il maintient un pool de connexions LDAP. L’erreur ldap: hit reconnection limit survient lorsque le module a tenté de (re)lier plusieurs fois au DC sans succès, ou que le pool ne parvient plus à fournir de connexions utilisables (timeouts, fermetures côté réseau, limites AD atteintes, etc.). Le résultat visible côté clients : délais d’authentification, refus ponctuels ou tempêtes d’échecs sous charge.

Symptômes typiques et messages

# freeradius -X
(0) ldap: Connecting to ldap.example.com:636
(0) ldap: TLS connected ok, attempting bind as CN=radiusbind,OU=Service Accounts,DC=example,DC=com
(0) ldap: Failed performing bind: Can't contact LDAP server
(0) ldap: Reconnecting in 5 seconds...
(0) ldap: Reconnecting ...
(0) ldap: hit reconnection limit
(0) ERROR: ldap: Connection pool full
(0) ERROR: ldap: Operation timed out

Ces messages indiquent que les liaisons échouent ou qu’aucune connexion du pool n’est opérationnelle pendant la fenêtre d’attente.

Causes possibles

Catégorie	Explications courantes
Disponibilité du serveur LDAP	AD indisponible ou latence réseau excessive provoquant l’expiration des tentatives de liaison.
Limites côté AD	Valeurs trop basses pour MaxConn (nombre max. de connexions) ou MaxConnIdleTime (temps d’inactivité) dans la configuration LDAP d’Active Directory.
Paramètres FreeRADIUS	Compteurs `retry_count`, `retry_delay` et `timeout` insuffisants, ou absence de `idle_timeout` / `pool { max }` adaptés dans `mods-available/ldap`.
Pare‑feu / filtrage réseau	Ports 389 (LDAP) ou 636 (LDAPS) filtrés ou soumis à inspection entraînant des ré‑ouvertures de session trop fréquentes.

Diagnostic rapide (checklist exécutable)

Tester la prise de connexion vers le DC : # nc -vz ldap.example.com 389 # nc -vz ldap.example.com 636 # openssl s_client -connect ldap.example.com:636 -servername ldap.example.com -showcerts Vérifiez la chaîne de certificats, la négociation TLS et l’absence de coupure immédiate.
Tester une recherche LDAP avec le compte de liaison : # ldapsearch -H ldaps://ldap.example.com:636 -x \ -D "CN=radiusbind,OU=Service Accounts,DC=example,DC=com" -W \ -b "DC=example,DC=com" "(sAMAccountName=utilisateur_test)" 1.1 Si bind ou recherche échoue ici, FreeRADIUS échouera aussi.
Tracer le trafic pour vérifier les resets/timeouts : # tcpdump -ni any 'port 389 or port 636'
Observer le pool depuis le système : # ss -antp | egrep ':389|:636' | wc -l # ss -antp | egrep ':389|:636' | head -n 10 Comparez ce volume à vos seuils AD (MaxConn) et au pool { max }.
Mode debug FreeRADIUS pour capturer la séquence exacte des échecs : # systemctl stop freeradius # freeradius -X Repérez Timeout, Cannot bind, Connection pool full, ldap: hit reconnection limit.
Valider l’authentification de bout en bout depuis le serveur RADIUS : # radtest utilisateur_test motdepasse 127.0.0.1 0 testing123 Remplacez le secret et l’IP par celles de votre client NAS si besoin.

Réglages côté Active Directory (LDAP Policies)

Active Directory expose des LDAP policies qui bornent les connexions et leur inactivité. Un dimensionnement trop serré déclenche la fermeture des sessions, forçant FreeRADIUS à se reconnecter en boucle jusqu’à atteindre la limite de reconnexions.

Paramètres clés à auditer

MaxConn (nombre max. de connexions simultanées)
MaxConnIdleTime (durée d’inactivité avant fermeture, en secondes)
MaxPoolThreads (threads de traitement LDAP)
MaxActiveQueries (requêtes concurrentes)
MaxPageSize (pagination des résultats)

Ces valeurs se trouvent généralement dans les paramètres LDAP d’AD DS (via ADSI Edit, ntdsutil ou la base de registre). Procédez prudemment, documentez les valeurs avant modification et planifiez un redémarrage du service AD DS (ou du DC) si requis.

Bonnes pratiques de réglage AD

Fixez MaxConn au‑dessus du pic attendu (conns RADIUS) + marge de 20–30 %.
Augmentez MaxConnIdleTime si vos flux comportent des périodes calmes, ou baissez idle_timeout côté FreeRADIUS pour rester en‑dessous du seuil AD (voir plus bas).
Gardez des threads (MaxPoolThreads) cohérents avec les cœurs CPU du DC et la charge globale (Kerberos, GC, etc.).
Surveillez le Journal d’événements (Directory Service, Security) pendant vos tests pour repérer les fermetures, throttling ou erreurs d’accès.

Réglages côté FreeRADIUS (rlm_ldap)

Commencez par un module LDAP proprement dimensionné. Exemple de base dans /etc/raddb/mods-available/ldap :

ldap {
    server          = 'ldap.example.com'
    port            = 636
    start_tls       = no            # ou 'yes' si vous utilisez 389 + STARTTLS
    identity        = 'CN=radiusbind,OU=Service Accounts,DC=example,DC=com'
    password        = '********'
    base_dn         = 'DC=example,DC=com'

```
# Pool de connexions
pool {
    start           = 4
    min             = 4
    max             = 32        # augmentez si le trafic est soutenu
    spare           = 3
    uses            = 0
    retry_delay     = 30        # secondes avant nouvelle tentative
    lifetime        = 0
    idle_timeout    = 60        # &lt;= MaxConnIdleTime côté AD
}

# Délais
timeout         = 10            # délai de requête LDAP
timelimit       = 30
net_timeout     = 10

# Retentatives
retry_count     = 5
```

}

Activez ensuite le module et reliez‑le dans vos sites (authorize/authenticate/post-auth) :

# ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

# Extrait typique (sites-enabled/default)

authorize {
ldap
# ...
}
authenticate {
Auth-Type LDAP {
ldap
}
}

Redémarrez FreeRADIUS après modification :

# systemctl restart freeradius

Dimensionner le pool : méthode pragmatique

Estimez la concurrence maximale à absorber par AD :

Paramètre	Symbole	Exemple
Taux d’authentifications RADIUS (requêtes/s)	T	120 req/s
Opérations LDAP par auth (recherche + groupe)	O	2 ops
Temps moyen d’une opération LDAP (s)	D	0,08 s
Connexions simultanées requises ≈ T × O × D	C	120 × 2 × 0,08 = 19,2 → 24

Fixez pool { max } ≈ C + 25 % et restez bien en‑dessous de MaxConn côté AD (en tenant compte d’autres consommateurs LDAP). Ajustez start/min pour éviter un cold start pénalisant.

Temps d’inactivité et timeouts

idle_timeout doit être strictement inférieur à MaxConnIdleTime d’AD pour éviter les fermetures côté DC qui surprennent le pool.
timeout et net_timeout doivent couvrir la latence maximale observée + marge (ex. 10–15 s sur WAN chargé).
retry_count et retry_delay : assez élevés pour absorber une micro‑panne, sans créer d’emballement. Typiquement 5 tentatives avec un délai de 30 s.

Cache des appartenances aux groupes

Si votre version expose un bloc cache { enable = yes } dans le module LDAP, activez‑le pour réduire la pression sur AD lors des filtrages par groupe. À défaut, utilisez le module rlm_cache (par ex. rbtree ou memcached) pour conserver temporairement les résultats de groupe et limiter les lectures répétées.

Fichier ouvert / ressources processus

Un pool conséquent augmente le nombre de sockets. Assurez‑vous que la limite de descripteurs est suffisante :

# systemctl edit freeradius
# -- override --
[Service]
LimitNOFILE=65536

# systemctl daemon-reload
# systemctl restart freeradius

Réseau et chiffrement : éviter les fermetures intempestives

Pare‑feu / IDS/IPS : interdisez l’inspection active sur LDAPS si elle casse la session. Autorisez 389/636 entre RADIUS et DC avec des timeouts d’état cohérents (ex. ≥ 5 min).
Keepalive TCP : si un équipement ferme agressivement les connexions inactives, activez un keepalive système inférieur au timeout réseau : # sysctl -w net.ipv4.tcp_keepalive_time=120 # sysctl -w net.ipv4.tcp_keepalive_intvl=30 # sysctl -w net.ipv4.tcp_keepalive_probes=3
TLS : utilisez LDAPS (636) ou STARTTLS avec la racine AD installée sur le serveur RADIUS. Vérifiez la SNI, les protocoles acceptés et les suites de chiffrement. Un échec TLS déclenche des reconnexions en chaîne.

Procédure de remédiation recommandée

Vérifier la santé du DC : disponibilité, charge CPU/RAM/IO, latence depuis le serveur RADIUS.
Confirmer le bind avec ldapsearch en LDAPS. Corriger certificats et droits du compte.
Aligner les timeouts : idle_timeout (RADIUS) < MaxConnIdleTime (AD). Ajuster timeout/net_timeout.
Dimensionner le pool : fixez pool { max } selon la formule T×O×D, puis marge 25 %. Gardez une distance confortable avec MaxConn d’AD.
Assouplir les limites AD si nécessaire (MaxConn, MaxPoolThreads), en coordination avec l’équipe AD.
Stabiliser le réseau : timeouts pare-feu, keepalive TCP côté RADIUS, pas d’inspection cassante sur 636.
Sécuriser le compte de liaison : non expirant, non verrouillable en routine, rotation planifiée. Évitez « must change password ».
Activer le cache des groupes si vous faites des group checks intensifs.
Superviser : exporter le nombre de connexions établies (ss), la latence LDAP, le taux d’échecs d’authentification. Définir des seuils d’alerte avant saturation.

Exemples concrets de commandes utiles

# Compter les sessions LDAP actives vers le DC
ss -antp | egrep 'ESTAB.*(:389|:636)' | wc -l

# Voir les PID et processus détenteurs des sockets

ss -antp | egrep ':389|:636'

# Mesurer la latence réseau vers le DC

ping -c 10 ldap.example.com

# Tester STARTTLS sur 389

openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com

# Relancer FreeRADIUS proprement

systemctl restart freeradius

# Debug focalisé (verbeux)

freeradius -X | tee /tmp/fr_ldap_debug.log

Cartographie des messages d’erreur vers des actions

Message	Cause probable	Action
`ldap: hit reconnection limit`	Échec répété de bind/connexion : DC indisponible, TLS cassé, limites AD.	Tester `ldapsearch`, vérifier certificats, logs AD, relever MaxConn ou baisser `idle_timeout`.
`Connection pool full`	Pool saturé, fuites, timeouts trop longs, charge pointe.	Augmenter `pool { max }`, réduire délai d’attente, optimiser requêtes et cache.
`Can't contact LDAP server`	Coupure réseau/TLS, pare‑feu, DC down.	Valider ports 389/636, inspection, `openssl s_client`.
`Operation timed out`	Latence réseau, DC surchargé, `timeout` trop court.	Allonger `timeout`/`net_timeout`, soulager le DC.

Optimisations complémentaires

Répartition de charge : si le trafic RADIUS est important (Wi‑Fi d’entreprise, hotspots), déployez plusieurs serveurs FreeRADIUS derrière un répartiteur et/ou utilisez un alias DNS pointant vers plusieurs DC. Visez la proximité réseau.
Réduction des requêtes LDAP : ne cherchez que les attributs nécessaires. Évitez les filtres gourmands ou non indexés.
Journalisation ciblée : en debug, filtrez sur rlm_ldap pour réduire le bruit et repérer les séquences fautives.
Supervision proactive : alertez sur le ratio « échecs LDAP / total requêtes », la latence p95/p99, l’occupation du pool et la disponibilité TLS.

Exemple de configuration commentée (référence)

ldap {
    server          = 'ldap.example.com'
    port            = 636
    start_tls       = no

```
identity        = 'CN=radiusbind,OU=Service Accounts,DC=example,DC=com'
password        = '********'
base_dn         = 'DC=example,DC=com'

# Recherche utilisateur
user {
    base_dn     = 'DC=example,DC=com'
    filter      = '(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})'
}

# Groupes AD (utilisés pour l'autorisation)
group {
    base_dn     = 'DC=example,DC=com'
    filter      = '(member=%{control:LDAP-UserDN})'
    name_attribute = 'cn'
}

# Cache (si disponible dans votre version)
# cache {
#     enable = yes
#     ttl    = 300
# }

pool {
    start           = 4
    min             = 4
    max             = 32
    spare           = 3
    retry_delay     = 30
    lifetime        = 0
    idle_timeout    = 60
}

timeout         = 10
timelimit       = 30
net_timeout     = 10
retry_count     = 5
```

}

Contrôles de sécurité essentiels

Chiffrement systématique : LDAPS ou STARTTLS uniquement, certificats valides et chaînés.
Compte de liaison : privilèges minimaux (lecture des attributs requis), mot de passe non expirant (ou rotation orchestrée et testée).
Journaux : activez l’audit LDAP « Directory Service Access » côté AD pour diagnostiquer des échecs précoces.

Scénarios typiques et corrections rapides

Cas A : tout va bien en heures creuses, mais l’erreur surgit aux heures de pointe.
Augmentez pool { max } et MaxConn AD, ajoutez du cache de groupes, vérifiez timeout (trop court) et la CPU du DC.

Cas B : coupures aléatoires avec inspection TLS.
Désactivez l’inspection pour 636 ou excluez le flux RADIUS → AD. Installez la racine AD côté RADIUS. Validez via openssl s_client.

Cas C : pool qui se vide la nuit.
Le DC ferme les connexions inactives via MaxConnIdleTime. Baissez idle_timeout (ex. 45 s) ou augmentez MaxConnIdleTime (ex. 120 s) pour synchroniser les comportements.

Checklist finale avant mise en production

LDAPS/STARTTLS validé (openssl s_client), chaîne de confiance OK.
idle_timeout < MaxConnIdleTime (preuve par mesures).
Pool dimensionné avec marge, MaxConn AD ajusté.
Pare‑feu sans inspection cassante, timeouts d’état ≥ 5 min, keepalive TCP actif si besoin.
Compte de liaison sain (pas d’expiration imprévue), droits minimaux.
Cache de groupes activé si filtrage par groupes intensif.
Tableau de bord de supervision prêt (latence LDAP, erreurs, occupation du pool).

Conclusion

L’erreur « ldap: hit reconnection limit » n’est pas une fatalité. En alignant les LDAP policies d’Active Directory avec le dimensionnement du pool rlm_ldap, en réglant précisément idle_timeout et les délais, et en stabilisant la couche réseau/TLS, vous éliminerez les reconnexions massives et rétablirez une authentification FreeRADIUS ↔ AD fiable, y compris sous charge.

Annexe : matrice de paramètres recommandés (point de départ)

Contexte	Pool FreeRADIUS	Timeouts FreeRADIUS	LDAP Policies AD
Petite structure (≤ 500 util.)	`start=2`, `min=2`, `max=8`, `idle_timeout=60`	`timeout=10`, `retry_count=5`, `retry_delay=30`	MaxConn ≥ 50, MaxConnIdleTime ≥ 90 s
Site moyen (Wi‑Fi d’entreprise)	`start=4`, `min=4`, `max=32`, `idle_timeout=60`	`timeout=12`, `retry_count=5`, `retry_delay=30`	MaxConn ≥ 200, MaxConnIdleTime ≥ 120 s
Grande charge (campus, hotspot)	`start=8`, `min=8`, `max=64`, `idle_timeout=45–60`	`timeout=15`, `retry_count=6`, `retry_delay=20–30`	MaxConn ≥ 500, MaxConnIdleTime ≥ 180 s

Récapitulatif des actions à fort impact

Synchroniser idle_timeout (RADIUS) et MaxConnIdleTime (AD).
Calibrer le pool selon T×O×D (+ marge).
Normaliser la couche TLS (certificats, suites, SNI).
Stabiliser le réseau (timeouts pare‑feu, keepalive).
Décharger AD via cache et filtres ciblés.