Vai al contenuto principale
Italiano

Configurazione di SCEP per l'autenticazione sicura WiFi e BYOD nel settore dell'istruzione superiore

Questa guida tecnica fornisce ad architetti di rete e responsabili IT un modello neutrale rispetto ai vendor per implementare la registrazione dei certificati basata su SCEP per mettere in sicurezza il WiFi nell'istruzione superiore. Descrive in dettaglio la transizione dall'autenticazione vulnerabile basata su password a EAP-TLS, concentrandosi sull'onboarding BYOD scalabile e sull'integrazione MDM.

📖 5 minuti di lettura📝 1,242 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 8 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
Benvenuti al Purple Technical Briefing. Sono il vostro ospite e oggi parleremo di un argomento ricorrente nel settore IT dell'istruzione superiore: l'implementazione di SCEP per l'autenticazione sicura di BYOD e WiFi. Se utilizzate PEAP-MSCHAPv2 sulla rete del vostro campus, questo briefing vi riguarda direttamente. E se state già pianificando il passaggio all'autenticazione basata su certificati, vi forniremo l'architettura, le insidie e la sequenza di implementazione per arrivarci. Partiamo dal problema. Le università sono, per loro natura, ambienti aperti. A settembre gli studenti arrivano con due, tre, a volte cinque dispositivi personali. Si aspettano di connettersi immediatamente, in modo sicuro e senza dover contattare l'helpdesk. La realtà per la maggior parte degli istituti è una coda dell'helpdesk che raggiunge i duemila ticket entro quarantotto ore dall'inizio del trimestre. Questo non è un problema di personale. È un problema di architettura. La causa principale è quasi sempre la stessa: l'autenticazione WiFi basata su password. Quando si utilizza WPA2-Enterprise con PEAP e MSCHAPv2, si chiede agli studenti di configurare manualmente le impostazioni 802.1X su ogni dispositivo. Un'impostazione errata e diventano vulnerabili a un attacco man-in-the-middle. Peggio ancora, quando l'università impone il ripristino della password ogni novanta giorni, ogni dispositivo nel campus perde contemporaneamente l'accesso al WiFi. Questo è un disastro prevedibile e prevenibile. La risposta è l'autenticazione basata su certificati tramite EAP-TLS, e il meccanismo che la rende scalabile è SCEP: il Simple Certificate Enrollment Protocol. SCEP è stato formalizzato dall'IETF nell'RFC 8894 nel 2020, sebbene sia in uso fin dai primi anni 2000. Automatizza il processo di richiesta e installazione dei certificati digitali X.509 sui dispositivi, senza richiedere alcun intervento IT manuale per singolo dispositivo. Ecco come funziona in sintesi. La vostra piattaforma MDM, che si tratti di Microsoft Intune o Jamf, invia un payload SCEP a ciascun dispositivo registrato. Tale payload contiene due elementi: l'URL del gateway SCEP e una password di verifica (challenge password) condivisa. Il dispositivo genera una Certificate Signing Request, la invia al gateway SCEP, che convalida la password di verifica e inoltra la richiesta alla vostra Certificate Authority. La CA firma il certificato e lo restituisce al dispositivo. Da quel momento in poi, il dispositivo si autentica alla rete WiFi utilizzando EAP-TLS: il certificato dimostra l'identità del dispositivo al server RADIUS, mentre il certificato del server RADIUS dimostra l'identità della rete al dispositivo. Autenticazione reciproca. Nessuna password scambiata via etere. Questo elemento di autenticazione reciproca è fondamentale. Con PEAP, uno studente che si connette a un access point canaglia che trasmette il vostro SSID cederà volentieri le proprie credenziali. Con EAP-TLS, il dispositivo verifica il certificato del server RADIUS prima di procedere. Se non corrisponde alla CA attendibile, la connessione si interrompe silenziosamente. In questo modo avrete eliminato l'intera classe di attacchi evil twin. Ora parliamo di architettura. Un'implementazione SCEP in produzione per un'università prevede sei componenti principali. In primo luogo, l'identity provider: Microsoft Entra ID, Okta o Google Workspace. In secondo luogo, la piattaforma MDM: Intune per Windows e Android, Jamf per macOS e iOS. In terzo luogo, la Certificate Authority: Microsoft Active Directory Certificate Services on-premises oppure una PKI cloud. In quarto luogo, il gateway SCEP: l'endpoint HTTP che riceve le richieste di certificato. In quinto luogo, il server RADIUS per l'autenticazione. In sesto luogo, l'access layer: access point Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist configurati per 802.1X. La catena di attendibilità funziona così. La CA emette un certificato root. Tale root viene distribuito a ogni dispositivo tramite MDM, stabilendo la relazione di attendibilità. La CA emette quindi i certificati client per i dispositivi tramite SCEP. Quando un dispositivo si connette, presenta il proprio certificato client al server RADIUS, e il server RADIUS presenta il proprio certificato server al dispositivo. Entrambe le parti effettuano la verifica rispetto alla root attendibile. L'accesso viene consentito o negato in base alla validità del certificato, non a una password. Vediamo ora la sequenza di implementazione. Questo è l'ordine corretto. Fase uno: pulizia dell'identity store. Verifica che Active Directory o Entra ID presentino gruppi ben definiti per studenti, personale e ospiti. Le policy dei certificati e le assegnazioni VLAN saranno collegate a questi gruppi. Fase due: implementazione della Certificate Authority. Se utilizzi Microsoft ADCS, configura una gerarchia a due livelli: una CA root offline e una CA di emissione online. La CA root dovrebbe essere isolata dopo la configurazione iniziale. Fase tre: configurazione del gateway SCEP. Questo è l'endpoint HTTP verso cui l'MDM indirizzerà i dispositivi. Assicurati che sia accessibile dal segmento di rete in cui i dispositivi eseguono la registrazione iniziale, in genere l'SSID di onboarding. Fase quattro: configurazione del server RADIUS. Importa il certificato della CA di emissione come CA attendibile. Configura EAP-TLS como metodo di autenticazione. Imposta gli attributi di ritorno VLAN in modo che RADIUS possa assegnare dinamicamente gli studenti al segmento di rete corretto. Fase cinque: configurazione dei profili MDM. In Intune, crea prima un profilo Certificato attendibile, poi un profilo Certificato SCEP e infine un profilo WiFi che faccia riferimento al certificato SCEP. Distribuisci questi profili esattamente in questo ordine. Ciascuno di essi dipende dalla presenza di quello precedente. Fase sei: configurazione degli access point. Su Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist, configura il tuo SSID sicuro per WPA2-Enterprise o WPA3-Enterprise. Imposta il timeout RADIUS ad almeno cinque secondi per gestire la latenza di convalida dei certificati durante i picchi di onboarding. Ora, le potenziali insidie. Ho visto questi errori compromettere ripetutamente le implementazioni. Il primo consiste nel distribuire i profili MDM nell'ordine errato. Se il profilo WiFi arriva sul dispositivo prima del profilo del certificato SCEP, il dispositivo non disporrà di alcun certificato con cui autenticarsi. Di conseguenza, la connessione fallirà e l'utente contatterà l'assistenza. Il secondo errore comune è dimenticare i dispositivi BYOD. Intune e Jamf gestiscono la flotta di proprietà dell'istituto. Ma i dispositivi personali degli studenti non sono registrati nel vostro MDM. Per questi, serve un portale di onboarding self-service. Lo studente si autentica tramite Single Sign-On utilizzando le proprie credenziali universitarie, e il portale utilizza SCEP per emettere il certificato. La piattaforma di Purple integra questo flusso di onboarding direttamente nell'esperienza del Captive Portal, così gli studenti completano la registrazione in meno di due minuti senza alcun intervento dell'IT. Il terzo errore comune sono i timeout di RADIUS durante i picchi di onboarding. Eseguite test di carico sulla vostra infrastruttura RADIUS prima di settembre, non durante. Implementate il bilanciamento del carico su almeno due nodi RADIUS. Il quarto errore comune è la revoca dei certificati. Quando uno studente se ne va, o un dispositivo viene smarrito o rubato, è necessario revocare immediatamente il certificato. Assicuratevi che la vostra CA pubblichi una Certificate Revocation List e che il server RADIUS la controlli a ogni autenticazione. Passiamo ora a una rapida sessione di domande e risposte sui quesiti che sentiamo più spesso. Il SCEP può funzionare senza un MDM? Tecnicamente sì, ma praticamente no. Senza un MDM che distribuisca il payload SCEP e il profilo WiFi, si torna alla configurazione manuale del dispositivo. Quanto dovrebbe durare la validità di un certificato? Per i dispositivi degli studenti, lo standard è da uno a due anni. Abbastanza a lungo da superare l'anno accademico senza problemi di rinnovo, abbastanza breve da limitare i rischi se un certificato viene compromesso. Cosa fare con i dispositivi IoT che non supportano lo standard 802.1X? Utilizzate il MAC Authentication Bypass con un portale di registrazione dei dispositivi self-service. Gli studenti registrano l'indirizzo MAC della propria console di gioco o smart TV, e il sistema NAC lo inserisce nella VLAN corretta. Funziona con eduroam? Sì. EAP-TLS è pienamente supportato dalla federazione eduroam. I certificati emessi dalla CA del campus possono autenticare gli studenti su eduroam in qualsiasi istituto aderente nel mondo. Per concludere, ecco le tre decisioni che definiscono un deployment SCEP di successo. Primo: scegliete l'architettura della CA prima di ogni altra cosa. ADCS on-premises offre un controllo totale. La PKI cloud offre semplicità operativa. Una scelta errata in questa fase costa mesi di lavoro extra. Secondo: automatizzate l'onboarding BYOD fin dal primo giorno. Non presupponete che gli studenti configurino i propri dispositivi personali manualmente. Non lo faranno. Create il portale self-service prima dell'inizio delle lezioni. Terzo: testate la capacità di carico di RADIUS prima di settembre. Un'interruzione di RADIUS il primo giorno di lezione è del tutto prevenibile. La piattaforma di Purple supporta tutti e tre questi aspetti: integrazione PKI cloud overlay, onboarding BYOD self-service tramite il nostro Captive Portal e un'infrastruttura RADIUS testata su ottantamila location attive con un uptime del novantanove virgola nove nove nove percento. Grazie per aver partecipato al Technical Briefing di Purple. Per ulteriori informazioni, visitate purple.ai.

header_image.png

Sintesi Esecutiva

Per i team IT dell'istruzione superiore, l'inizio dell'anno accademico porta con sé uno stress test immediato. Migliaia di studenti arrivano nel campus con molteplici dispositivi non gestiti, aspettandosi una connettività istantanea e sicura. Quando le università si affidano all'autenticazione basata su password come PEAP-MSCHAPv2, questo afflusso si traduce prevedibilmente in enormi code all'helpdesk, errori di configurazione e gravi vulnerabilità al furto di credenziali tramite access point evil twin.

La soluzione architetturale a questa sfida di scala e sicurezza è l'autenticazione basata su certificati che utilizza EAP-TLS. Per rendere fattibile l'implementazione dei certificati su decine di migliaia di endpoint, le università devono implementare il Simple Certificate Enrollment Protocol (SCEP). SCEP automatizza l'invio di certificati digitali sia ai dispositivi gestiti tramite MDM sia ai dispositivi personali degli studenti tramite portali di onboarding self-service. Questa guida descrive in dettaglio i requisiti tecnici per l'implementazione di SCEP in un ambiente di istruzione superiore, fornendo passaggi pratici per eliminare i ticket di helpdesk relativi alle password e proteggere il perimetro del campus.

L'Architettura dell'Iscrizione dei Certificati SCEP

Il passaggio a un Wi-Fi basato su certificati richiede un cambiamento fondamentale, dalla convalida della conoscenza dell'utente (una password) alla convalida dell'identità del dispositivo (un certificato). Il protocollo SCEP funge da ponte tra il livello di gestione dei dispositivi e la Public Key Infrastructure (PKI).

scep_architecture_diagram.png

Componenti Infrastrutturali Centrali

Un'implementazione SCEP pronta per la produzione richiede sei componenti integrati che lavorano in sequenza:

  1. Identity Provider (IdP): La directory autorevole (Microsoft Entra ID, Okta o Google Workspace) che verifica l'identità dell'utente prima dell'emissione del certificato.
  2. Mobile Device Management (MDM): Piattaforme come Microsoft Intune o Jamf che inviano il payload SCEP ai dispositivi di proprietà dell'istituto.
  3. Certificate Authority (CA): Il motore PKI che firma ed emette i certificati. Può trattarsi di un'implementazione Microsoft ADCS on-premises o di un overlay PKI cloud-native.
  4. SCEP Gateway: L'endpoint HTTP che riceve le Certificate Signing Requests (CSR) dai dispositivi, convalida la password di verifica e inoltra la richiesta alla CA.
  5. RADIUS Server: Il server di autenticazione che valuta il certificato client presentato rispetto alle policy di accesso alla rete durante lo scambio 802.1X EAP-TLS.
  6. Wireless Access Network: Gli access point fisici (Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist) configurati per imporre l'autenticazione 802.1X.

Il Flusso di Registrazione SCEP

Il processo di registrazione viene eseguito senza l'intervento dell'utente sui dispositivi gestiti. La piattaforma MDM distribuisce un profilo di configurazione contenente l'URL del gateway SCEP e una password challenge generata dinamicamente. Il dispositivo genera localmente una chiave privata e crea una richiesta CSR, che invia poi al gateway SCEP tramite HTTP.

Il gateway intercetta la richiesta e convalida la password challenge tramite le API MDM per confermare che il dispositivo sia autorizzato. Una volta verificata, il gateway inoltra la CSR alla CA. La CA firma il certificato e lo restituisce al dispositivo attraverso il gateway. La chiave privata non lascia mai l'endpoint, garantendo l'integrità crittografica.

Guida all'implementazione: una strategia di implementazione graduale

L'implementazione di SCEP richiede una sequenza precisa. Le dipendenze dei profili indicano che l'esecuzione di questi passaggi non in ordine provocherà errori di autenticazione.

Passaggio 1: Sincronizzazione della directory e criteri di gruppo

Prima di gestire i certificati, assicurati che il tuo archivio di identità sia pulito. Crea gruppi di sicurezza distinti per studenti, personale e docenti in Entra ID o Active Directory. Il server RADIUS utilizzerà queste appartenenze ai gruppi, incorporate come Subject Alternative Names (SAN) nei certificati, per assegnare dinamicamente i dispositivi alle VLAN corrette.

Passaggio 2: Configurazione della PKI e del gateway SCEP

Stabilisci la gerarchia della tua CA. Se crei un'infrastruttura on-premises, distribuisci una Root CA offline e una Issuing CA online. Per gli ambienti dell'istruzione superiore che desiderano ridurre l'impronta infrastrutturale, le soluzioni PKI cloud offrono semplicità operativa. Configura il gateway SCEP per comunicare con la CA ed esponi l'endpoint di registrazione al segmento di rete in cui i dispositivi si connetteranno inizialmente.

Passaggio 3: Integrazione del server RADIUS

Importa il certificato della Issuing CA nell'archivio dei certificati attendibili del server RADIUS. Configura il protocollo di autenticazione rigorosamente su EAP-TLS. Definisci criteri di rete che mappano gli attributi del certificato (come lo User Principal Name) a specifici attributi di ritorno VLAN, consentendo la micro-segmentazione in tutto il campus.

Passaggio 4: Sequenziamento del profilo MDM

Per i dispositivi di proprietà dell'istituto gestiti da Intune o Jamf, l'ordine di distribuzione del profilo è fondamentale. È necessario distribuire i profili esattamente in questa sequenza:

  1. Profilo certificato attendibile: distribuisce il certificato Root CA per stabilire la relazione di attendibilità.
  2. Profilo certificato SCEP: indirizza il dispositivo al gateway per ottenere il proprio certificato client.
  3. Profilo WiFi: configura l'SSID per utilizzare WPA3-Enterprise con EAP-TLS, facendo esplicito riferimento al certificato acquisito nel passaggio precedente.

Passaggio 5: Onboarding self-service BYOD

Gli studenti non installeranno manualmente i certificati sui propri dispositivi personali. È necessario fornire un percorso di onboarding automatizzato. Distribuisci un SSID aperto che limiti il traffico esclusivamente al Captive Portal e al gateway SCEP. Quando uno studente si connette, il portale richiede l'autenticazione tramite Single Sign-On utilizzando le credenziali universitarie. Una volta completata l'autenticazione, il portale distribuisce il payload SCEP sul dispositivo. Purple integra questo flusso di onboarding direttamente nell'esperienza del Captive Portal, consentendo agli studenti di completare la registrazione in meno di due minuti senza l'intervento dell'IT.

Best Practice e mitigazione dei rischi

Il passaggio a EAP-TLS elimina il furto di credenziali, ma introduce nuove considerazioni operative. Gli architetti di rete devono anticipare gli eventi legati alla scalabilità e al ciclo di vita.

scep_vs_password_comparison.png

Pianificazione della capacità RADIUS

Il sovraccarico computazionale della convalida dei certificati EAP-TLS è notevolmente superiore rispetto al controllo delle password PEAP. Durante la prima settimana di corsi, migliaia di dispositivi tenteranno di autenticarsi contemporaneamente. Un singolo nodo RADIUS esaurirà probabilmente le sue risorse e rifiuterà le richieste, provocando un blocco diffuso delle connessioni. È necessario implementare il bilanciamento del carico su più nodi RADIUS e aumentare il timeout di autenticazione sugli access point a un minimo di cinque secondi per gestire i picchi di latenza.

Gestione del ciclo di vita dei certificati

I certificati per i dispositivi degli studenti dovrebbero avere un periodo di validità compreso tra uno e due anni. Questa durata copre il ciclo accademico limitando l'esposizione in caso di compromissione del dispositivo. È fondamentale implementare un meccanismo di revoca affidabile. Quando uno studente si laurea o segnala lo smarrimento di un dispositivo, il certificato deve essere revocato immediatamente. Assicurati che la CA pubblichi una Certificate Revocation List (CRL) o utilizzi un risponditore Online Certificate Status Protocol (OCSP), e configura il server RADIUS in modo che controlli lo stato di revoca a ogni tentativo di autenticazione.

Gestione dei dispositivi IoT headless

Smart TV, console di gioco e stampanti wireless nelle residenze universitarie sono privi dei richiedenti nativi 802.1X necessari per la registrazione SCEP. Per questi dispositivi, implementa il MAC Authentication Bypass (MAB). Fornisci un portale di registrazione dei dispositivi self-service in cui gli studenti possono registrare gli indirizzi MAC del proprio hardware IoT. Il sistema Network Access Control (NAC) autenticherà quindi questi indirizzi registrati e li inserirà nella VLAN per studenti appropriata.

Ascolta il briefing tecnico

Per un approfondimento sull'architettura e sugli scenari di implementazione reali, ascolta il nostro podcast di briefing tecnico di 10 minuti.

ROI e impatto aziendale

Il business case per l'implementazione di SCEP nell'istruzione superiore si fonda su due pilastri: la postura di sicurezza e l'efficienza operativa.

Dal punto di vista della sicurezza, EAP-TLS offre un'autenticazione reciproca. Il dispositivo verifica il certificato del server RADIUS prima di trasmettere qualsiasi dato, mitigando completamente il rischio che access point "evil twin" sottraggano credenziali. Questa architettura si allinea con i principi zero-trust, garantendo che solo i dispositivi verificati crittograficamente accedano alla rete del campus.

Dal punto di vista operativo, il disaccoppiamento dell'autenticazione WiFi dalle password di directory genera ritorni finanziari immediati. Quando un'università impone il ripristino della password ogni 90 giorni, gli studenti che utilizzano PEAP devono aggiornare le proprie credenziali su ogni dispositivo. Inevitabilmente, molti non ci riescono, provocando un'impennata di ticket di supporto. Con SCEP ed EAP-TLS, il certificato rimane valido indipendentemente dalle modifiche della password. Le università che implementano l'onboarding automatizzato dei certificati registrano costantemente una riduzione fino al 70% dei ticket di supporto relativi al WiFi nei periodi di punta, consentendo al personale IT di concentrarsi su iniziative strategiche piuttosto che sulla risoluzione di problemi di connettività di base.

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo che automatizza la richiesta e il rilascio di certificati digitali ai dispositivi di rete senza intervento manuale.

Essenziale per scalare le distribuzioni EAP-TLS, in quanto consente agli MDM e ai portali di onboarding di fornire certificati a decine di migliaia di dispositivi degli studenti in modo trasparente.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Il metodo di autenticazione 802.1X più sicuro, che richiede sia un certificato lato server che uno lato client per l'autenticazione reciproca.

Sostituisce i protocolli vulnerabili basati su password come PEAP, eliminando il rischio di furto di credenziali tramite access point evil twin.

MDM (Mobile Device Management)

Piattaforme software come Microsoft Intune o Jamf utilizzate per amministrare e proteggere i dispositivi di proprietà dell'istituto.

Utilizzato per inviare silenziosamente payload SCEP e profili WiFi ai dispositivi gestiti, garantendo che siano configurati per l'accesso alla rete prima della distribuzione.

CSR (Certificate Signing Request)

Un blocco di testo codificato generato dal dispositivo client contenente la chiave pubblica e le informazioni sull'identità, inviato alla CA per richiedere un certificato.

In un flusso di lavoro SCEP, il dispositivo genera la chiave privata localmente e invia solo la CSR al gateway, garantendo che la chiave privata rimanga sicura sull'endpoint.

RADIUS (Remote Authentication Dial-In User Service)

Il protocollo di rete che fornisce gestione centralizzata di autenticazione, autorizzazione e accounting.

Il server che valuta il certificato client presentato dal dispositivo durante lo scambio 802.1X e stabilisce l'assegnazione della VLAN.

Evil Twin Attack

Un exploit di sicurezza in cui un attaccante configura un punto di accesso non autorizzato con lo stesso SSID della rete legittima per intercettare le credenziali degli utenti.

EAP-TLS previene questo attacco perché il dispositivo client verifica il certificato del server RADIUS prima di trasmettere qualsiasi dato; se l'attaccante non possiede il certificato del server attendibile, la connessione si interrompe.

MAB (MAC Authentication Bypass)

Un metodo di autenticazione alternativo che utilizza l'indirizzo MAC di un dispositivo come credenziale.

Necessario per l'onboarding di dispositivi IoT headless (come le console di gioco) negli alloggi universitari che non possono supportare 802.1X o SCEP.

CRL (Certificate Revocation List)

Un elenco pubblicato dall'Autorità di Certificazione contenente i numeri di serie dei certificati che sono stati invalidati prima della loro data di scadenza.

Fondamentale per la sicurezza della rete; il server RADIUS deve controllare la CRL per garantire che ai dispositivi rubati o agli studenti laureati venga immediatamente negato l'accesso.

Esempi pratici

Un'università con 20.000 studenti sta migrando da PEAP-MSCHAPv2 a EAP-TLS. Utilizzano Microsoft Intune per 3.000 laptop Windows di proprietà dell'università, ma i restanti 45.000 dispositivi sono BYOD degli studenti (telefoni, tablet, laptop personali). Come dovrebbero progettare l'architettura di distribuzione dei certificati per garantire che tutti i dispositivi possano autenticarsi il primo giorno di lezione?

L'università deve implementare una strategia di registrazione biforcata. Per i 3.000 laptop gestiti da Intune, il team IT configura un profilo di certificato SCEP all'interno di Intune, inviando silenziosamente l'URL del gateway e la password di verifica ai dispositivi. Per i 45.000 dispositivi BYOD, distribuiscono un SSID di "Onboarding" aperto che limita il traffico a un Captive Portal self-service e al gateway SCEP. Gli studenti si connettono all'SSID di Onboarding, si autenticano tramite SAML SSO su Entra ID e scaricano un payload di configurazione che avvia la registrazione SCEP. Una volta installato il certificato, il dispositivo si associa automaticamente all'SSID sicuro "eduroam" utilizzando EAP-TLS.

Commento dell'esaminatore: Questo approccio identifica correttamente che l'MDM da solo non può risolvere la sfida del BYOD. Sfruttando un Captive Portal per i dispositivi non gestiti, l'università ottiene una copertura del certificato al 100% senza richiedere agli studenti di configurare manualmente le impostazioni 802.1X, prevenendo così un afflusso massiccio di ticket all'helpdesk.

Durante la prima settimana di lezione, l'helpdesk di un'università riceve segnalazioni relative al fatto che gli studenti riescono a connettersi al WiFi con i loro laptop, ma i loro smart speaker e le console da gioco nei dormitori non riescono a connettersi alla rete 802.1X. In che modo l'architetto di rete dovrebbe risolvere questo problema?

L'architetto deve implementare il MAC Authentication Bypass (MAB) per i dispositivi headless. Poiché gli smart speaker e le console non dispongono di supplicant 802.1X, non possono elaborare i payload SCEP o presentare certificati client. L'università dovrebbe implementare un portale di registrazione dei dispositivi self-service in cui gli studenti accedono con le proprie credenziali universitarie e inseriscono gli indirizzi MAC dei loro dispositivi IoT. Il server RADIUS è configurato per accettare questi indirizzi MAC registrati tramite MAB e assegnarli alla VLAN specifica per camera dello studente.

Commento dell'esaminatore: Questa soluzione affronta il limite tecnico dei dispositivi IoT headless mantenendo al contempo la segmentazione della rete. Utilizzando un portale self-service, il team IT evita l'inserimento manuale degli indirizzi MAC, scalando la soluzione per accogliere migliaia di dispositivi consumer nei dormitori.

Domande di esercitazione

Q1. La tua università sta distribuendo EAP-TLS. Hai configurato il gateway SCEP e i profili MDM. Tuttavia, quando i dispositivi di test provano a connettersi all'SSID sicuro, la connessione non va a buon fine senza mostrare errori. I log RADIUS indicano che il certificato client è valido, ma il dispositivo rifiuta il server. Qual è l'errore di configurazione più probabile?

Suggerimento: Considera i requisiti per l'autenticazione reciproca e ciò di cui il dispositivo ha bisogno per considerare attendibile il server.

Visualizza risposta modello

Il profilo del certificato attendibile MDM è probabilmente mancante o configurato in modo errato. In EAP-TLS, l'autenticazione reciproca richiede che il dispositivo verifichi il certificato del server RADIUS. Se il dispositivo non ha il certificato Root CA installato nel suo archivio attendibile, non può convalidare il certificato del server e interromperà la connessione per prevenire un potenziale Evil Twin Attack.

Q2. Uno studente riferisce che il proprio laptop, registrato con successo tramite il portale BYOD e dotato di un certificato client valido, non può più accedere alla rete dopo aver cambiato la password della directory universitaria. Quale difetto architetturale indica questo problema?

Suggerimento: L'autenticazione EAP-TLS si basa interamente sul certificato, non sulla password.

Visualizza risposta modello

Questo indica che la rete non sta effettivamente utilizzando EAP-TLS, ma probabilmente sta ricorrendo a PEAP-MSCHAPv2 o a un altro protocollo basato su password. Se viene configurato il vero EAP-TLS, il server RADIUS convalida la firma crittografica del certificato, scollegando completamente l'accesso alla rete dalla password della directory. L'architetto di rete deve imporre criteri EAP-TLS rigorosi sul server RADIUS e disattivare i protocolli alternativi.

Q3. Durante la prima settimana di corsi, i server RADIUS registrano un utilizzo elevato della CPU ed errori di timeout intermittenti, causando disservizi diffusi nell'autenticazione. I server sono dimensionati adeguatamente per il numero totale di sessioni simultanee. Cosa sta causando i timeout?

Suggerimento: Considera la differenza di carico computazionale tra la verifica di una password e la convalida di una catena di certificati durante la fase iniziale di connessione.

Visualizza risposta modello

I timeout sono causati dal pesante carico computazionale degli handshake crittografici EAP-TLS durante il picco iniziale di autenticazioni degli studenti che rientrano. L'architetto deve aumentare il valore di timeout RADIUS sui punti di accesso wireless (ad es. Cisco Meraki o HPE Aruba) ad almeno 5 secondi per gestire la latenza e assicurarsi che il bilanciamento del carico distribuisca equamente le richieste iniziali di autenticazione completa su tutti i nodi RADIUS.

Continua a leggere questa serie

PSK per dispositivo per fornitore: confronto tra iPSK, DPSK, MPSK e PPSK (e supporto WPA3)

Un confronto completo delle implementazioni PSK per dispositivo tra Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Scopri come WPA3-SAE influisce sulle strategie delle chiavi per dispositivo e quando distribuire le modalità di transizione rispetto al passaggio a 802.1X.

Leggi la guida →

Metodi di autenticazione del Captive Portal a confronto

Questa guida di riferimento tecnico autorevole valuta i compromessi architetturali, operativi e di conformità di cinque metodi di autenticazione principali per captive portal. Fornisce ad architetti di rete, direttori IT e marketing manager i dati quantitativi e i framework decisionali necessari per bilanciare l'attrito nell'onboarding degli ospiti con i requisiti di raccolta dati all'interno delle sedi aziendali.

Leggi la guida →

Cos'è l'autenticazione tramite indirizzo MAC? Quando usarla e quando evitarla

Questa guida tecnica di riferimento autorevole copre l'autenticazione tramite indirizzo MAC negli ambienti WiFi aziendali: come funziona l'autenticazione MAC basata su RADIUS a livello Layer 2, le sue vulnerabilità di sicurezza intrinseche (incluso il MAC spoofing e l'impatto della randomizzazione MAC a livello di sistema operativo) e i precisi contesti operativi in cui rimane uno strumento valido per la gestione di dispositivi IoT e headless. Fornisce linee guida di implementazione pratiche per responsabili IT e architetti di rete nei settori dell'ospitalità, del retail, della sanità e dei luoghi pubblici, con esempi pratici reali, framework decisionali e contesti di integrazione per la piattaforma di guest WiFi e analytics di Purple.

Leggi la guida →