FreeRADIUS et 802.1X : Guide Complet d'Authentification Réseau Centralisée 2026

FreeRADIUS combiné à 802.1X constitue l'architecture d'authentification réseau de référence pour les entreprises souhaitant contrôler précisément qui peut se connecter à leur réseau filaire et WiFi. Alors que les connexions VPN protègent l'accès distant, 802.1X protège l'accès réseau local — le réseau interne lui-même. Sans 802.1X, n'importe qui connectant un câble RJ45 à une prise murale de bureau ou se connectant à un SSID WiFi d'entreprise peut accéder au réseau, à condition de connaître le mot de passe WiFi. Avec 802.1X, chaque tentative de connexion est authentifiée individuellement contre une source d'autorité (Active Directory, LDAP, base locale) avant que l'accès réseau soit accordé. FreeRADIUS est l'implémentation RADIUS open source la plus répandue au monde — elle traite des milliards d'authentifications quotidiennes chez les FAI, les opérateurs mobiles et les entreprises. Ce guide couvre le protocole RADIUS (RFC 2865), les méthodes EAP (PEAP-MSCHAPv2 et EAP-TLS), l'installation sur Ubuntu 22.04, l'intégration Active Directory via LDAP, la configuration des switches Cisco et des AP WiFi, et les bonnes pratiques pour une PME de 200 postes.

Protocole RADIUS : Architecture et Messages

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) est un protocole AAA (Authentication, Authorization, Accounting) qui centralise la gestion des accès réseau. Initialement conçu pour les accès dial-up dans les années 1990, RADIUS est devenu le standard universel pour l'authentification réseau dans les entreprises, les FAI et les opérateurs télécoms.

Les 4 types de messages RADIUS :

• Access-Request : le NAS (Network Access Server — switch ou AP WiFi) envoie une demande d'authentification au serveur RADIUS avec les credentials de l'utilisateur
• Access-Accept : le serveur RADIUS approuve l'accès, optionnellement avec des attributs de politique (VLAN assigné, temps de session, bande passante)
• Access-Reject : authentification refusée
• Access-Challenge : le serveur demande des informations supplémentaires (utilisé dans les méthodes EAP multi-round)

Ports RADIUS :

• UDP 1812 : authentification (remplace l'ancien port 1645)
• UDP 1813 : accounting (remplace l'ancien port 1646)
• TCP 2083 : RadSec (RADIUS over TLS, pour la sécurisation du transport)

Secret partagé : la communication entre le NAS et le serveur RADIUS est protégée par un secret partagé (shared secret) — une chaîne de caractères configurée des deux côtés. Ce secret chiffre les mots de passe dans les Access-Request. Important : le secret partagé ne chiffre pas l'intégralité du message RADIUS — il faut utiliser RadSec (RADIUS over TLS) ou une connexion réseau isolée pour une sécurisation complète.

EAP : Méthodes d'Authentification et Tunnel TLS

EAP (Extensible Authentication Protocol) est un framework d'authentification utilisé dans 802.1X. Il fonctionne dans un tunnel RADIUS et supporte de nombreuses méthodes d'authentification. Les trois méthodes les plus utilisées en entreprise :

EAP-PEAP (Protected EAP) avec MSCHAPv2 : la méthode la plus déployée en entreprise. Établit un tunnel TLS entre le supplicant et le serveur RADIUS (authentification du serveur uniquement via son certificat), puis effectue l'authentification utilisateur via MSCHAPv2 (username/password) à l'intérieur du tunnel. Avantage : pas de certificat client requis, migration simple depuis l'authentification classique. Inconvénient : si le certificat serveur RADIUS n'est pas validé côté client, vulnérable aux attaques MITM (rogue RADIUS server).

EAP-TLS : la méthode la plus sécurisée. Authentification mutuelle via certificats des deux côtés — le serveur RADIUS présente son certificat ET le client présente un certificat client. Avantage : pas de mot de passe, résistant au phishing et aux brute forces, seuls les machines/utilisateurs avec certificat valide peuvent se connecter. Inconvénient : infrastructure PKI requise pour distribuer les certificats clients (via GPO/AD CS ou MDM).

EAP-TTLS : similaire à PEAP mais supporte des méthodes d'authentification interne plus variées (PAP, CHAP, MSCHAPv2). Moins répandu que PEAP en environnement Windows car nécessite un supplicant tiers.

802.1X : Port-Based NAC et Rôles

802.1X est un standard IEEE de contrôle d'accès réseau basé sur les ports (Port-Based Network Access Control, PNAC). Il définit trois entités :

• Supplicant : le client qui demande l'accès (ordinateur Windows, téléphone, tablette). Le supplicant est un logiciel — natif dans Windows (wired AutoConfig service, WiFi AutoConfig), macOS, iOS, Android.
• Authenticator : le switch réseau ou l'AP WiFi. Il fait transiter les messages EAP entre le supplicant et le serveur d'authentification. Jusqu'à ce que l'authentification soit réussie, le port ne donne accès qu'à un VLAN de quarantaine.
• Authentication Server : le serveur RADIUS (FreeRADIUS dans notre cas). Il valide les credentials et retourne la décision d'accès.

Le cycle d'authentification 802.1X :

1. Un appareil se connecte au port switch → le switch détecte le lien
2. Le switch (authenticator) envoie un EAP-Request/Identity
3. Le supplicant répond avec l'identité (username ou identité EAP anonyme)
4. Le switch encapsule dans RADIUS et envoie au serveur FreeRADIUS
5. FreeRADIUS démarre le tunnel EAP (PEAP ou TLS)
6. L'authentification se déroule dans le tunnel
7. FreeRADIUS envoie Access-Accept avec optionnellement un VLAN-ID
8. Le switch débloque le port dans le VLAN approprié

Pour les imprimantes, les téléphones IP et autres appareils sans supplicant 802.1X, utilisez le MAB (MAC Authentication Bypass) : le switch envoie l'adresse MAC de l'appareil au serveur RADIUS, qui l'autorise si elle est dans la liste blanche. MAB est moins sécurisé (MAC spoofing possible) mais nécessaire pour les appareils IoT.

Installation FreeRADIUS 3.x sur Ubuntu 22.04

# Installation des packages
apt update && apt install freeradius freeradius-ldap freeradius-utils

# Vérification du statut
systemctl status freeradius

# Structure des fichiers de configuration
/etc/freeradius/3.0/
├── clients.conf          # Déclaration des NAS (switches, AP)
├── users                 # Utilisateurs locaux (test/dev)
├── radiusd.conf          # Config globale daemon
├── mods-available/       # Modules disponibles (non actifs)
├── mods-enabled/         # Modules actifs (symlinks vers mods-available)
│   ├── eap               # Configuration EAP
│   ├── ldap              # Module LDAP/AD
│   └── ...
├── sites-available/      # Serveurs virtuels
└── sites-enabled/        # Serveurs actifs

Test basique de fonctionnement :

# Démarrer FreeRADIUS en mode debug (très verbeux)
freeradius -X

# Test depuis un autre terminal
radtest testuser testpassword 127.0.0.1 0 testing123
# Réponse attendue : Received Access-Accept

# Si Access-Reject : vérifiez le fichier /etc/freeradius/3.0/users
# Ajoutez : testuser Cleartext-Password := "testpassword"

Configuration clients.conf : Déclaration des NAS

Le fichier clients.conf déclare les équipements réseau autorisés à envoyer des demandes RADIUS. Chaque NAS (switch, AP WiFi, VPN concentrator) doit être déclaré avec son IP et son secret partagé.

# /etc/freeradius/3.0/clients.conf

# Switch de distribution
client switch-distribution-01 {
    ipaddr      = 192.168.1.1
    secret      = VotreSecretPartage2026!
    shortname   = sw-dist-01
    nas_type    = cisco
}

# Point d'accès WiFi (ou contrôleur WiFi central)
client ap-controller {
    ipaddr      = 192.168.1.10
    secret      = AutreSecretWifi2026!
    shortname   = ap-ctrl
    nas_type    = cisco
}

# Réseau entier (déconseillé en prod, OK pour test)
client intranet {
    ipaddr      = 192.168.0.0/16
    secret      = SecretIntranet2026!
    shortname   = intranet
}

Utilisez des secrets partagés forts (minimum 20 caractères, alphanumérique + spéciaux). En production, configurez RadSec (RADIUS over TLS) si votre infrastructure le supporte pour chiffrer l'intégralité du trafic RADIUS, pas seulement les mots de passe.

Intégration Active Directory via LDAP

Pour authentifier les utilisateurs AD dans FreeRADIUS :

# Activer le module LDAP
cd /etc/freeradius/3.0/mods-enabled
ln -s ../mods-available/ldap ldap

# Éditer la configuration LDAP
nano /etc/freeradius/3.0/mods-available/ldap

Configuration du module LDAP pour Active Directory :

ldap {
    server = "192.168.1.100"   # IP du contrôleur de domaine
    port = 389
    
    # Compte de service pour la recherche LDAP
    identity = "CN=svc_radius,OU=ServiceAccounts,DC=domain,DC=local"
    password = "MotDePasseServiceRadius2026!"
    
    # Base de recherche
    base_dn = "DC=domain,DC=local"
    
    user {
        base_dn = "${..base_dn}"
        filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    
    group {
        base_dn = "${..base_dn}"
        filter = "(objectClass=Group)"
        membership_attribute = "memberOf"
    }
    
    # TLS pour LDAPS (recommandé en production)
    tls {
        start_tls = no
        # Ou configurez LDAPS sur port 636
    }
}

Test de la connexion LDAP :

ldapsearch -H ldap://192.168.1.100 
  -D "svc_radius@domain.local" 
  -w "MotDePasseServiceRadius2026!" 
  -b "DC=domain,DC=local" 
  "(sAMAccountName=testuser)" 
  displayName mail memberOf

Configuration EAP-PEAP pour RADIUS

# /etc/freeradius/3.0/mods-enabled/eap
eap {
    default_eap_type = peap
    
    peap {
        default_eap_type = mschapv2
        
        tls-config tls-peap {
            # Certificat serveur RADIUS (auto-signé OK pour test, CA interne en prod)
            private_key_file = /etc/freeradius/3.0/certs/server.key
            certificate_file = /etc/freeradius/3.0/certs/server.pem
            ca_file = /etc/freeradius/3.0/certs/ca.pem
            
            # Protocoles TLS acceptés
            tls_min_version = "1.2"
        }
    }
    
    mschapv2 {
        send_error = yes
    }
}

Génération d'un certificat auto-signé pour les tests :

cd /etc/freeradius/3.0/certs
make

En production, utilisez une CA interne (Active Directory Certificate Services ou easy-rsa) pour générer un certificat signé par votre CA d'entreprise. Les supplicants Windows doivent faire confiance à cette CA — distribuez le certificat CA via GPO.

EAP-TLS : PKI et Certificats Clients

EAP-TLS est la méthode la plus sécurisée car elle requiert un certificat sur chaque poste client. La mise en œuvre nécessite une PKI interne :

Option 1 — Active Directory Certificate Services (AD CS) : si vous avez Windows Server, AD CS fournit une PKI intégrée. Les certificats clients sont distribués automatiquement via GPO aux machines jointes au domaine. C'est la solution la plus simple pour un environnement Windows.

Option 2 — easy-rsa (open source) :

# Installation easy-rsa
apt install easy-rsa

# Initialiser la PKI
make-cadir /etc/freeradius/easy-rsa
cd /etc/freeradius/easy-rsa
./easyrsa init-pki

# Créer la CA
./easyrsa build-ca nopass

# Certificat serveur RADIUS
./easyrsa gen-req radius-server nopass
./easyrsa sign-req server radius-server

# Certificat client (un par poste/utilisateur)
./easyrsa gen-req client-pc01 nopass
./easyrsa sign-req client client-pc01

# Export au format PKCS12 (pour import Windows)
openssl pkcs12 -export 
  -in pki/issued/client-pc01.crt 
  -inkey pki/private/client-pc01.key 
  -certfile pki/ca.crt 
  -out client-pc01.p12

Distribution des certificats clients sur les postes Windows : importez le fichier .p12 dans le magasin de certificats "Personnel" de l'ordinateur (pas de l'utilisateur) pour une authentification machine. Via GPO, scriptez l'import automatique.

Configuration Switch Cisco IOS pour 802.1X

! Configuration globale RADIUS
radius server FREERADIUS-SERVER
 address ipv4 192.168.1.200 auth-port 1812 acct-port 1813
 key 7 VotreSecretPartage2026!

! Activer 802.1X
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control

! Configuration par port
interface GigabitEthernet0/1
 description Port-Utilisateurs-802.1X
 switchport mode access
 switchport access vlan 10          ! VLAN par défaut (quarantaine)
 authentication port-control auto   ! Mode 802.1X auto
 dot1x pae authenticator
 dot1x timeout tx-period 7
 dot1x timeout quiet-period 30
 spanning-tree portfast
 
! VLAN de quarantaine (accès avant authentification)
interface Vlan999
 description QUARANTINE-PRE-AUTH
 ip address 192.168.99.1 255.255.255.0

Configuration de l'attribution de VLAN dynamique depuis RADIUS :

# Dans FreeRADIUS, configurez les attributs VLAN dans la réponse
# /etc/freeradius/3.0/users (ou via LDAP group-to-vlan mapping)
DEFAULT LDAP-Group == "CN=Employes,OU=Groups,DC=domain,DC=local"
    Tunnel-Type = VLAN,
    Tunnel-Medium-Type = IEEE-802,
    Tunnel-Private-Group-Id = "10"

Cette configuration attribue dynamiquement le VLAN 10 aux membres du groupe AD "Employes". Les visiteurs ou les appareils non authentifiés restent dans le VLAN de quarantaine (999).

Configuration AP WiFi WPA2-Enterprise

La configuration côté AP WiFi varie selon le contrôleur (Cisco WLC, Aruba, Ubiquiti UniFi, Ruckus), mais les paramètres RADIUS sont identiques :

SSID WLAN Settings:
  Security: WPA2-Enterprise (WPA2 with 802.1X)
  Encryption: AES-CCMP
  Authentication: EAP (PEAP ou TLS)
  
RADIUS Settings:
  Primary RADIUS Server IP: 192.168.1.200
  Primary RADIUS Port: 1812
  Shared Secret: VotreSecretWifi2026!
  Secondary RADIUS (failover): 192.168.1.201:1812

Machine Authentication vs User Authentication : en environnement Windows AD, vous pouvez configurer 802.1X pour authentifier la machine (certificat machine) au démarrage (avant le login), puis authentifier l'utilisateur après le login. Cette approche double garantit que seuls les appareils managés peuvent rejoindre le réseau ET que seuls les utilisateurs AD peuvent se connecter.

L'authentification réseau centralisée avec FreeRADIUS s'intègre parfaitement avec les logs SIEM — les logs RADIUS Access-Accept/Reject fournissent un audit trail complet des connexions réseau.

NPS Windows Server vs FreeRADIUS : Comparaison

Microsoft NPS (Network Policy Server) est la solution RADIUS native de Windows Server, disponible dans les éditions Standard et Datacenter :

Avantages NPS :

• Intégration native avec Active Directory — pas de configuration LDAP
• Interface graphique complète, plus accessible pour les équipes Windows
• Support natif des health checks Windows (NAP Network Access Protection)
• Pas de déploiement Linux supplémentaire

Avantages FreeRADIUS :

• Cross-platform (fonctionne sur Linux, macOS, Windows)
• Configuration plus flexible et scriptable (fichiers texte)
• Support de sources d'authentification hétérogènes (LDAP multi-domaines, bases SQL, fichiers plats)
• Gratuit sans licence Windows Server supplémentaire
• Meilleure performance sur matériel modeste

Recommandation : si vous avez déjà une infrastructure Windows Server avec AD, NPS est le choix naturel. Si votre infrastructure est mixte (Linux, containers, pas de Windows Server), FreeRADIUS est plus adapté.

Troubleshooting : Mode Debug et Logs

# Mode debug (arrêter le service FreeRADIUS avant)
systemctl stop freeradius
freeradius -X

# Dans un autre terminal, testez
radtest utilisateur motdepasse 127.0.0.1 0 testing123

# Filtrer les logs pour l'authentification spécifique
freeradius -X 2>&1 | grep -E "Access|ERROR|LDAP|mschapv2"

# Logs en production
tail -f /var/log/freeradius/radius.log

# Test LDAP debug
ldapsearch -H ldap://192.168.1.100 
  -D "svc_radius@domain.local" 
  -w password 
  -d 1 
  -b "DC=domain,DC=local" 
  "(sAMAccountName=testuser)"

Erreurs courantes et solutions :

• rlm_ldap: Bind as user failed : credentials du compte de service incorrects, ou compte lockout
• TLS Alert : problème de certificat — vérifiez la date d'expiration et la chaîne de confiance
• Access-Reject: rlm_mschapv2: AD refuses LAN Manager : désactivez LM hashes dans les politiques AD (Security Options → Network Security: Do not store LAN Manager hash)

Questions fréquentes sur FreeRADIUS et 802.1X