Un client arrive dans un hôtel, sélectionne le WiFi de l'établissement, attend un Captive Portal, accepte les conditions, saisit une adresse e-mail, et répète le processus au centre de conférence voisin. Dans un hôpital, l'iPad managé d'un clinicien et son combiné VoWiFi peuvent se déplacer entre les points d'accès tout en portant des profils différents. Dans un stade, des milliers d'appareils se disputent la bande passante tandis que la page de connexion devient un point de défaillance supplémentaire.
La configuration du WiFi Passpoint résout ces frictions en déplaçant les décisions d'accès vers la couche d'identité. Les appareils compatibles découvrent le réseau, évaluent ses identifiants annoncés ainsi que les informations d'itinérance, puis s'authentifient via la sécurité WiFi d'entreprise plutôt que de s'appuyer sur un mot de passe partagé ou une page de connexion. Le résultat permet un enregistrement automatique et une itinérance fluide sur plusieurs sites qui font confiance au même fournisseur d'identité.
Ce résultat ne s'obtient pas simplement en cochant une case Hotspot 2.0. Il dépend du firmware de l'AP, des annonces 802.11u et ANQP, des méthodes EAP, des certificats, des domaines NAI, de la capacité RADIUS, de la compatibilité des appareils et de la conception des solutions de secours. L'approche pratique consiste à auditer le parc, à piloter un segment contrôlé, à identifier les défaillances et à ne déployer à grande échelle que lorsque les résultats le valident.
Pourquoi la configuration du WiFi Passpoint est essentielle pour les réseaux d'entreprise
Les hôtels, les hôpitaux et les stades révèlent rapidement les faiblesses du WiFi invité conventionnel. Un hôtel peut devoir prendre en charge des centaines d'appareils différents lors de visites répétées, tandis qu'un hôpital dispose d'appareils cliniques partagés, de téléphones du personnel et de visiteurs ayant des fournisseurs d'identité sans rapport. Un stade présente une demande dense et imprévisible, avec peu de tolérance pour un flux de connexion qui échoue lorsque les utilisateurs se déplacent dans les entrées ou changent de tribune.
Les Captive Portals sont utiles lorsqu'un opérateur a besoin d'un consentement ou de données marketing, mais ils créent une charge opérationnelle distincte. Les SSID par site obligent les utilisateurs à choisir les réseaux manuellement, les mots de passe partagés se propagent au-delà de leur public cible, et les redirections de portail peuvent échouer en raison du comportement du navigateur, d'avertissements de certificat ou de mauvaises conditions radio. La réauthentification devient particulièrement perturbatrice lorsqu'un utilisateur passe d'un contrôleur ou d'un bâtiment à un autre.
Ce qu'un déploiement opérationnel remplace
Passpoint utilise la découverte 802.11u, les informations réseau ANQP et l'authentification basée sur EAP pour permettre à un appareil de déterminer s'il dispose d'un profil valide avant de s'associer. Avec les bons identifiants, l'appareil peut se connecter sans saisie répétée de mot de passe. Le WPA2-Enterprise ou le WPA3-Enterprise fournit ensuite le modèle de sécurité attendu pour un accès basé sur l'identité.
Les avantages opérationnels sont pratiques plutôt que cosmétiques :
- Moins d'administration des identifiants : le personnel n'a pas à réinitialiser un mot de passe invité partagé chaque fois qu'il est divulgué publiquement.
- Moins de dépendances au portail : un appareil compatible n'a pas besoin de charger une page d'accueil avant d'accéder au réseau.
- Meilleure continuité multi-site : un profil peut identifier les réseaux de confiance associés au même domaine ou à la même relation d'itinérance.
- Contrôle d'accès plus précis : les politiques RADIUS peuvent distinguer les utilisateurs, les appareils et les fournisseurs d'identité au lieu de traiter chaque client comme un membre anonyme d'un même SSID.
Le Royaume-Uni dispose déjà d'une référence pertinente dans le secteur public. Le service officiel GovWifi fournit un nom d'utilisateur et un mot de passe uniques pour le personnel et les visiteurs de l'ensemble du secteur public, et la Government Property Agency indique qu'il dessert plus de 850 000 personnes à travers le Royaume-Uni. GovWifi connecte également les utilisateurs automatiquement dans des milliers de bâtiments qui proposent le service. Il ne s'agit pas de la même implémentation que Passpoint, mais cela démontre que l'authentification centralisée et l'accès multi-site sont des pratiques opérationnelles bien établies, et non des concepts théoriques.
Traitez le projet comme de l'ingénierie d'identité
Le premier choix de conception consiste à déterminer si Passpoint s'adresse aux appareils du personnel géré, à l'accès des invités publics, au déchargement d'opérateur ou à une fédération telle que OpenRoaming. Chaque cas d'utilisation modifie la source des identifiants, la méthode EAP, le modèle de politique et l'expérience de repli.
Le rapport de la Wireless Broadband Alliance couvert par Comms Business a révélé que 81 % des répondants prévoyaient des déploiements OpenRoaming, avec des motivations incluant l'accès WiFi et cellulaire, une sécurité renforcée, un accès sans friction et la continuité entre les réseaux. Ces chiffres ne suppriment pas le travail d'ingénierie. Ils montrent pourquoi les opérateurs y investissent, tandis que l'implémentation dépend toujours de la configuration exacte de l'identité et de la confiance.
Comprendre la pile Passpoint
Passpoint est un système de couche d'identité, pas une simple case à cocher sur le contrôleur sans fil. Le dépannage devient beaucoup plus rapide lorsque chaque couche a une fonction définie. Le point d'accès diffuse suffisamment d'informations pour qu'un appareil puisse décider si le réseau correspond à un profil installé. L'appareil sélectionne un identifiant compatible et démarre l'authentification entreprise. Le serveur RADIUS prend la décision d'autorisation, tandis que les certificats et les domaines d'authentification déterminent si le client et le serveur se font confiance mutuellement.
Au niveau de la couche radio et de découverte, la norme IEEE 802.11u permet la découverte du réseau avant l'association normale. Le point d'accès utilise GAS pour transporter les requêtes et réponses ANQP. L'ANQP peut publier le type d'accès du réseau, les noms de domaine, les domaines NAI, les identifiants d'itinérance, les informations sur le site, les données liées au réseau cellulaire et les métriques WAN. Le client compare ces valeurs avec les profils déjà installés sur l'appareil.
La démarche pratique est la suivante :
- Balise et indication 802.11u : L'AP signale que les informations Hotspot 2.0 sont disponibles.
- Échange GAS et ANQP : Le client demande quels identités, domaines, partenaires d'itinérance et services le réseau prend en charge.
- Correspondance de profil : L'appareil compare les valeurs annoncées avec son profil Passpoint.
- Authentification EAP : L'appareil s'authentifie via 802.1X, généralement en utilisant EAP-TLS, EAP-TTLS, EAP-SIM ou EAP-AKA, selon le déploiement.
- Autorisation RADIUS : L'AP ou le contrôleur transfère la requête et applique la politique renvoyée.
- Association chiffrée : Le client se connecte via WPA2-Enterprise ou WPA3-Enterprise, sans dépendre d'un Captive Portal.
Le guide de déploiement de la WiFi Alliance identifie l'indication HS2.0 dans la balise de l'AP comme un prérequis indispensable. Si un client ne peut pas détecter cette indication, il ne démarrera pas la découverte Passpoint, quel que soit le soin apporté à la configuration du serveur RADIUS.
L'EAP-TLS utilise des certificats clients et convient généralement aux flottes gérées car l'organisation peut émettre, renouveler et révoquer les identifiants des appareils. L'EAP-TTLS prend en charge les flux de travail avec identifiant et mot de passe, mais l'identité interne et le certificat serveur nécessitent toujours une protection rigoureuse. Les méthodes EAP basées sur la carte SIM conviennent aux déploiements d'opérateurs ou fédérés où l'abonnement mobile fournit l'identifiant.
Le domaine NAI identifie le domaine d'identité responsable d'une demande. Les RCOI identifient les consortiums d'itinérance et aident les clients à déterminer si un réseau appartient à une relation de service approuvée. Un serveur OSU peut fournir des identifiants pour les flux d'inscription pris en charge, tandis qu'un serveur de politique peut connecter le site à une fédération et appliquer les règles des partenaires.
Les versions de Passpoint vont bien au-delà de la simple découverte. Les versions 2 et 3 de Hotspot 2.0 prennent en charge l'inscription en ligne et le provisionnement des politiques, mais chaque fonctionnalité ajoutée crée un point de configuration supplémentaire. Un URI OSU mal formé, une chaîne de certificats incomplète ou un domaine qui diffère d'un seul caractère peut bloquer l'association. Les paramètres du Captive Portal peuvent également entrer en conflit avec un flux d'identité qui s'attend à un accès entreprise chiffré.
Règle d'ingénierie : Tracez le chemin depuis la balise vers l'ANQP, le profil, l'EAP, le RADIUS et la décision de politique avant de configurer le SSID de production. Si une transition n'est pas claire, lancez le projet pilote à cet endroit en premier.
Vérifications préalables avant de manipuler le contrôleur
Un pilote Passpoint peut échouer avant même que quiconque n'ouvre le contrôleur. Commencez par la chaîne de dépendance : firmware AP, version du contrôleur, services d'identité, certificats, profils clients et capacité opérationnelle. Confirmez que le modèle exact d'AP et la branche logicielle prennent en charge Hotspot 2.0, ANQP, le mode WPA sélectionné et chaque champ Passpoint requis. La simple compatibilité d'une gamme de produits ne suffit pas.
Établissez une base de référence écrite succincte plutôt que de copier les paramètres d'un site à l'autre. Confirmez que la plateforme AAA prend en charge les méthodes EAP choisies, les attributs Passpoint, la comptabilisation et les réponses de politique. Testez l'accessibilité depuis chaque AP ou source de contrôleur qui participera au projet pilote. Dimensionnez RADIUS pour les pics d'authentification et de comptabilisation, et pas seulement pour le trafic moyen. Une incompatibilité de domaine échouera tout de même sur une plateforme surdimensionnée, tandis qu'un service sous-dimensionné peut masquer une configuration par ailleurs correcte.
Le plan de certificat nécessite le même traitement. Enregistrez l'autorité de certification émettrice, les ancres de confiance, le responsable du renouvellement et le chemin de révocation. Assurez-vous que le certificat serveur est approuvé par chaque appareil de test. Si l'organisation contrôle les certificats d'appareils et souhaite un accès sans mot de passe, EAP-TLS est généralement le choix approprié. EAP-TTLS convient à un processus contrôlé d'identifiant et de mot de passe. EAP-SIM ou EAP-AKA relève de conceptions de fédération gérées par l'opérateur ou par carte SIM, plutôt que de remplacer une stratégie de certificat d'entreprise.
Utilisez un groupe de clients tests représentatifs du site, incluant différents systèmes d'exploitation, fabricants de terminaux et profils managés. Ajoutez des appareils non managés ou non pris en charge pour vérifier ce que voient les utilisateurs lorsque l'authentification automatique n'est pas disponible. Le comportement du Captive Portal doit faire partie de ce test, car une politique de portail peut interférer avec un flux d'identité conçu pour utiliser un accès entreprise chiffré.
Avant la configuration, figez les valeurs d'identité. Saisissez le domaine NAI exactement comme le fournisseur d'identité l'attend, en respectant la casse, la ponctuation et les suffixes. Notez le choix du serveur OSU, la relation de fédération, les exigences RCOI, le propriétaire du certificat et le SSID de secours dans une liste de contrôle unique. Ces valeurs ne doivent pas rester uniquement dans les notes d'un ingénieur.
Planifiez le parc radio à partir du site réel, puis validez le nombre de bornes et la conception à l'aide d'un calculateur de points d'accès. La planification de la capacité révèle une conception surchargée avant la mise en service, mais elle ne peut pas corriger un domaine incompatible ou un certificat invalide.
Désactivez WEP et TKIP. Maintenez la conception de Passpoint sur WPA2-Enterprise ou WPA3-Enterprise, en excluant les modes de sécurité obsolètes.
Configuration spécifique aux fournisseurs pour Meraki, Aruba, Ruckus, Mist et UniFi
Les normes sont communes, mais l'expérience d'administration ne l'est pas. Les constructeurs exposent les mêmes primitives dans des profils différents, et certaines plateformes masquent la validation derrière des paramètres WLAN génériques. Traitez la configuration ci-dessous comme une carte des éléments à rechercher, puis confirmez chaque champ par rapport à la documentation exacte de la version utilisée.
| Fournisseur | Support Passpoint natif | Emplacement de téléchargement du certificat | OSU / Enrôlement | Erreur courante |
|---|---|---|---|---|
| Meraki | Paramètres Hotspot 2.0 sur l'SSID | Zone de certificat à l'échelle du réseau | Champs du fournisseur OSU dans le profil SSID | Un profil peut sembler complet alors que les valeurs de domaine ou de réseau d'accès restent incohérentes |
| Aruba | Profil Hotspot 2.0 associé à un SSID 802.1X | Magasin de certificats du contrôleur ou de mobilité | Intégration du profil et AAA | Les valeurs de domaine dérivées de l'AAA doivent être vérifiées et non supposées |
| Ruckus | Paramètres Passpoint dans le WLAN | Configuration du certificat SmartZone | Champs de lieu et d'OSU dans les paramètres WLAN | Les micrologiciels de points d'accès plus anciens peuvent omettre silencieusement les éléments ANQP |
| Juniper Mist | Passpoint via les modèles WLAN | Identité de l'organisation et configuration du certificat | Fournisseur d'identité et flux de travail des modèles | Un URI OSU mal formé peut créer des anomalies ANQP |
| UniFi | Support d'objet natif limité | Gestion des certificats RADIUS externes et spécifiques à la plateforme | Généralement externe ou improvisé | Les solutions de contournement personnalisées sont difficiles à gérer en tant que fédération de production |
Là où les implémentations divergent
Meraki est relativement direct pour un déploiement géré dans le cloud. Activez Hotspot 2.0 sur le SSID, définissez le type de réseau d'accès, le domaine, le domaine d'authentification et la méthode EAP, puis renseignez les informations du fournisseur OSU si nécessaire. Téléversez le certificat via le flux de travail des certificats réseau et inspectez l'annonce ANQP résultante plutôt que de vous fier au résumé du tableau de bord. Les organisations qui se standardisent sur Meraki devraient également examiner la gamme de points d'accès Cisco Meraki par rapport au micrologiciel prévu et aux exigences de profil client.
Aruba commence généralement par un WLAN 802.1X, un profil Hotspot 2.0 et une chaîne d'autorité de certification (CA) importée. L'élément crucial à vérifier est la relation entre le domaine dérivé du serveur AAA et le domaine annoncé via le profil. Les Mobility Conductors et les contrôleurs distribués ajoutent un niveau supplémentaire de complexité où l'héritage de la configuration peut échouer.
Ruckus SmartZone nécessite une attention particulière concernant l'alignement du firmware du WLAN et des AP. Ajoutez le profil Passpoint, le certificat signé et les détails du site, puis capturez les réponses ANQP d'un AP actif. Un tableau de bord affichant les paramètres activés ne garantit pas qu'un AP plus ancien transmet ces mêmes éléments.
Juniper Mist centralise la configuration au niveau des modèles WLAN et des paramètres d'identité de l'organisation. Le processus est fluide lorsque le fournisseur d'identité et les valeurs OSU sont valides, mais des URI d'enrôlement mal formés ont tendance à se manifester sous forme d'anomalies de découverte plutôt que par un message d'erreur de configuration explicite.
UniFi représente le cas difficile. Sans un objet Passpoint natif complet, les équipes doivent souvent assembler un serveur RADIUS externe, des noms d'hôte personnalisés et des solutions de contournement de politique partielles. Bien que cela puisse convenir pour des phases de test, cette approche crée trop de limites de responsabilité pour un hôpital réglementé, un grand groupe hôtelier ou une fédération d'itinérance.
Réalité du fournisseur : Un statut de configuration vert signifie que l'objet a été accepté par le contrôleur. Cela ne prouve pas qu'un client peut le découvrir, lui faire confiance, s'authentifier et l'utiliser pour l'itinérance.
Certificats, RADIUS et configuration de la couche d'identité
Un déploiement Passpoint peut s'associer avec succès tout en échouant au niveau de la couche d'identité. Commencez par l'identité du serveur que les appareils clients devront valider. Générez un CSR avec les noms alternatifs de sujet requis pour le domaine de service et l'espace de noms d'identité. Utilisez une CA publique déjà approuvée par le parc d'appareils, ou distribuez une chaîne de confiance privée via vos outils de gestion de flotte.
Importez le certificat et la chaîne intermédiaire dans l'ordre requis par le contrôleur. Une chaîne intermédiaire manquante apparaît généralement à l'utilisateur comme un mot de passe incorrect. Après chaque modification de certificat, effectuez un test depuis un véritable appareil client, inspectez la chaîne présentée et associez le résultat aux journaux d'authentification du contrôleur. Une vérification dans un navigateur de laboratoire ne suffit pas.
Construire le chemin RADIUS
Le serveur RADIUS est le point de décision de politique pour l'identité Passpoint, et pas seulement un simple validateur de mot de passe. FreeRADIUS, Cisco ISE, ClearPass et Microsoft NPS diffèrent dans leur prise en charge de l'EAP et la syntaxe de leurs politiques. Documentez la méthode sélectionnée, les vérifications de certificats, la gestion des domaines et le mappage des attributs avant l'implémentation.
- EAP-TLS : associez le sujet du certificat client ou le SAN à la fiche de l'appareil ou de l'utilisateur, appliquez la confiance en l'émetteur et définissez la gestion de la révocation.
- EAP-TTLS : protégez l'échange externe avec le certificat du serveur, puis associez l'identité interne au domaine et à la politique appropriés.
- EAP basé sur SIM : vérifiez que l'opérateur ou la fédération fournit la validation de l'abonné et que le niveau RADIUS peut la traiter.
- Politique de domaine : assurez-vous qu'une valeur telle que
@corp.example.comatteint le fournisseur d'identité prévu sans dérive de casse ou de formatage.
La capacité du RADIUS nécessite une analyse distincte. L'authentification par certificat et l'accounting génèrent des profils de requêtes différents du 802.1X ordinaire. Les pics d'enregistrement et de reconnexion peuvent révéler des problèmes de latence, de file d'attente et de dépassement de délai, en particulier dans un hôtel, un hôpital ou un stade. Utilisez des serveurs redondants, mesurez la latence de réponse et testez le comportement en cas de panne plutôt que de supposer que le réseau WLAN existant du personnel dispose d'une capacité excédentaire.
Un modèle managé de RADIUS-as-a-Service peut réduire la charge opérationnelle, mais vérifiez la prise en charge des méthodes EAP requises, des contrôles de politique, de la journalisation et du cycle de vie des certificats avant de faire votre choix.
Ajoutez délibérément les détails de la fédération
L'OpenRoaming exige que le lieu d'implantation, l'identité du fournisseur de services et les identifiants de fédération s'accordent à travers le profil, le système de politique et la relation d'itinérance. Les directives de déploiement et d'implémentation Passpoint couvrent les domaines NAI, le déploiement de certificats et l'enregistrement RCOI en tant que tâches de la couche d'identité. Les identifiants d'itinérance courants incluent le RCOI sans règlement financier 5A-03-BA et le RCOI Cisco hérité 00-40-96 lorsqu'une compatibilité plus large est requise.
Après avoir téléchargé le profil, rechargez les composants du contrôleur concernés et inspectez les balises et les réponses ANQP en direct. Confirmez que le domaine annoncé, les informations sur le lieu, l'RCOI et l'OSU NAI sont corrects. Vérifiez également qu'aucun Captive Portal n'est associé au même chemin de service, car il pourrait intercepter l'enregistrement ou entrer en conflit avec un profil qui s'attend à une authentification directe.
Le fichier de configuration n'est qu'une entrée. Le paquet transmis par voie aérienne constitue la vérification finale.
Pilote, validation et seuils de mise en production
Lancez le projet pilote comme un exercice de mesure. Sélectionnez un étage, un service ou un hall, conservez un accès 802.1X existant et utilisez un groupe fixe d'appareils dont vous connaissez les propriétaires et les versions du système d'exploitation. Intégrez à la fois des clients gérés par certificat et les appareils des visiteurs susceptibles de révéler des problèmes de profil et de secours.
Avant d'activer le SSID, définissez les critères d'acceptation par écrit :
- Découverte : Chaque point d'accès de test doit annoncer l'indication HS2.0 et les éléments ANQP requis.
- Association : Les identifiants mis en cache doivent s'associer en moins de trois secondes lors du test contrôlé.
- Authentification : Le niveau RADIUS ne doit présenter aucun délai d'attente lors des pics de demande attendus.
- Solution de secours : Les appareils ne disposant pas d'un profil compatible doivent recevoir une alternative documentée, plutôt que de tourner en boucle sur un portail défectueux.
- Itinérance : Testez le mouvement de point d'accès à point d'accès à intervalles réguliers, puis répétez l'opération sur l'ensemble des contrôleurs avec le domaine de mobilité configuré.
Capturez des preuves à trois niveaux différents. Utilisez un point d'accès en mode moniteur ou une capture de paquets équivalente pour inspecter le trafic balise (beacon), GAS et ANQP. Exportez les journaux RADIUS contenant les identifiants de requête et les attributs de réponse. Collectez les journaux du système d'exploitation de chaque appareil de test, en particulier lorsqu'un fabricant de téléphones réussit là où un autre refuse le même profil.
Le guide de la WiFi Alliance recommande de vérifier la capacité des AP et des contrôleurs, la préparation RADIUS et la compatibilité EAP avant le déploiement. Un guide d'expert pratique recommande un projet pilote sur 10 % à 20 % des AP, avec un taux de réussite de connexion supérieur à 98 % et une latence d'authentification inférieure à 300 millisecondes comme indicateurs de validation ou d'arrêt. Ces seuils doivent être testés par rapport à la tolérance au risque de l'entreprise, mais ils fournissent une discipline concrète pour l'expansion.
Ne déployez pas à plus grande échelle simplement parce que la première matinée s'est bien déroulée. Maintenez le projet pilote actif pendant les périodes d'activité normale, examinez les journaux d'itinérance et d'erreur, puis appliquez les correctifs documentés au site suivant.
Dépannage et modes de défaillance du dernier kilomètre
Les pannes les plus complexes apparaissent une fois que la configuration semble terminée. Passpoint dépend de la synchronisation parfaite entre le client, le point d'accès, le profil, la chaîne de confiance et la politique RADIUS. Un Captive Portal ne peut pas résoudre un échec d'échange Passpoint car les SSIDs compatibles Passpoint ne prennent pas en charge les redirections de portail comme mécanisme d'authentification.
| Mode de défaillance | Symptôme | Signal de diagnostic | Résolution |
|---|---|---|---|
| Incohérence de domaine (Realm) | Le client ignore le réseau ou bascule sur un autre SSID | Comparer le domaine NAI annoncé dans ANQP avec le domaine de la requête RADIUS | Normaliser les chaînes de domaine et les valeurs de profil, y compris la casse et les suffixes |
| Chaîne de certificats corrompue | Échec de l'EAP-TLS malgré un certificat client valide | Les journaux RADIUS EAP indiquent des erreurs de validation de confiance ou de chaîne | Reconstruire la chaîne servie, confirmer les certificats intermédiaires et tester à partir du système d'exploitation du client |
| Éléments ANQP manquants | Les appareils ne reconnaissent pas le SSID comme un réseau Passpoint adapté | La capture de paquets montre l'absence d'indication HS2.0 ou une réponse ANQP incomplète | Vérifier le micrologiciel de l'AP, l'héritage du contrôleur et la balise de diffusion active |
| Saturation RADIUS | L'authentification ralentit ou échoue lors des pics de connexion | Augmentation de la latence des requêtes, retransmissions ou taille de la file d'attente dans les journaux RADIUS | Ajouter de la capacité et de la redondance, puis retester la charge des certificats et de l'accounting |
| Conflit de Captive Portal | Les clients compatibles se connectent de manière instable ou ne finalisent jamais l'accès | Le débogage du contrôleur montre une politique de portail associée au SSID Passpoint | Séparer les politiques Passpoint et de portail, avec un SSID hérité explicite |
| Variabilité des appareils | Une gamme de téléphones effectue l'itinérance tandis qu'une autre reste connectée ou refuse la connexion | Comparer les journaux du système d'exploitation, la prise en charge des profils et la gestion RCOI par type d'appareil | Maintenir une matrice d'appareils testés et publier des instructions de secours |
Vérifiez d'abord l'annonce radio en direct, puis le profil client, la confiance du certificat, la requête RADIUS et la réponse de politique. Cet ordre évite de passer des heures à modifier les règles du serveur lorsque l'AP n'a jamais annoncé l'indication HS2.0 requise.
Les flottes mixtes nécessitent une transition réfléchie. Conservez un accès hérité WPA2-Enterprise ou EAP-TTLS disponible pour les appareils qui ne peuvent pas consommer le profil Passpoint, mais ne placez pas de logique de Captive Portal sur l'SSID Passpoint. L'enquête de participation publique du DSIT pour 2025 à 2026 (DSIT public engagement survey for 2025 to 2026) indique que 31 % des adultes utilisent des données mobiles ou un hotspot à domicile, tandis que 3 % s'appuient sur cette solution comme méthode principale d'accès à la maison. Cela suggère que les utilisateurs sont familiarisés avec la connectivité assistée par mobile, mais les gestionnaires de sites ont toujours besoin d'une solution de secours simple pour les clients dont le téléphone, l'identifiant d'opérateur ou le système d'exploitation ne prend pas en charge le profil prévu de manière cohérente.
Les appareils Apple et Android peuvent également interpréter les indices d'itinérance différemment. Testez chaque gamme d'appareils prise en charge, ne déduisez pas la compatibilité de la simple présence d'un paramètre Passpoint. Lorsqu'un déploiement auparavant stable tombe en panne, comparez les dernières modifications de certificat, de profil, de firmware, de domaine et de politique RADIUS avant de reconstruire le WLAN.
Purple propose le WiFi Passpoint via sa plateforme SecurePass, en utilisant un enregistrement basé sur des profils et des certificats pour une authentification automatique sur l'ensemble des réseaux pris en charge. Si vous souhaitez évaluer cette approche de couche d'identité parallèlement à votre infrastructure AP et RADIUS existante, visitez Purple et discutez du périmètre pilote, de la variété des appareils et des exigences de repli avec son équipe.
