7 Erreurs de Configuration RADIUS à Éviter Absolument en 2026

Un serveur RADIUS mal configuré, c’est une bombe à retardement pour votre infrastructure réseau. Les conséquences sont immédiates et mesurables : indisponibilité du réseau pendant les heures critiques, failles d’authentification exploitables par des acteurs malveillants, et impossibilité de produire les journaux d’audit requis par les réglementations en vigueur (NIS2, ISO 27001, RGPD). Ce guide recense les 7 erreurs les plus fréquentes, les explique et vous donne les bonnes pratiques pour les corriger.

Erreur 1 : Ne pas activer le chiffrement des communications RADIUS (RADSEC / TLS)

RADIUS utilise historiquement UDP comme protocole de transport, avec un chiffrement partiel basé sur MD5 — un algorithme considéré comme cryptographiquement obsolète. Les échanges entre votre NAS et votre serveur RADIUS transitent en clair sur le réseau, à l’exception du mot de passe utilisateur masqué par MD5. Un attaquant positionné en man-in-the-middle peut capturer les paquets et tenter des attaques par dictionnaire sur les hash MD5.

La bonne pratique : déployez RADSEC (RFC 6614), qui encapsule le protocole RADIUS dans une connexion TLS ou DTLS. Le port d’écoute passe du 1812/UDP au 2083/TCP. RADSEC garantit la confidentialité et l’intégrité de l’ensemble des échanges.

Erreur 2 : Utiliser un secret partagé faible entre NAS et serveur RADIUS

Le secret partagé (shared secret) est la clé symétrique qui authentifie les échanges entre le NAS et le serveur RADIUS. Nombre d’administrateurs conservent les valeurs par défaut proposées par leur équipementier (« radius », « secret », « cisco », « testing123 »), ou choisissent des secrets trop courts, soumis à des attaques par force brute en quelques heures.

La bonne pratique : générez des secrets partagés d’une longueur minimale de 32 caractères, composés de caractères alphanumériques et de symboles. Configurez un secret distinct pour chaque NAS enregistré dans votre serveur RADIUS. Auditez et renouvelez ces secrets tous les 12 mois au minimum.

Erreur 3 : Ne pas segmenter les politiques réseau par groupe Active Directory

Mettre tous les utilisateurs authentifiés sur le même VLAN est l’erreur architecturale la plus répandue. Un technicien de maintenance externe, un stagiaire et un administrateur système atterrissent sur le même segment réseau, avec les mêmes droits d’accès aux ressources internes. En cas de compromission d’un compte à faibles privilèges, la latéralisation vers des ressources critiques devient triviale.

La bonne pratique : définissez des politiques RADIUS distinctes par groupe AD en utilisant les attributs RADIUS Tunnel-Type, Tunnel-Medium-Type et Tunnel-Private-Group-ID pour l’assignation dynamique de VLAN. Consultez notre guide sur le RADIUS couplé à Active Directory pour une implémentation détaillée.

Erreur 4 : Négliger la haute disponibilité RADIUS (primaire / secondaire)

Un seul serveur RADIUS, c’est un single point of failure pour l’ensemble de vos accès réseau. Panne matérielle, mise à jour logicielle, saturation CPU lors d’un pic d’authentifications simultanées : si le serveur RADIUS devient indisponible, plus aucun utilisateur ne peut s’authentifier sur le WiFi d’entreprise.

La bonne pratique : déployez systématiquement un serveur RADIUS secondaire (failover), configuré en mode hot standby. Les NAS doivent être configurés avec un timeout et un nombre de retries cohérents (3 tentatives, 5 secondes de timeout) avant bascule sur le serveur secondaire. Testez le failover activement, au minimum une fois par trimestre.

Erreur 5 : Ignorer l’accounting RADIUS (port 1813)

L’accounting RADIUS (port 1813/UDP) consigne le début, la fin et les statistiques de chaque session réseau authentifiée. Beaucoup d’administrateurs activent uniquement l’authentification (port 1812) et laissent l’accounting désactivé. Cette omission a des conséquences directes sur la traçabilité : en cas d’incident de sécurité ou d’audit de conformité, il est impossible de reconstituer l’historique des connexions.

La bonne pratique : activez l’accounting RADIUS sur l’ensemble de vos NAS et centralisez les logs dans votre SIEM. Définissez une politique de rétention conforme à vos obligations légales (minimum 12 mois pour NIS2).

Erreur 6 : Oublier le renouvellement des certificats EAP-TLS

EAP-TLS est la méthode d’authentification RADIUS la plus sécurisée, basée sur des certificats clients et serveur. Consultez notre guide sur le RADIUS WiFi avec EAP-TLS. Les certificats ont une durée de vie limitée — généralement 1 à 3 ans — et leur expiration provoque une coupure totale des authentifications sans aucun avertissement pour les utilisateurs finaux.

La bonne pratique : inventoriez l’ensemble des certificats utilisés dans votre chaîne RADIUS. Configurez des alertes automatiques à 90, 60 et 30 jours avant expiration. Intégrez le renouvellement des certificats dans votre processus ITSM avec une tâche récurrente.

Erreur 7 : Sous-dimensionner le serveur RADIUS

Le dimensionnement du serveur RADIUS est souvent réalisé sur la base du nombre d’utilisateurs déclarés, sans tenir compte des pics d’authentifications simultanées. Le scénario critique n’est pas la charge nominale : c’est le lundi matin à 9h00 quand 500 collaborateurs allument leur poste de travail simultanément, ou le redémarrage du réseau après une coupure qui force une ré-authentification massive de tous les équipements 802.1X.

La bonne pratique : dimensionnez votre serveur RADIUS en prenant comme référence le nombre d’authentifications simultanées au pic (règle empirique : 10 % du parc de postes en connexion simultanée). Benchmarkez votre solution RADIUS retenue avec des outils de test de charge. Prévoyez une marge de 40 % au-dessus du pic mesuré.