Un ospite arriva in un hotel, seleziona il WiFi della struttura, attende un Captive Portal, accetta i termini, inserisce un indirizzo email e ripete il processo al centro congressi della porta accanto. In un ospedale, l'iPad gestito e il telefono VoWiFi di un medico possono spostarsi tra gli access point con profili diversi. In uno stadio, migliaia di dispositivi competono per la connessione mentre la pagina di login diventa un ulteriore punto di vulnerabilità.
La configurazione Passpoint WiFi risolve questo attrito spostando le decisioni di accesso nel livello di identità. I dispositivi compatibili rilevano la rete, valutano le credenziali pubblicizzate e le informazioni di roaming, quindi si autenticano tramite la sicurezza WiFi enterprise anziché affidarsi a una password condivisa o a una splash page. Il risultato può essere un onboarding automatico e il roaming in più sedi che si affidano allo stesso identity provider.
Questo risultato non si ottiene semplicemente selezionando una casella Hotspot 2.0. Dipende dal firmware degli AP, dagli annunci 802.11u e ANQP, dai metodi EAP, dai certificati, dai realm NAI, dalla capacità RADIUS, dal supporto dei dispositivi e dalla progettazione dei sistemi di fallback. L'approccio pratico consiste nell'analizzare l'infrastruttura, avviare un progetto pilota su una porzione controllata, registrare i problemi e procedere all'espansione solo quando i dati lo supportano.
Perché la configurazione di Passpoint WiFi è fondamentale per le reti enterprise
Hotel, ospedali e stadi mettono rapidamente in luce i punti deboli del WiFi per ospiti convenzionale. Un hotel potrebbe dover supportare centinaia di dispositivi diversi durante visite ripetute, mentre un ospedale dispone di dispositivi clinici condivisi, palmari del personale e visitatori con identity provider non correlati. Uno stadio presenta una domanda densa e imprevedibile e poca tolleranza per un flusso di accesso che fallisce quando gli utenti si spostano attraverso gli ingressi o cambiano settore.
I Captive Portal sono utili quando un operatore ha bisogno del consenso o di dati di marketing, ma creano un onere operativo separato. Gli SSID per singola sede costringono gli utenti a scegliere le reti manualmente, le password condivise si diffondono oltre il pubblico previsto e i reindirizzamenti dei portali possono fallire a causa del comportamento del browser, di avvisi sui certificati o di cattive condizioni radio. La riautenticazione diventa particolarmente problematica quando un utente passa da un controller o edificio a un altro.
Cosa sostituisce un'implementazione funzionante
Passpoint utilizza il protocollo di rilevamento 802.11u, le informazioni di rete ANQP e l'autenticazione basata su EAP per consentire a un dispositivo di determinare se possiede un profilo valido prima di associarsi. Con le credenziali corrette, il dispositivo può connettersi senza dover reinserire la password. Le tecnologie WPA2-Enterprise o WPA3-Enterprise forniscono quindi il modello di sicurezza previsto per l'accesso basato sull'identità.
I vantaggi operativi sono di natura pratica piuttosto che estetica:
- Minore amministrazione delle credenziali: lo staff non deve reimpostare una password guest condivisa ogni volta che viene pubblicata su un avviso pubblico.
- Minori dipendenze dal portale: un dispositivo supportato non deve caricare una splash page prima di ottenere l'accesso alla rete.
- Migliore continuità multi-sede: un profilo può riconoscere le reti affidabili associate allo stesso realm o relazione di roaming.
- Controllo degli accessi più pulito: i criteri RADIUS possono distinguere utenti, dispositivi e provider di identità invece di trattare ogni client come un membro anonimo di un unico SSID.
Il Regno Unito dispone già di un benchmark pertinente per il settore pubblico. Il servizio ufficiale GovWifi service fornisce un unico nome utente e password per il personale e i visitatori in tutto il settore pubblico, e la Government Property Agency dichiara che serve oltre 850.000 persone in tutto il Regno Unito. GovWifi connette inoltre gli utenti automaticamente in migliaia di edifici che offrono il servizio. Non si tratta della stessa implementazione di Passpoint, ma dimostra che l'autenticazione centralizzata e l'accesso multi-sede sono pratiche operative consolidate, non idee di laboratorio.
Gestisci il progetto come ingegneria delle identità
La prima decisione di progettazione riguarda se Passpoint deve servire dispositivi aziendali gestiti, accesso ospiti pubblico, offload di operatori mobili o una federazione come OpenRoaming. Ciascun caso d'uso modifica la sorgente delle credenziali, il metodo EAP, il modello di policy e l'esperienza di fallback.
Il report della Wireless Broadband Alliance coperto da Comms Business ha rilevato che l'81% degli intervistati pianificava distribuzioni OpenRoaming, con motivazioni che includono l'accesso WiFi e cellulare, una maggiore sicurezza, un accesso senza attriti e la continuità tra le reti. Questi dati non eliminano il lavoro di ingegneria. Mostrano perché gli operatori stanno investendo in questo ambito, mentre l'implementazione dipende ancora dall'esatta configurazione dell'identità e della attendibilità.
Comprendere lo stack Passpoint
Passpoint è un sistema a livello di identità, non una casella da spuntare sul controller wireless. La risoluzione dei problemi diventa molto più rapida quando ogni livello ha un compito definito. L'access point pubblicizza informazioni sufficienti affinché un dispositivo possa decidere se la rete corrisponde a un profilo installato. Il dispositivo seleziona una credenziale compatibile e avvia l'autenticazione enterprise. RADIUS prende la decisione di autorizzazione, mentre i certificati e i realm determinano se il client e il server si considerano attendibili a vicenda.
A livello radio e di rilevamento, lo standard IEEE 802.11u fornisce il rilevamento della rete prima della normale associazione. L'access point utilizza GAS per trasportare query e risposte ANQP. L'ANQP può pubblicare il tipo di accesso della rete, i nomi di dominio, i realm NAI, gli identificatori di roaming, le informazioni sulla sede, i dati relativi alla rete cellulare e le metriche WAN. Il client confronta questi valori con i profili già installati sul dispositivo.
Il percorso pratico è:
- Beacon e indicazione 802.11u: L'AP segnala che le informazioni Hotspot 2.0 sono disponibili.
- Scambio GAS e ANQP: Il client chiede quali identità, realm, partner di roaming e servizi sono supportati dalla rete.
- Corrispondenza del profilo: Il dispositivo confronta i valori pubblicizzati con il suo profilo Passpoint.
- Autenticazione EAP: Il dispositivo si autentica tramite 802.1X, comunemente utilizzando EAP-TLS, EAP-TTLS, EAP-SIM o EAP-AKA, a seconda dell'implementazione.
- Autorizzazione RADIUS: L'AP o il controller inoltra la richiesta e applica la policy restituita.
- Associazione crittografata: Il client si connette tramite WPA2-Enterprise o WPA3-Enterprise, senza affidarsi a un Captive Portal.
Le linee guida per la distribuzione di WiFi Alliance identificano l'indicazione HS2.0 nel beacon dell'AP come un prerequisito. Se un client non rileva tale indicazione, non avvierà l'individuazione Passpoint, indipendentemente da quanto accuratamente sia stato configurato il RADIUS.
EAP-TLS utilizza certificati client e si adatta generalmente alle flotte aziendali gestite, in quanto l'organizzazione può emettere, ruotare e revocare le credenziali dei dispositivi. EAP-TTLS supporta flussi di lavoro con nome utente e password, ma l'identità interna e il certificato del server richiedono comunque una protezione attenta. I metodi EAP basati su SIM sono adatti a implementazioni di operatori o federate in cui l'abbonamento mobile fornisce la credenziale.
Il realm NAI identifica il dominio di identità responsabile di una richiesta. I codici RCOI identificano i consorzi di roaming e aiutano i client a decidere se una rete appartiene a una relazione di servizio fidata. Un server OSU può fornire credenziali per i flussi di registrazione supportati, mentre un policy server può connettere la sede a una federazione e applicare le regole dei partner.
Le release Passpoint vanno oltre la semplice individuazione. Hotspot 2.0 Release 2 e Release 3 supportano la registrazione online e la fornitura di policy, ma ogni funzionalità aggiuntiva crea un ulteriore punto di configurazione. Un URI OSU non valido, una catena di certificati incompleta o un realm che differisce anche solo di un carattere possono bloccare l'associazione. Le impostazioni del Captive Portal possono inoltre entrare in conflitto con un flusso di identità che prevede un accesso enterprise crittografato.
Regola di ingegneria: Traccia il percorso da beacon ad ANQP, profilo, EAP, RADIUS e decisione di policy prima di configurare l'SSID di produzione. Se un passaggio non è chiaro, avvia prima il progetto pilota in quel punto.
Controlli preliminari prima di toccare il controller
Un progetto pilota Passpoint può fallire ancora prima di aprire il controller. Inizia analizzando la catena delle dipendenze: firmware degli AP, release del controller, servizi di identità, certificati, profili client e capacità operativa. Verifica che lo specifico modello di AP e la release del software supportino Hotspot 2.0, ANQP, la modalità WPA selezionata e ogni campo Passpoint richiesto. La compatibilità generica della famiglia di prodotti non è sufficiente.
Crea una piccola base di riferimento scritta piuttosto che copiare le impostazioni tra i siti. Conferma che la piattaforma AAA supporti i metodi EAP scelti, gli attributi Passpoint, l'accounting e le risposte alle policy. Testa la raggiungibilità da ogni sorgente AP o controller che parteciperà al progetto pilota. Dimensiona il RADIUS per i picchi di autenticazione e accounting, non solo per il traffico medio. Una mancata corrispondenza del realm fallirà comunque su una piattaforma sovradimensionata, mentre un servizio sottodimensionato può oscurare una configurazione altrimenti corretta.
Il piano dei certificati necessita dello stesso trattamento. Registra la CA emittente, i trust anchor, il proprietario del rinnovo e il percorso di revoca. Assicurati che il certificato del server sia ritenuto attendibile da ogni dispositivo di test. Se l'organizzazione controlla i certificati dei dispositivi e desidera un accesso senza password, EAP-TLS è solitamente la scelta appropriata. EAP-TTLS si adatta a un processo controllato di nome utente e password. EAP-SIM o EAP-AKA appartengono a progetti di federazione supportati da carrier o SIM, piuttosto che sostituire una strategia di certificati aziendali.
Utilizza un gruppo di client di prova noto che rappresenti il sito reale, inclusi diversi sistemi operativi, produttori di dispositivi e profili gestiti. Includi anche dispositivi non gestiti o non supportati per verificare l'esperienza utente quando l'autenticazione automatica non è disponibile. Anche il comportamento del Captive Portal rientra in questa fase di test, poiché una policy del portale può interferire con un flusso di identità progettato per utilizzare l'accesso enterprise crittografato.
Prima della configurazione, bloccare i valori di identità. Scrivere il realm NAI esattamente come previsto dall'identity provider, prestando attenzione a maiuscole, minuscole, punteggiatura e suffissi. Registrare la decisione sul server OSU, la relazione di federazione, i requisiti RCOI, il proprietario del certificato e l'SSID di fallback in un'unica checklist. Questi valori non devono rimanere solo nelle note di un tecnico.
Pianificate la disposizione radio partendo dalla sede reale, quindi convalidate il numero di AP e il design con un calcolatore di access point. La pianificazione della capacità evidenzia un design sovraccarico prima del cutover, ma non può correggere un realm non corrispondente o un certificato non valido.
Disabilitate WEP e TKIP. Mantenete il design Passpoint su WPA2-Enterprise o WPA3-Enterprise, escludendo le modalità di sicurezza legacy.
Configurazione specifica per i vendor Meraki, Aruba, Ruckus, Mist e UniFi
Gli standard sono condivisi, ma l'esperienza amministrativa no. I vendor espongono le stesse primitive in profili diversi e alcune piattaforme nascondono la convalida dietro impostazioni WLAN generiche. Considerate la configurazione seguente come una mappa su dove cercare, quindi verificate ogni campo confrontandolo con la documentazione esatta della release in uso.
| Fornitore | Supporto Passpoint Nativo | Posizione di Caricamento del Certificato | OSU / Onboarding | Errore Comune |
|---|---|---|---|---|
| Meraki | Impostazioni Hotspot 2.0 sull'SSID | Area certificati a livello di rete | Campi del provider OSU nel profilo SSID | Un profilo può apparire completo anche se i valori del realm o della rete di accesso rimangono incoerenti |
| Aruba | Profilo Hotspot 2.0 associato a un SSID 802.1X | Archivio certificati del controller o di mobilità | Integrazione profilo e AAA | I valori di realm derivati da AAA richiedono verifica e non presunzioni |
| Ruckus | Impostazioni Passpoint nella WLAN | Configurazione dei certificati SmartZone | Campi Venue e OSU nelle impostazioni WLAN | Il firmware degli AP più vecchi può omettere silenziosamente gli elementi ANQP |
| Juniper Mist | Passpoint tramite template WLAN | Identità dell'organizzazione e configurazione dei certificati | Identity provider e workflow dei template | Un URI OSU non valido può creare anomalie ANQP |
| UniFi | Supporto nativo dell'oggetto limitato | RADIUS esterno e gestione dei certificati specifica della piattaforma | In genere esterno o improvvisato | Le soluzioni alternative personalizzate sono difficili da gestire come federazione di produzione |
Dove divergono le implementazioni
Meraki è relativamente diretto per una distribuzione gestita in cloud. Abilita Hotspot 2.0 sull'SSID, imposta il tipo di rete di accesso, il dominio, il realm e il metodo EAP, quindi compila le informazioni del provider OSU dove richiesto. Carica il certificato tramite il flusso di lavoro del certificato di rete e controlla l'annuncio ANQP risultante invece di affidarti al riepilogo della dashboard. Le organizzazioni che si standardizzano su Meraki dovrebbero anche esaminare la gamma di access point Cisco Meraki rispetto al firmware pianificato e ai requisiti del profilo client.
Aruba normalmente inizia con una WLAN 802.1X, un profilo Hotspot 2.0 e una catena CA importata. Il controllo importante è la relazione tra il realm derivato del server AAA e il realm pubblicizzato tramite il profilo. I Mobility Conductor e i controller distribuiti aggiungono un ulteriore livello in cui l'ereditarietà delle configurazioni può fallire.
Ruckus SmartZone richiede una stretta attenzione all'allineamento del firmware di WLAN e AP. Aggiungete il profilo Passpoint, il certificato firmato e i dettagli della sede, quindi acquisite le risposte ANQP da un AP attivo. Una dashboard che mostra le impostazioni abilitate non dimostra che un AP più vecchio stia trasmettendo gli stessi elementi.
Juniper Mist concentra il lavoro nei modelli WLAN e nella configurazione dell'identità a livello aziendale. Il processo può risultare lineare quando l'identity provider e i valori OSU sono validi, ma gli URI di registrazione non validi tendono a manifestarsi come anomalie di individuazione piuttosto che come un chiaro errore di configurazione.
UniFi rappresenta il caso difficile. Senza un oggetto nativo Passpoint completo, i team spesso assemblano RADIUS esterni, hostname personalizzati e soluzioni temporanee di policy parziali. Questo può essere accettabile per scopi sperimentali, ma crea troppi confini di gestione per un ospedale regolamentato, un grande gruppo alberghiero o una federazione di roaming.
Realtà del vendor: Uno stato di configurazione verde indica semplicemente che l'oggetto è stato accettato dal controller. Non prova che un client sia in grado di rilevare, considerare attendibile, autenticare ed effettuare il roaming attraverso di esso.
Configurazione dei certificati, di RADIUS e del livello di identità
Un deployment Passpoint può completare l'associazione con successo ma fallire a livello di identità. Inizia con l'identità del server che i dispositivi client dovranno convalidare. Genera una CSR con i subject alternative names richiesti per il dominio del servizio e lo spazio dei nomi dell'identità. Utilizza una CA pubblica già considerata attendibile dai dispositivi degli utenti, oppure distribuisci una catena di attendibilità privata tramite strumenti di gestione dei dispositivi.
Importare il certificato e la catena intermedia nella sequenza richiesta dal controller. L'assenza di un certificato intermedio si presenta comunemente all'utente come una password errata. Dopo ogni modifica del certificato, eseguire un test da un dispositivo client reale, ispezionare la catena presentata e correlare il risultato con i log di autenticazione del controller. Un controllo del browser in laboratorio non è sufficiente.
Costruisci il percorso RADIUS
RADIUS è il punto di decisione delle policy per l'identità Passpoint, non un semplice validatore di password. FreeRADIUS, Cisco ISE, ClearPass e Microsoft NPS differiscono nel supporto EAP e nella sintassi delle policy. Registrate il metodo selezionato, i controlli dei certificati, la gestione dei realm e la mappatura degli attributi prima dell'implementazione.
- EAP-TLS: mappa il soggetto del certificato client o il SAN al record del dispositivo o dell'utente, applica l'attendibilità dell'emittente e definisci la gestione della revoca.
- EAP-TTLS: proteggi lo scambio esterno con il certificato del server, quindi mappa l'identità interna al realm e al criterio corretti.
- EAP basato su SIM: conferma che l'operatore o la federazione fornisca la convalida dell'abbonato e che il livello RADIUS sia in grado di elaborarla.
- Criterio del realm: assicurati che un valore come
@corp.example.comraggiunga il provider di identità previsto senza variazioni di maiuscole/minuscole o di formattazione.
La capacità RADIUS necessita di una verifica separata. L'autenticazione tramite certificati e l'accounting producono pattern di richiesta diversi rispetto al normale 802.1X. I picchi di onboarding e riconnessione possono evidenziare problemi di latenza, accodamento e timeout, specialmente in un hotel, un ospedale o uno stadio. Utilizza server ridondanti, misura la latenza di risposta e testa il comportamento in caso di guasto anziché presumere che il livello WLAN del personale esistente abbia capacità residua.
Un modello gestito di RADIUS-as-a-Service può ridurre l'onere operativo di gestione, ma prima di sceglierlo è fondamentale verificare il supporto per i metodi EAP richiesti, i controlli di policy, la registrazione dei log e il ciclo di vita dei certificati.
Aggiungi i dettagli della federazione in modo mirato
OpenRoaming richiede che la sede, l'identità del fornitore di servizi e gli identificatori di federazione concordino tra il profilo, il sistema di policy e la relazione di roaming. Le linee guida per l'implementazione e la distribuzione di Passpoint coprono i realm NAI, la distribuzione dei certificati e la registrazione RCOI come attività a livello di identità. Gli identificatori di roaming comuni includono l'RCOI settlement-free 5A-03-BA e il legacy Cisco RCOI 00-40-96 dove è richiesta una compatibilità più ampia.
Dopo aver caricato il profilo, riavvia i componenti pertinenti del controller e ispeziona i beacon attivi e le risposte ANQP. Verifica che il realm annunciato, le informazioni sulla sede (venue information), l'RCOI e l'OSU NAI siano corretti. Controlla inoltre la presenza di un Captive Portal associato allo stesso percorso di servizio, poiché potrebbe intercettare l'onboarding o entrare in conflitto con un profilo che prevede l'autenticazione diretta.
Il file di configurazione è solo un input. Il pacchetto trasmesso via etere costituisce la verifica finale.
Soglie di pilot, validazione e go-live
Eseguire il progetto pilota come un esercizio di misurazione. Selezionare un piano, un dipartimento o un atrio, mantenere disponibile un percorso legacy 802.1X e utilizzare un gruppo fisso di dispositivi di cui si conoscono la proprietà e le versioni del sistema operativo. Includere sia i client gestiti da certificato sia i dispositivi dei visitatori che potrebbero esporre problemi di profilo e di fallback.
Prima di abilitare l'SSID, definite per iscritto i criteri di accettazione:
- Discovery: Ogni AP di test deve trasmettere l'indicazione HS2.0 e gli elementi ANQP richiesti.
- Associazione: Le credenziali memorizzate nella cache dovrebbero associarsi in meno di tre secondi durante il test controllato.
- Autenticazione: Il livello RADIUS non dovrebbe mostrare timeout al picco di domanda previsto.
- Fallback: I dispositivi che non dispongono di un profilo compatibile dovrebbero ricevere un'alternativa documentata, anziché rimanere bloccati in un loop continuo all'interno di un portale non funzionante.
- Roaming: Testa il passaggio da AP ad AP a intervalli regolari, quindi ripeti l'operazione tra i controller con il dominio di mobilità configurato.
Acquisire prove in tre punti. Utilizzare un AP in modalità monitor o un'acquisizione pacchetti equivalente per ispezionare il traffico beacon, GAS e ANQP. Esportare i log RADIUS con gli identificativi di richiesta e gli attributi di risposta. Raccogliere i log del sistema operativo da ciascun dispositivo di test, specialmente dove il produttore di un dispositivo ha successo e un altro rifiuta lo stesso profilo.
Le linee guida della WiFi Alliance supportano la verifica delle funzionalità dell'AP e del controller, della prontezza RADIUS e della compatibilità EAP prima della distribuzione. Una guida pratica per esperti raccomanda un progetto pilota sul 10% - 20% degli AP, con oltre il 98% di successo della connessione e una latenza di autenticazione inferiore a 300 millisecondi come indicatori go - or - no - go. Tali soglie dovrebbero essere testate rispetto alla tolleranza al rischio dell'organizzazione, ma forniscono una disciplina concreta per l'espansione.
Non estendere la distribuzione solo perché la prima mattina è andata bene. Mantenere attivo il progetto pilota durante i normali periodi di picco, verificare i log di roaming e di errore, quindi applicare le correzioni documentate al sito successivo.
Risoluzione dei problemi e scenari di guasto dell'ultimo miglio
I fallimenti più difficili si presentano dopo che la configurazione sembra completata. Passpoint dipende dall'accordo simultaneo tra client, AP, profilo, catena di attendibilità e policy RADIUS. Un Captive Portal non può riparare uno scambio Passpoint fallito perché gli SSID abilitati per Passpoint non supportano i reindirizzamenti del portale come meccanismo di autenticazione.
| Failure Mode | Symptom | Diagnostic Signal | Remediation |
|---|---|---|---|
| Mancata corrispondenza del realm | Il client ignora la rete o torna a un altro SSID | Confronta il realm NAI pubblicizzato in ANQP con il realm nella richiesta RADIUS | Normalizza le stringhe dei realm e i valori dei profili, inclusi maiuscole/minuscole e suffissi |
| Catena di certificati interrotta | EAP-TLS fallisce nonostante un certificato client valido | I log RADIUS EAP mostrano errori di attendibilità o di validazione della catena | Ricostruisci la catena servita, conferma i certificati intermedi e testa dal sistema operativo del client |
| Elementi ANQP mancanti | I dispositivi non riconoscono l'SSID come rete Passpoint idonea | L'acquisizione dei pacchetti mostra l'assenza di indicazione HS2.0 o una risposta ANQP incompleta | Verifica il firmware dell'AP, l'ereditarietà del controller e il beacon live |
| Saturazione del RADIUS | L'autenticazione rallenta o fallisce durante i picchi di onboarding | Latenza delle richieste in aumento, ritrasmissioni o profondità della coda nei log RADIUS | Aggiungi capacità e ridondanza, quindi testa nuovamente il carico dei certificati e dell'accounting |
| Conflitto con Captive Portal | I client supportati si connettono in modo discontinuo o non completano mai l'accesso | Il debug del controller mostra la policy del portale associata all'SSID Passpoint | Separa le policy Passpoint e del portale, con un SSID legacy esplicito |
| Variazioni tra i dispositivi | Una famiglia di smartphone effettua il roaming mentre un'altra rimane collegata o rifiuta la connessione | Confronta i log del sistema operativo, il supporto del profilo e la gestione dell'RCOI per tipo di dispositivo | Mantieni una matrice dei dispositivi testati e pubblica le istruzioni di fallback |
Controlla prima l'annuncio radio in tempo reale, poi il profilo del client, l'attendibilità del certificato, la richiesta RADIUS e la risposta alla policy. Questo ordine evita ore di modifiche alle regole del server quando l'AP non ha mai annunciato l'indicazione HS2.0 richiesta.
Le flotte miste richiedono una transizione intenzionale. Mantieni attivo l'accesso legacy WPA2-Enterprise o EAP-TTLS per i dispositivi che non possono consumare il profilo Passpoint, ma non inserire la logica del Captive Portal sull'SSID Passpoint. Il DSIT public engagement survey per il periodo 2025 - 2026 riporta che il 31% degli adulti utilizza la rete dati mobile o un hotspot a casa, mentre il 3% vi si affida come metodo di accesso domestico principale. Ciò suggerisce che gli utenti hanno familiarità con la connettività assistita da dispositivi mobili, ma i gestori delle sedi hanno comunque bisogno di un meccanismo di fallback semplice per i client il cui telefono, identificativo dell'operatore o sistema operativo non supporta il profilo desiderato in modo coerente.
Anche i dispositivi iOS e Android possono interpretare i suggerimenti di roaming in modo diverso. Testate ogni famiglia supportata, non deducete la compatibilità dalla sola presenza di un'impostazione Passpoint. Se una distribuzione precedentemente funzionante si interrompe, confrontate le ultime modifiche a certificati, profili, firmware, realm e policy RADIUS prima di ricostruire la WLAN.
Purple offre la tecnologia Passpoint WiFi attraverso la sua piattaforma SecurePass, utilizzando l'onboarding basato su profili e certificati per l'autenticazione automatica sulle reti supportate. Se desideri valutare questo approccio a livello di identità insieme al tuo design AP e RADIUS esistente, visita il sito Purple e discuti con il team l'ambito del progetto pilota, il mix di dispositivi e i requisiti di fallback.
