Chi, nelle reti aziendali, vuole gestire seriamente quali endpoint possono operare su quali porte e SSID (identificatori di rete WLAN), non può prescindere da 1X Network Access Control. In pratica si intende quasi sempre IEEE 802.1X: controllo di accesso basato su porta, in cui uno switch o un access point (l Authenticator) inoltra le credenziali di un client (il Supplicant) a un RADIUS-Server (backend AAA per Authentication, Authorization, Accounting). Il risultato non è solo «dentro o fuori», ma può innescare assegnazioni come VLAN, ACL o quarantena.
Il problema: 802.1X è meno una funzionalità che un modello operativo. Raramente fallisce per una casella non spuntata nello switch; piuttosto per certificati, identità non uniformi, dispositivi speciali (stampanti, IoT), timer errati, policy poco chiare e un rollout senza percorso di rollback. Questo contributo vi guida in modo pratico attraverso il RADIUS-Setup, il design delle NAC-Policy e un piano di rollout che funzioni realisticamente in reti eterogenee (LAN/WLAN, Windows/macOS/Linux, gestite/non gestite).
Perché 802.1X/NAC: cosa si ottiene operativamente (e cosa no)
802.1X affronta un problema centrale delle reti classiche di Layer 2: una porta attiva è spesso «di fiducia» finché il link è attivo. Questo non si adatta più a BYOD, postazioni di lavoro variabili, ritorni dal lavoro da remoto, reti guest e alla pressione di separare i segmenti in modo netto. Con 802.1X si impone che un dispositivo dimostri un’identità prima di ottenere l’accesso alla rete.
Importante per la gestione delle aspettative: 802.1X non è una completa endpoint-security. Non sostituisce né il patch-management né l’EDR. E non è una panacea contro dispositivi compromessi. Ma crea una base tecnica solida per standardizzare gli accessi: «Chi sei, a quale tipo corrispondi, e quale profilo si applica a te?» Proprio questa mappatura è spesso la leva decisiva in esercizio e in audit.
Fondamenti architetturali: ruoli e protocolli senza ambiguità
In 802.1X interagiscono tre ruoli:
- Supplicant: client sul dispositivo finale (p.es. Windows Wired AutoConfig, macOS 802.1X, wpa_supplicant su Linux).
- Authenticator: porta dello switch o access point WLAN che inizialmente blocca il traffico e gestisce EAPOL (EAP over LAN) o EAP over WLAN.
- Authentication Server: server RADIUS che termina o elabora ulteriormente EAP (Extensible Authentication Protocol) e restituisce decisioni.
Metodi EAP importanti nella pratica operativa del NAC:
- EAP-TLS: autenticazione basata su certificato (certificato client). Molto robusto, ma esigente in termini di PKI e gestione del ciclo di vita.
- PEAP: tunnel (TLS) più metodo password interno (tipicamente MSCHAPv2). Più facile da distribuire, ma più vulnerabile a problemi legati a password e phishing; inoltre dipende da un trust accurato del certificato server.
Importante per gli amministratori: sulla linea non circola una „password RADIUS“, bensì l’EAP viene trasportato tra il Supplicant e il RADIUS tramite l’Authenticator. Se qualcosa fallisce, dovete sempre determinare: si interrompe sul client (Supplicant), sull’Authenticator (Switch/AP) o sul RADIUS/servizio di directory (p.es. AD/LDAP) e sulla sua catena di certificati?
Voraussetzungen vor dem ersten Paket: Inventar, Identitäten, PKI
Un avvio pulito vi risparmia settimane di troubleshooting. Chiarite in anticipo questi punti:
1) Gerätetypen und Sonderfälle inventarisieren
Elencate porte/reti e classi di endpoint: client gestiti, notebook per amministratori, telefoni VoIP, stampanti, sistemi per conferenze, telecamere, dispositivi di produzione, Access Points, thin client. È cruciale: chi può fare 802.1X come Supplicant? Chi necessita di MAB? Chi ha MAC variabili (randomization) e dunque non è idoneo per MAB?
2) Identitätsquelle festlegen: Benutzer, Geräte oder beides
Per la LAN la scelta tra „User-Auth“ e „Machine-Auth“ è centrale. In Windows-ambienti il Computer-Zertifikat (EAP-TLS) per la condizione „il dispositivo appartiene al dominio“ è spesso più stabile della combinazione utente/password, perché l’autenticazione può avvenire prima del logon dell’utente. Per il WLAN spesso servono entrambi (p.es. WLAN per il personale con certificato utente, WLAN per dispositivi con certificato macchina).
3) PKI-Entscheidung: Wer stellt Zertifikate aus und wie wird rotiert?
L’efficacia di EAP-TLS dipende dai certificati: CA (Certificate Authority), template/profili, validità, revoca (CRL/OCSP), distribuzione delle CA root/intermediate e rinnovo. Trappola tipica: il client non si fida del certificato del server RADIUS perché mancano certificati intermedi o vengono usati EKU (Extended Key Usage) errati.
Se adottate PEAP: anche in quel caso è necessario un Server-Zertifikat sul RADIUS, e i client devono verificarne correttamente la fiducia. Altrimenti il „tunnel sicuro“ diventa rapidamente una sicurezza basata su un semplice clic.
RADIUS-Setup: Redundanz, Ports, Zertifikate, Logging
Un RADIUS produttivo non è solo un servizio su singolo server. Piano minimo: almeno due istanze (HA tramite load balancer o server duplicati configurati nei dispositivi di rete), policy coerenti e logging accurato.
Netzwerkseitige Basis: Erreichbarkeit und Shared Secrets
RADIUS usa tipicamente UDP/1812 (Auth) e UDP/1813 (Accounting). In ambienti più datati si incontrano UDP/1645/1646. Controllate firewall e routing, soprattutto se Access Layer e AAA-Server sono in zone separate. Per ogni Authenticator (Switch/AP/Controller) esiste un Shared Secret (chiave condivisa) che non deve essere indovinabile e deve poter essere ruotato.
Un test di connettività minimale (senza client 802.1X) è spesso utile. Un esempio con radclient (strumenti FreeRADIUS) contro un utente di test può mostrare se RADIUS risponde fondamentalmente:
# Beispiel: Access-Request an RADIUS schicken (Test-User/Passwort nur für Lab)
# radclient erwartet hier PAP/CHAP-ähnliche Attribute, nicht EAP-TLS.
echo "User-Name=testuser,User-Password=testpass" |
radclient -x 10.10.10.20 auth SuperSecretSharedKeyImportante: questo non è un test EAP. È un „RADIUS è operativo e il segreto condiviso è corretto?“. Per EAP-TLS/PEAP servono test reali con supplicant o strumenti specifici per testare EAP.
Certificati sul RADIUS: catena, EKU, nome
Il server RADIUS deve presentare un certificato server che i client possano validare. Verificare:
- Subject/SAN: Il nome DNS che i client si aspettano deve essere presente nel certificato (SAN: Subject Alternative Name).
- EKU: „Server Authentication“ deve essere impostato.
- Catena dei certificati: gli intermedi devono essere forniti correttamente, altrimenti molti client falliranno silenziosamente.
- CRL/OCSP: se i client forzano il controllo di revoca, l’accessibilità delle liste di revoca deve essere garantita (anche in fase di pre-logon).
Accounting e telemetria: senza log non c’è operatività
Il RADIUS-Accounting fornisce informazioni su avvii/termini di sessione e può aiutare nelle analisi NAC: quali porte/SSID vengono utilizzate e come, chi si discosta dalle regole? Anche se non usate l’Accounting per la fatturazione, è prezioso per l’operatività, la risoluzione dei problemi e l’audit.
Pianificate le sorgenti di log in modo da poter correlare gli eventi:
- RADIUS-Logs (Accept/Reject, Reason, EAP-State)
- Switch/AP-Logs (Dot1x, AAA, Port-Events)
- Client-Logs (Windows visualizzatore eventi, macOS console, wpa_supplicant)
Progettare la politica NAC: meno „tutto chiuso“, più percorsi controllati
Una politica NAC è la regola operativa che determina in quale profilo obiettivo ricade un endpoint. Il classico è: „Employee VLAN“ o „Guest VLAN“. In pratica servono più sfumature per mantenere stabile il rollout e l’operatività.
Componenti di policy che si sono dimostrati efficaci
- Pre-Auth / Fail-Open / Fail-Closed: comportamento quando RADIUS non è raggiungibile. Fail-Open può salvare il business, ma è un rischio per la sicurezza; Fail-Closed è rigoroso, ma in caso di guasto AAA può disabilitare largamente gli accessi. In molti ambienti il miglior compromesso è un fail-open controllato con profilo ridotto (es. solo per remediation/management).
- Quarantena/Remediation: VLAN o ACL che permettono solo servizi di aggiornamento/management, DNS, DHCP e, se necessario, proxy. Obiettivo: rendere i dispositivi „riparabili“ invece di bloccarli.
- Ruoli per tipo di dispositivo: Managed Client, Unmanaged Device, Voice, Printer, IoT, Admin-Workstation.
- Guest/BYOD separati: proprie SSID/porte, spazi di indirizzamento chiaramente separati, privilegi ridotti.
Tecnicamente questo si realizza spesso tramite attributi RADIUS (es. VLAN-ID, Tunnel-Private-Group-ID, Filter-ID, dACL). Quali attributi la vostra infrastruttura supporta dipende dal vendor. Fondamentale è il principio operativo: profili chiari e testabili.
EAP-TLS vs. PEAP nel contesto della policy
EAP-TLS è di norma la scelta migliore per dispositivi gestiti, perché fornisce un’identità dispositivo forte. Lo svantaggio è il carico sulla PKI: enrollment, rinnovo, revoca, offboarding. PEAP è spesso il punto di partenza quando serve rapidamente un’autenticazione basata su utente, ma genera più casi di supporto („avviso certificato“, cambio password, lockout) ed è più vulnerabile se i client non verificano rigorosamente l’identità del server.
Un ibrido frequente nelle aziende: LAN via EAP-TLS (Machine), WLAN per i collaboratori via EAP-TLS (User o Device), dispositivi legacy/particolari tramite MAB in una VLAN RESTrittiva.
Lato switch e WLAN: parametri tipici che determinano la stabilità
Molti progetti 802.1X non falliscono perché „lo switch supporta 802.1X“, ma per timer e priorità. PRESTate attenzione ai seguenti punti:
Ruoli di porta e scenari multi-dispositivo (PC + telefono)
Alla postazione spesso un telefono VoIP è collegato alla porta e il PC è collegato al telefono. Per questo serve un modello che possa rappresentare due identità sulla stessa porta. Parole chiave sono „Multi-Auth“ o „Multi-Domain Authentication“ (Voice/ Data separati). Se lo ignorate, si autenticherà solo uno dei dispositivi e l’altro finirà nel profilo sbagliato.
Timer e tentativi
Intervalli di ri-autenticazione troppo aggressivi o timeout troppo brevi provocano „flapping“: la porta viene ri-autenticata periodicamente, le connessioni si interrompono, Teams/VoIP ne risente. Intervalli troppo lunghi rallentano l’offboarding. Partite con impostazioni conservative e ottimizzate in seguito.
Definire chiaramente i fallback: MAB e Guest VLAN
Se consentite MAB come eccezione, lo switch deve assegnare priorità chiare: prima 802.1X, poi MAB (o viceversa, a seconda della classe di dispositivo). Una „Guest VLAN“ per i fallimenti di autenticazione può rendere il rollout più sicuro, ma diventa una via d’accesso se impostata troppo permissivamente. La Guest/Fail-VLAN dovrebbe avere solo accessi minimi.
Piano di rollout: dal laboratorio attraverso il monitor-mode fino alla messa in applicazione
Un rollout è meno un’azione tecnica che una transizione controllata. Si è dimostrato efficace un approccio a più fasi che includa punti di misurazione e percorsi di rollback.
Fase 0: Lab e percorso di riferimento
Allestite un piccolo percorso di riferimento: 1–2 Switches/1 AP, un RADIUS-Cluster (oder zwei Instanzen), ein Windows-Client, ein macOS-Client, ein Linux-Client, plus ein Sondergerät (z. B. Drucker). Ziel ist nicht Vollständigkeit, sondern frühes Finden der harten Probleme: Zertifikatskette, Name, CRL-Erreichbarkeit, Policy-Entscheidungen, VLAN-Zuweisung.
Fase 1: visibilità senza applicazione (Monitor/Low Impact)
Se la vostra piattaforma lo permette: iniziate con „Monitor Mode“ o una configurazione che registra le autenticazioni ma non le blocca ancora. In alternativa: le porte RESTano aperte, ma Accounting und RADIUS-Requests laufen parallel (je nach Vendor). Questo vi fornisce dati: quali dispositivi potrebbero usare 802.1X e quali no, dove ci sono sorprese di MAC-Randomization, dove i dispositivi sono collegati dietro unmanaged Switches?
Fase 2: gruppo pilota con responsabilità ben definita
Selezionate un ambito con utenti in grado di supportare (IT, power user, una sede) e definite i criteri di successo:
- Login/sblocco stabile
- VPN/VDI/telefonia/stampa funzionano
- Nessuna interruzione «sporadica» dovuta a reauth
- Test di offboarding: revocare dispositivo/certificato e verificare il comportamento
Fase 3: Enforcement graduale per segmento
Rollout lungo confini naturali: edificio/piano/switch di accesso, SSID separati, poi aree core. Importante: non «tutte le porte insieme».
Implementate una gestione esplicita delle eccezioni: i dispositivi speciali devono essere registrati, classificati e inseriti in un profilo RESTrittivo prima dell’enforcement. Altrimenti i team inventeranno «workaround» (mini-switch, bridge WLAN) che alla fine sono più rischiosi della rete di partenza.
Checklist pratiche: cosa verificare prima, durante e dopo il cutover
Controllo pre-cutover (per blocco switch/AP)
- Ridondanza RADIUS configurata e testata (entrambe le istanze Accept)
- Shared Secrets documentati, ruotabili, non riutilizzati
- NTP sincronizzato (deriva di orario interrompe TLS e correlazione dei log)
- DHCP/DNS presenti nei profili Quarantine e Guest
- Verifica raggiungibilità CRL/OCSP dal contesto pre-logon (se rilevante)
- Scenario multi-dispositivo Voice/PC testato
- Accesso di emergenza: almeno una porta/SSID definita come break-glass (controllata fisicamente/amministrativamente)
Protocollo di cutover (adatto al runbook operativo)
- Stabilire la finestra di modifica e i canali di comunicazione (Ops/Netz/Sec/Service Desk)
- Attivare l’enforcement per il blocco definito
- Verifica live: nuove sessioni si autenticano, nessun flapping delle porte
- Campionamenti: Windows/macOS/Linux, telefono, stampante/IoT
- Raggruppare i log RADIUS per motivi di reject (prime le 3 cause)
Post-Cutover: stabilità e igiene
- Ridurre le eccezioni: inventariare i dispositivi MAB e, se necessario, migrarli
- Ottimizzare gli intervalli di reauth e i timer quando i dati sono stabili
- Stabilire reporting: auth rifiutate, nuovi OUI/MAC-vendor, classi di dispositivi sconosciute
Troubleshooting: i casi di errore più frequenti e come isolarli rapidamente
I guasti 802.1X spesso appaiono uguali («nessuna rete»), ma hanno cause molto diverse. Lavorate in modo strutturato dal basso verso l’alto: link/porta, avvio EAP, request RADIUS, verifica del certificato, decisione della policy, applicazione VLAN/ACL.
Caso d’errore 1: il client non riceve IP (DHCP) dopo login riuscito
Le cause spesso non sono «802.1X rotto», ma VLAN errato, DHCP non presente nel VLAN di destinazione, o mancanza di DHCP-Relay/Helper. Verificate sullo switch: in quale VLAN si trova la porta dopo l’Accept? E: il DHCP è permesso (con dACL/Filter-IDs)?
Caso d’errore 2: «Certificato non attendibile» o avvisi sporadici
Tipico con PEAP e anche per il server-trust EAP-TLS: nome server errato, certificati intermedi mancanti, Root-CA obsoleta sui client, o CRL/OCSP non raggiungibili. Se gli utenti possono chiudere gli avvisi, è un problema di design. L’obiettivo deve essere: validazione rigorosa del server senza prompt.
Caso d’errore 3: telefonia instabile dopo l’introduzione
Spesso dipende da metodo di porta errato (assenza di Multi-Auth/Multi-Domain), priorizzazione sbagliata (MAB/802.1X) o da reauth troppo aggressiva. I dispositivi VoIP spesso necessitano di un profilo dedicato (Voice VLAN, marcature QoS) e implementano 802.1X in modo differente.
Caso d’errore 4: stampante/IoT si disconnette nonostante MAB sia attivato
Verifichi la MAC-Randomization (su alcuni dispositivi/adattatori), i limiti di Port-Security (numero massimo di MAC) e se il dispositivo è collegato dietro un piccolo switch. MAB vede allora la MAC dell’uplink, non del dispositivo finale. In questi casi è necessario avere dispositivi con supporto 802.1X, porte separate o una strategia di connessione diversa.
Caso d’errore 5: tutto funziona nella fase pilota, ma durante il rollout si interrompe in aree specifiche
Questo indica spesso template di switch incoerenti, diversi livelli di firmware, parametri AAA differenti o un problema di routing/firewall verso i server RADIUS. Una gestione delle configurazioni per dispositivi di rete basata sui diff si ripaga immediatamente.
Snippet di configurazione esemplificativi: cosa dovRESTe documentare e versionare
La configurazione concreta di switch/AP dipende dal produttore. Per l’esercizio e il controllo delle modifiche è però fondamentale che versioniate correttamente i vostri parametri: server RADIUS, gestione dei secret, ordine di autenticazione, mapping VLAN/ACL, timer, failover. Di seguito sono riportati esempi volutamente generici come modello di documentazione.
RADIUS-Client-Definition (Beispiel INI-ähnlich)
; Dokumentationsvorlage: RADIUS-Clients pro Authenticator
; Nicht 1:1 für ein bestimmtes Produkt gedacht.
[client:access-switch-12]
ip = 10.20.30.12
secret = <rotierbares_shared_secret>
ports = 1812,1813
coa_port = 3799
notes = Access-Layer, Etage 3, Ports 1-48Policy-Mapping (Beispiel YAML für interne Doku/Automation)
# Beispiel: Rollen auf Netzprofile abbilden (für Doku, IaC oder NAC-Policy-Design)
roles:
managed_workstation:
auth_method: eap-tls
network_profile:
vlan: 120
RESTrictions: standard
managed_admin:
auth_method: eap-tls
network_profile:
vlan: 130
RESTrictions: privileged
unmanaged_printer:
auth_method: mab
network_profile:
vlan: 220
RESTrictions: limited
guest:
auth_method: captive_or_psk
network_profile:
vlan: 300
RESTrictions: internet_only
fallbacks:
radius_unreachable:
behavior: controlled_fail_open
network_profile:
vlan: 210
RESTrictions: remediation_onlyComandi di controllo per la risoluzione dei problemi (Linux-Client, contesto EAP/WLAN)
# Link und Treiberzustand
ip link
nmcli device status
# WLAN-Details (wenn zutreffend)
iw dev
# Logs (systemd-basierte Distributionen)
journalctl -u NetworkManager --since "-30 min" | tail -n 200Questi blocchi non sostituiscono la documentazione del vendor, ma aiutano a gestire il vostro progetto NAC in modo riproducibile: cosa è „Standard“, cosa è eccezione e quali fallback sono stati impostati consapevolmente?
Strategia di rollback che funzioni nella pratica, non solo sulla carta
Un rollback per 802.1X non è un singolo interruttore se avete già modificato VLAN/ACL e profili. Definite quindi una strategia di ripiego su tre livelli:
1) Ripiego tecnico per segmento
- Template di porte switch preparati: ‚Enforcement‘ e ‚Open/Legacy‘
- Confini di ambito chiari: quale blocco di switch/AP può essere isolato per il rollback?
- Break-Glass-Port(s): protetti fisicamente, documentati, testati
2) Ripiego AAA (interruzione RADIUS)
- Usare attivamente la ridondanza RADIUS (non solo installarla)
- Monitoraggio della raggiungibilità dei server RADIUS e dei picchi di reject
- Decisione definita di fail-open/fail-closed per classe di rete (Office vs. Produzione)
3) Ripiego organizzativo
- Runbook del Service Desk: quali domande, quali log, quali azioni standard?
Il punto centrale è: il rollback deve essere esercitato. Un percorso di ritorno non testato è in caso di incidente inutile.
Sicurezza e operatività: hardening, monitoring, cicli di vita
Dopo il rollout inizia l’effettiva operatività. Questi temi dovrebbero entrare nei vostri processi standard:
- Ciclo di vita dei certificati: rinnovo automatico, report di scadenza, processi di revoca in caso di perdita di dispositivi.
- Controllo delle modifiche alle policy: trattare le modifiche a ruoli/VLAN come regole firewall (revisione, test, rollback).
- Registrazione/Audit: classificare i motivi di reject, segnalare pattern anomali (es. molti eventi MAB su una porta).
- Ridurre il debito tecnico: ridurre le eccezioni MAB, sostituire i dispositivi obsoleti, eliminare gli switch „ombra“.
Conclusione: 1X Network Access Control è un progetto che si consolida con l’operatività
802.1X e RADIUS sono tecnologie mature, ma il loro successo dipende dall’interazione tra identità, certificati, chiare policy NAC e un rollout che controlla le eccezioni invece di sopprimerle. Se iniziate con una fase di monitoraggio, separate i profili in modo netto (Standard, Quarantena, dispositivi speciali), considerate il logging seriamente fin dall’inizio e definite una vera strategia di rollback, 1X Network Access Control non diventerà un cantiere permanente, ma una base solida per la segmentazione, modelli di accesso vicini al Zero Trust e decisioni di rete auditabili.