“Mettiamo 802.1X” è facile da dire, meno da fare bene. Tra certificati, supplicant, dynamic VLAN e Active Directory ci sono dieci punti dove la cosa si rompe. Questa è la sequenza che usiamo nei progetti reali con FreeRADIUS 3.x — niente fuffa, solo i passaggi che servono.
Lo stack tipico in un cliente medio
| Componente | Ruolo | Esempio |
|---|---|---|
| Authenticator | AP o switch che parla RADIUS | Cisco, UniFi, Aruba, MikroTik |
| Authentication server | RADIUS che valida le credenziali | FreeRADIUS 3.x su Ubuntu LTS |
| Identity store | Dove vivono utenti/macchine | Active Directory, LDAP, file users |
| PKI | Emette certificati server (e client per EAP-TLS) | AD CS, smallstep, OpenSSL |
| Supplicant | Client lato endpoint | Windows 10/11, macOS, iOS, Android, intune |
EAP-TLS o PEAP-MSCHAPv2: scegli prima
PEAP-MSCHAPv2 è ancora il default in molti deployment AD: l’utente inserisce username e password di dominio, il tunnel TLS protegge lo scambio. Veloce da rolloutare, ma password riusabili e MSCHAPv2 ormai è considerato debole (rainbow table su NTLM hash).
EAP-TLS è certificate-based: nessuna password sul filo, mutual auth, l’utente non può “leggere e digitare” la sua credenziale altrove. È quello che consigliamo praticamente sempre nel 2026, soprattutto se hai già una PKI o usi Intune/Jamf per distribuire certificati.
Ibrido tipico: EAP-TLS per device managed, PEAP per BYOD legacy con guardrail di rotazione password.
I 7 passaggi reali con FreeRADIUS
1. Installazione e baseline
Su Ubuntu Server LTS:
sudo apt install freeradius freeradius-utils freeradius-ldap
sudo systemctl stop freeradius
sudo freeradius -X # debug mode, da usare TANTOLavora sempre in freeradius -X durante il setup: vedi ogni richiesta, ogni decisione, ogni errore di certificato. Senza, perdi giornate.
2. Certificato server fatto bene
Il dolore più frequente è il certificato server EAP. Requisiti minimi 2026:
- Emesso da una CA che il supplicant fida (tipicamente AD CS interna, distribuita via GPO o MDM)
- EKU: Server Authentication (1.3.6.1.5.5.7.3.1)
- Subject Alternative Name con FQDN del RADIUS
- Chiave RSA 2048 minimo, meglio 3072 o ECDSA P-256
- Validità ragionevole (1-2 anni), con rotation pianificata
Mettilo in /etc/freeradius/3.0/certs/ e referenzialo in mods-available/eap.
3. Integrazione Active Directory
Due strade. Per PEAP-MSCHAPv2 serve ntlm_auth via Samba/winbind: FreeRADIUS chiama winbind che parla con AD. Setup classico ma fragile su domain controller in failover.
Per EAP-TLS non ti serve nessun lookup AD per l’auth (il certificato è la prova). AD ti serve solo per autorizzazione: leggi il CN del certificato, mappi a un gruppo, decidi VLAN. Più pulito, meno dipendenze.
4. Dynamic VLAN assignment
Il bello di 802.1X è poter mettere device diversi su VLAN diverse senza riconfigurare lo switch. Il RADIUS risponde con questi attributi:
Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-Id = "42"In FreeRADIUS lo metti in users o in un policy file basato su gruppo AD/LDAP:
DEFAULT Ldap-Group == "Wifi-Staff"
Tunnel-Type := VLAN,
Tunnel-Medium-Type := IEEE-802,
Tunnel-Private-Group-Id := "42"Sullo switch/AP verifica che il dynamic VLAN sia abilitato e che la VLAN esista già — il RADIUS non la crea.
5. MAC Authentication Bypass per IoT
Stampanti, telecamere, badge reader: spesso non parlano 802.1X. Configura MAB sull’authenticator e su FreeRADIUS un check sul MAC come username/password:
aa:bb:cc:dd:ee:ff Cleartext-Password := "aa:bb:cc:dd:ee:ff"
Tunnel-Type := VLAN,
Tunnel-Private-Group-Id := "100"Sì, è autenticazione “debole”. Il punto è isolarli in una VLAN IoT con ACL strette, non fingere che sia sicuro.
6. Logging e accounting
Abilita accounting verso un file o, meglio, un DB SQL. Ti serve per:
- audit GDPR (chi era online, quando, da quale MAC)
- troubleshooting roaming
- compliance NIS2 (tracciabilità accessi)
Conserva i log per il periodo previsto dalla tua data retention policy.
7. Alta disponibilità
Un solo RADIUS = single point of failure dell’intera rete wireless aziendale. Configura sempre due nodi in failover sull’authenticator. FreeRADIUS può girare attivo/attivo se l’identity store è coerente (AD lo è, file flat no).
Errori che fanno perdere ore
- Certificato server non fidato sul client: Windows mostra “impossibile connettersi” senza spiegare nulla. Distribuisci la CA root via GPO/Intune prima di abilitare 802.1X.
- Validate server certificate disabilitato sui client: classico workaround che diventa permanente, abbassa la sicurezza e regala MITM ad attaccanti con un rogue RADIUS.
- Shared secret RADIUS uguale ovunque: usane uno diverso per ogni authenticator, gestiscili in un secret manager.
- DHCP non pronto per la nuova VLAN: il client autentica, finisce in VLAN 42, e non prende IP. Test sempre end-to-end.
- TLS 1.0/1.1 ancora attivi in
eap: forza TLS 1.2 minimo, meglio 1.3 dove supportato.
In sintesi
FreeRADIUS è ancora oggi lo strumento più flessibile per 802.1X enterprise: open source, integrabile, scriptabile. La differenza tra un deployment che dura anni e uno che diventa un incubo sta nei dettagli — certificati, supplicant config, VLAN routing, HA.
Nei nostri progetti reali partiamo sempre da EAP-TLS dove possibile e teniamo PEAP solo come ponte. Se stai pianificando un rollout 802.1X, vuoi un audit su un setup esistente, o vuoi formare il team, parliamone dai contatti — e dai un’occhiata anche al nostro percorso pfSense/firewall, perché i due mondi si toccano più di quanto sembri.