Un invitado llega a un hotel, selecciona el WiFi del establecimiento, espera a que aparezca el Captive Portal, acepta las condiciones, introduce una dirección de correo electrónico y repite el proceso en el centro de conferencias de al lado. En un hospital, el iPad gestionado y el terminal VoWiFi de un médico pueden moverse entre puntos de acceso llevando perfiles diferentes. En un estadio, miles de dispositivos compiten por el tiempo de emisión mientras la página de inicio de sesión se convierte en otro punto de fallo.
La configuración de Passpoint WiFi aborda esa fricción trasladando las decisiones de acceso a la capa de identidad. Los dispositivos compatibles descubren la red, evalúan sus credenciales anunciadas y la información de roaming, y luego se autentican a través de la seguridad WiFi corporativa en lugar de depender de una contraseña compartida o una página de inicio. El resultado puede ser una incorporación y un roaming automáticos en múltiples centros que confían en el mismo proveedor de identidad.
Ese resultado no se consigue simplemente marcando una casilla de verificación de Hotspot 2.0. Depende del firmware del AP, de los anuncios 802.11u y ANQP, los métodos EAP, los certificados, los reinos NAI, la capacidad de RADIUS, el soporte de dispositivos y el diseño de contingencia. El enfoque práctico consiste en auditar la infraestructura, realizar una prueba piloto en una sección controlada, registrar lo que falla y expandirse únicamente cuando las pruebas lo respalden.
Por qué es importante la configuración de Passpoint WiFi para las redes corporativas
Los hoteles, hospitales y estadios exponen rápidamente las debilidades del WiFi para invitados convencional. Un hotel puede necesitar dar soporte a cientos de dispositivos diferentes en visitas repetidas, mientras que un hospital cuenta con dispositivos clínicos compartidos, terminales de personal y visitantes con proveedores de identidad no relacionados. Un estadio presenta una demanda densa e impredecible y muy poca tolerancia a un flujo de inicio de sesión que falla cuando los usuarios se desplazan por las entradas o cambian de zona de asientos.
Los portales cautivos son útiles cuando un operador necesita consentimiento o datos de marketing, pero crean una carga operativa independiente. Los SSID por centro obligan a los usuarios a elegir las redes manualmente, las contraseñas compartidas se difunden más allá del público previsto y las redirecciones de los portales pueden fallar debido al comportamiento del navegador, advertencias de certificados o malas condiciones de radio. La autenticación repetida se vuelve especialmente molesta cuando un usuario pasa de un controlador o edificio a otro.
Qué sustituye un despliegue operativo
Passpoint utiliza la detección 802.11u, la información de red ANQP y la autenticación basada en EAP para permitir que un dispositivo determine si tiene un perfil válido antes de asociarse. Con las credenciales correctas, el dispositivo puede conectarse sin tener que volver a introducir la contraseña. WPA2 o WPA3 empresarial proporciona entonces el modelo de seguridad esperado para el acceso basado en identidad.
Los beneficios operativos son prácticos más que estéticos:
- Menor administración de credenciales: el personal no tiene que restablecer una contraseña de invitado compartida cada vez que aparece en un aviso público.
- Menos dependencias de portal: un dispositivo compatible no necesita cargar una página de bienvenida antes de obtener acceso a la red.
- Mejor continuidad multisitio: un perfil puede reconocer redes de confianza asociadas con el mismo dominio o relación de itinerancia.
- Control de acceso más limpio: las políticas de RADIUS pueden distinguir usuarios, dispositivos y proveedores de identidad en lugar de tratar a cada cliente como un miembro anónimo de un solo SSID.
El Reino Unido ya cuenta con un punto de referencia relevante en el sector público. El servicio oficial GovWifi proporciona un único nombre de usuario y contraseña para el personal y los visitantes en todo el sector público, y la Government Property Agency afirma que ofrece servicio a más de 850.000 personas en todo el Reino Unido. GovWifi también conecta a los usuarios automáticamente en miles de edificios que ofrecen el servicio. No es la misma implementación que Passpoint, pero demuestra que la autenticación centralizada y el acceso multisitio son prácticas operativas consolidadas, no ideas de laboratorio.
Trate el proyecto como ingeniería de identidad
La primera decisión de diseño es si Passpoint dará servicio a dispositivos gestionados del personal, acceso público para invitados, descarga de tráfico de operadores o una federación como OpenRoaming. Cada caso de uso cambia la fuente de credenciales, el método EAP, el modelo de políticas y la experiencia de respaldo.
El informe de la Wireless Broadband Alliance cubierto por Comms Business reveló que el 81% de los encuestados planeaba implementaciones de OpenRoaming, con motivaciones que incluyen el acceso celular y WiFi, una seguridad mejorada, un acceso sin fricciones y la continuidad a través de las redes. Esas cifras no eliminan el trabajo de ingeniería. Muestran por qué los operadores están invirtiendo en ello, mientras que la implementación sigue dependiendo de la configuración exacta de la identidad y la confianza.
Comprensión de la pila de Passpoint
Passpoint es un sistema de capa de identidad, no una casilla de verificación en el controlador inalámbrico. La resolución de problemas es mucho más rápida cuando cada capa tiene una función definida. El punto de acceso anuncia suficiente información para que un dispositivo decida si la red coincide con un perfil instalado. El dispositivo selecciona una credencial compatible e inicia la autenticación empresarial. RADIUS toma la decisión de autorización, mientras que los certificados y los dominios de identidad determinan si el cliente y el servidor confían mutuamente.
En la capa de radio y descubrimiento, IEEE 802.11u proporciona el descubrimiento de redes antes de la asociación normal. El punto de acceso utiliza GAS para transportar consultas y respuestas ANQP. ANQP puede publicar el tipo de acceso de la red, nombres de dominio, reinos NAI, identificadores de roaming, información del centro, datos relacionados con la telefonía móvil y métricas WAN. El cliente compara esos valores con los perfiles ya instalados en el dispositivo.
El camino práctico es:
- Indicación de baliza (beacon) y 802.11u: El AP señala que la información de Hotspot 2.0 está disponible.
- Intercambio GAS y ANQP: El cliente pregunta qué identidades, dominios (realms), socios de roaming y servicios admite la red.
- Coincidencia de perfil: El dispositivo compara los valores anunciados con su perfil de Passpoint.
- Autenticación EAP: El dispositivo se autentica a través de 802.1X, normalmente utilizando EAP-TLS, EAP-TTLS, EAP-SIM o EAP-AKA, según la implementación.
- Autorización RADIUS: El AP o controlador reenvía la solicitud y aplica la política devuelta.
- Asociación cifrada: El cliente se conecta a través de WPA2 o WPA3 corporativo (WPA2-Enterprise o WPA3-Enterprise), sin depender de un Captive Portal.
La guía de despliegue de WiFi Alliance identifica la indicación HS2.0 en la baliza del punto de acceso como un requisito previo. Si un cliente no puede detectar esa indicación, no iniciará el descubrimiento de Passpoint, independientemente de lo minuciosamente que se haya configurado RADIUS.
EAP-TLS utiliza certificados de cliente y, por lo general, se adapta a flotas gestionadas porque la organización puede emitir, renovar y revocar las credenciales de los dispositivos. EAP-TTLS admite flujos de trabajo de usuario y contraseña, pero la identidad interna y el certificado del servidor siguen requiriendo una protección minuciosa. Los métodos EAP basados en SIM se adaptan a implementaciones de operadores o federadas donde la suscripción móvil proporciona la credencial.
El dominio NAI identifica el dominio de identidad responsable de una solicitud. Los RCOI identifican los consorcios de itinerancia y ayudan a los clientes a decidir si una red pertenece a una relación de servicio de confianza. Un servidor OSU puede aprovisionar credenciales para flujos de inscripción compatibles, mientras que un servidor de políticas puede conectar el espacio a una federación y aplicar reglas de socios.
Las versiones de Passpoint van más allá de la detección. Hotspot 2.0 versión 2 y versión 3 admiten el registro en línea y el aprovisionamiento de políticas, pero cada función añadida crea otro punto de configuración. Un URI de OSU con formato incorrecto, una cadena de certificados incompleta o un dominio que difiera por un solo carácter pueden detener la asociación. La configuración del Captive Portal también puede entrar en conflicto con un flujo de identidad que espera un acceso empresarial cifrado.
Regla de ingeniería: Trace la ruta desde el beacon hasta el ANQP, el perfil, el EAP, el RADIUS y la decisión de política antes de configurar el SSID de producción. Si una transferencia no está clara, ejecute la prueba piloto allí primero.
Comprobaciones previas antes de tocar el controlador
Un piloto de Passpoint puede fallar antes de que alguien abra el controlador. Comience con la cadena de dependencias: firmware del AP, versión del controlador, servicios de identidad, certificados, perfiles de cliente y capacidad de operaciones. Confirme que el modelo exacto de AP y la rama de software admiten Hotspot 2.0, ANQP, el modo WPA seleccionado y cada campo obligatorio de Passpoint. La compatibilidad de la familia de productos no es suficiente.
Cree una pequeña línea de base por escrito en lugar de copiar configuraciones entre sitios. Confirme que la plataforma AAA es compatible con los métodos EAP elegidos, los atributos de Passpoint, la contabilidad y las respuestas de políticas. Pruebe la accesibilidad desde cada AP o controlador de origen que participará en el piloto. Dimensione RADIUS para picos de autenticación y contabilidad, no solo para el tráfico promedio. Un desajuste de dominios seguirá fallando en una plataforma sobredimensionada, mientras que un servicio sobredimensionado a la baja puede ocultar una configuración que de otro modo sería correcta.
El plan de certificados necesita el mismo tratamiento. Registre la CA emisora, las anclas de confianza, el responsable de la renovación y la ruta de revocación. Asegúrese de que el certificado de servidor sea de confianza para todos los dispositivos de prueba. Si la organización controla los certificados de los dispositivos y desea un acceso sin contraseñas, EAP-TLS suele ser la opción adecuada. EAP-TTLS se adapta a un proceso controlado de nombre de usuario y contraseña. EAP-SIM o EAP-AKA pertenecen a diseños de federación respaldados por operadores o SIM, en lugar de reemplazar una estrategia de certificados empresariales.
Utilice un grupo de clientes de prueba conocido que represente el sitio, incluidos los sistemas operativos, los fabricantes de terminales y los perfiles gestionados. Añada dispositivos no gestionados o no compatibles para comprobar qué ven los usuarios cuando la autenticación automática no está disponible. El comportamiento del Captive Portal debe incluirse en esta prueba, ya que una política de portal puede interferir con un flujo de identidad diseñado para utilizar un acceso empresarial cifrado.
Antes de la configuración, congele los valores de identidad. Escriba el dominio NAI exactamente como lo espera el proveedor de identidad, incluyendo mayúsculas y minúsculas, puntuación y sufijos. Registre la decisión del servidor OSU, la relación de federación, los requisitos de RCOI, el propietario del certificado y el SSID de respaldo en una única lista de comprobación. Estos valores no deben quedar guardados únicamente en las notas de un ingeniero.
Planifique la infraestructura de radio desde el propio recinto y, a continuación, valide el número de puntos de acceso y el diseño con una calculadora de puntos de acceso. La planificación de capacidad revela un diseño sobrecargado antes del despliegue, pero no puede corregir un dominio mal emparejado o un certificado no válido.
Desactive WEP y TKIP. Mantenga el diseño de Passpoint en WPA2-Enterprise o WPA3-Enterprise, excluyendo los modos de seguridad heredados.
Configuración específica del proveedor para Meraki, Aruba, Ruckus, Mist y UniFi
Los estándares son compartidos, pero la experiencia administrativa no lo es. Los proveedores exponen las mismas primitivas en perfiles diferentes y algunas plataformas ocultan la validación detrás de ajustes genéricos de WLAN. Trate la configuración siguiente como un mapa de dónde buscar, y luego confirme cada campo con la documentación exacta de la versión en uso.
| Proveedor | Soporte nativo de Passpoint | Ubicación de carga del certificado | OSU / Onboarding | Error común |
|---|---|---|---|---|
| Meraki | Ajustes de Hotspot 2.0 en el SSID | Área de certificados a nivel de red | Campos del proveedor OSU en el perfil de SSID | Un perfil puede parecer completo mientras que los valores de dominio o de red de acceso siguen siendo inconsistentes |
| Aruba | Perfil de Hotspot 2.0 adjunto a un SSID 802.1X | Almacén de certificados del controlador o de movilidad | Integración de perfil y AAA | Los valores de dominio derivados de AAA necesitan verificación, no suposición |
| Ruckus | Ajustes de Passpoint en la WLAN | Configuración de certificados de SmartZone | Campos de ubicación y OSU en los ajustes de WLAN | El firmware antiguo del AP puede omitir silenciosamente los elementos ANQP |
| Juniper Mist | Passpoint a través de plantillas de WLAN | Configuración de certificado e identidad de la organización | Proveedor de identidad y flujo de trabajo de plantillas | Un URI de OSU con formato incorrecto puede crear anomalías en ANQP |
| UniFi | Soporte nativo limitado de objetos | RADIUS externo y gestión de certificados específica de la plataforma | Normalmente externo o improvisado | Las soluciones personalizadas son difíciles de gobernar como federación de producción |
Donde las implementaciones difieren
Meraki es comparativamente directo para un despliegue gestionado en la nube. Habilite Hotspot 2.0 en el SSID, configure el tipo de acceso a la red, el dominio, el dominio de identidad (realm) y el método EAP, y luego introduzca la información del proveedor de OSU cuando sea necesario. Cargue el certificado a través del flujo de trabajo de certificados de red e inspeccione el anuncio ANQP resultante en lugar de confiar en el resumen del panel de control. Las organizaciones que se estandaricen con Meraki también deberían revisar la gama de puntos de acceso de Cisco Meraki en relación con los requisitos previstos de firmware y perfiles de cliente.
Aruba normalmente comienza con una WLAN 802.1X, un perfil Hotspot 2.0 y una cadena de CA importada. La comprobación importante es la relación entre el dominio derivado del servidor AAA y el dominio anunciado a través del perfil. Los Mobility Conductors y los controladores distribuidos añaden otro punto donde la herencia de la configuración puede fallar.
Ruckus SmartZone requiere prestar mucha atención a la alineación del firmware de la WLAN y el punto de acceso. Añada el perfil de Passpoint, el certificado firmado y los detalles del recinto, y luego capture las respuestas ANQP de un punto de acceso actual. Un panel que muestra los ajustes activados no demuestra que un punto de acceso más antiguo esté transmitiendo los mismos elementos.
Juniper Mist enfoca el trabajo en las plantillas WLAN y en la configuración de identidad a nivel de organización. Puede resultar sencillo cuando el proveedor de identidad y los valores de OSU son válidos, pero las URI de registro mal formadas suelen manifestarse como anomalías de descubrimiento en lugar de como un error de configuración claro.
UniFi es el caso difícil. Sin un objeto Passpoint nativo completo, los equipos a menudo combinan un RADIUS externo, nombres de host personalizados y soluciones alternativas de políticas parciales. Esto puede ser aceptable para experimentar, pero crea demasiados límites de propiedad para un hospital regulado, un gran grupo hotelero o una federación de itinerancia.
Realidad del proveedor: Un estado de configuración verde significa que el objeto fue aceptado por el controlador. No demuestra que un cliente pueda descubrir, confiar, autenticarse y realizar roaming a través de él.
Certificados, RADIUS y configuración de la capa de identidad
Un despliegue de Passpoint puede asociarse correctamente pero fallar en la capa de identidad. Comience con la identidad del servidor que validarán los dispositivos cliente. Genere un CSR con los nombres alternativos de sujeto requeridos para el dominio de servicio y el espacio de nombres de identidad. Utilice una CA pública en la que ya confíe la base de dispositivos, o distribuya una cadena de confianza privada a través de herramientas de gestión de dispositivos.
Importe el certificado y la cadena intermedia en la secuencia requerida por el controlador. La falta de un certificado intermedio suele aparecer ante el usuario como una contraseña incorrecta. Después de cada cambio de certificado, realice una prueba desde un dispositivo cliente real, inspeccione la cadena presentada y correlacione el resultado con los registros de autenticación del controlador. Una comprobación con un navegador de laboratorio no es suficiente.
Construya la ruta RADIUS
RADIUS es el punto de decisión de políticas para la identidad de Passpoint, no un simple validador de contraseñas. FreeRADIUS, Cisco ISE, ClearPass y Microsoft NPS difieren en el soporte de EAP y en la sintaxis de las políticas. Registre el método seleccionado, las comprobaciones de certificados, la gestión de dominios y el mapeo de atributos antes de la implementación.
- EAP-TLS: asocie el firmante del certificado de cliente o el SAN al registro del dispositivo o usuario, aplique la confianza del emisor y defina la gestión de revocación.
- EAP-TTLS: proteja el intercambio externo con el certificado del servidor y, a continuación, asocie la identidad interna con el dominio y la política correctos.
- EAP respaldado por SIM: confirme que el operador o la federación proporcionan la validación del suscriptor y que el nivel de RADIUS puede procesarla.
- Política de dominio: asegúrese de que un valor como
@corp.example.comllegue al proveedor de identidad previsto sin alteraciones de mayúsculas o formato.
La capacidad de RADIUS necesita una revisión independiente. La autenticación de certificados y la contabilidad producen patrones de solicitud diferentes a los de un 802.1X ordinario. Los picos de incorporación y reconexión pueden exponer problemas de latencia, colas y tiempos de espera, especialmente en un hotel, hospital o estadio. Utilice servidores redundantes, mida la latencia de respuesta y pruebe el comportamiento ante fallos en lugar de asumir que el nivel de WLAN del personal existente tiene capacidad de sobra.
Un modelo gestionado de RADIUS-as-a-Service puede reducir la carga operativa, pero verifique la compatibilidad con los métodos EAP requeridos, los controles de políticas, el registro y el ciclo de vida de los certificados antes de elegirlo.
Añada los detalles de la federación de forma deliberada
OpenRoaming requiere que la identidad del recinto, del proveedor de servicios y los identificadores de federación coincidan en todo el perfil, el sistema de políticas y la relación de itinerancia. Las directrices de despliegue e implementación de Passpoint cubren los dominios NAI, el despliegue de certificados y el registro de RCOI como tareas de la capa de identidad. Los identificadores de itinerancia comunes incluyen el RCOI sin liquidación 5A-03-BA y el RCOI heredado de Cisco 00-40-96 cuando se requiere una compatibilidad más amplia.
Después de cargar el perfil, reinicie los componentes relevantes del controlador e inspeccione las respuestas de baliza y ANQP en directo. Confirme que el dominio anunciado, la información del lugar, el RCOI y el NAI de OSU son correctos. Compruebe también si hay un Captive Portal asociado a la misma ruta de servicio, ya que puede interceptar la incorporación o entrar en conflicto con un perfil que espera autenticación directa.
El archivo de configuración es solo una entrada. El paquete transmitido por el aire es la comprobación final.
Piloto, validación y umbrales de puesta en marcha
Ejecute el piloto como un ejercicio de medición. Seleccione una sola planta, departamento o vestíbulo, mantenga disponible una ruta heredada de 802.1X y utilice un grupo fijo de dispositivos cuya propiedad y versiones de sistema operativo sean conocidas. Incluya tanto clientes gestionados por certificado como los dispositivos de visitantes que tienen más probabilidades de revelar problemas de perfil y de respaldo.
Antes de activar el SSID, defina los criterios de aceptación por escrito:
- Descubrimiento: Cada AP de prueba debe anunciar la indicación HS2.0 y los elementos ANQP requeridos.
- Asociación: Las credenciales almacenadas en caché deben asociarse en menos de tres segundos durante la prueba controlada.
- Autenticación: El nivel de RADIUS no debe mostrar tiempos de espera agotados ante la demanda máxima prevista.
- Alternativa: Los dispositivos que carezcan de un perfil compatible deben recibir una alternativa documentada, en lugar de entrar en un bucle a través de un portal defectuoso.
- Roaming: Pruebe el movimiento de AP a AP a intervalos regulares y luego repítalo en todos los controladores con el dominio de movilidad configurado.
Capture pruebas en tres puntos. Utilice un AP en modo monitor o una captura de paquetes equivalente para inspeccionar el tráfico de balizas, GAS y ANQP. Exporte los registros de RADIUS con identificadores de solicitud y atributos de respuesta. Recopile registros del sistema operativo de cada dispositivo de prueba, especialmente allí donde el fabricante de un terminal tiene éxito y otro rechaza el mismo perfil.
Las directrices de la WiFi Alliance recomiendan verificar la capacidad del AP y del controlador, la preparación de RADIUS y la compatibilidad con EAP antes del despliegue. Un manual de expertos práctico recomienda realizar una prueba piloto en el 10% al 20% de los AP, con un éxito de conexión superior al 98% y una latencia de autenticación inferior a 300 milisegundos como indicadores para proceder o no. Esos umbrales deben probarse frente a la tolerancia al riesgo de la propia organización, pero proporcionan una disciplina concreta para la expansión.
No amplíe la implementación solo porque la primera mañana haya ido bien. Mantenga el piloto en funcionamiento durante los periodos de actividad habituales, revise los registros de itinerancia y de fallos, y luego traslade las correcciones documentadas al siguiente centro.
Resolución de problemas y modos de fallo de última milla
Los fallos más difíciles aparecen después de que la configuración parece terminada. Passpoint depende de que el cliente, el AP, el perfil, la cadena de confianza y la política RADIUS coincidan en el mismo momento. Un Captive Portal no puede reparar un intercambio de Passpoint fallido porque los SSID habilitados para Passpoint no admiten redirecciones de portal como mecanismo de autenticación.
| Modo de fallo | Síntoma | Señal de diagnóstico | Resolución |
|---|---|---|---|
| Discrepancia de dominio (realm) | El cliente ignora la red o recurre a otro SSID | Compare el dominio NAI anunciado en ANQP con el dominio en la solicitud RADIUS | Normalice las cadenas de dominio y los valores de perfil, incluyendo mayúsculas y sufijos |
| Cadena de certificación rota | EAP-TLS falla a pesar de tener un certificado de cliente válido | Los registros EAP de RADIUS muestran errores de confianza o de validación de cadena | Vuelva a generar la cadena servida, confirme los certificados intermedios y realice pruebas desde el SO del cliente |
| Faltan elementos ANQP | Los dispositivos no reconocen el SSID como una red Passpoint adecuada | La captura de paquetes muestra la ausencia de indicación HS2.0 o una respuesta ANQP incompleta | Verifique el firmware del AP, la herencia del controlador y la baliza (beacon) activa |
| Saturación de RADIUS | La autenticación se ralentiza o falla durante picos de incorporación | Aumento de la latencia de solicitudes, retransmisiones o longitud de la cola en los registros de RADIUS | Añada capacidad y redundancia, luego vuelva a probar la carga de certificados y contabilidad (accounting) |
| Conflicto con el Captive Portal | Los clientes compatibles se conectan de forma inconsistente o nunca completan el acceso | La depuración del controlador muestra la política de portal asignada al SSID de Passpoint | Separe las políticas de Passpoint y de portal, con un SSID heredado explícito |
| Variación según el dispositivo | Una familia de terminales realiza el roaming mientras que otra permanece conectada o lo rechaza | Compare los registros del SO, la compatibilidad de perfiles y la gestión de RCOI por tipo de dispositivo | Mantenga una matriz de dispositivos probados y publique instrucciones alternativas |
Compruebe primero el anuncio de radio en vivo, luego el perfil del cliente, la confianza del certificado, la solicitud de RADIUS y la respuesta de la política. Ese orden evita pasar horas cambiando las reglas del servidor cuando el AP nunca anunció la indicación HS2.0 requerida.
Las flotas mixtas necesitan una transición intencionada. Mantenga el acceso heredado WPA2-Enterprise o EAP-TTLS disponible para los dispositivos que no puedan consumir el perfil de Passpoint, pero no coloque lógica de Captive Portal en el SSID de Passpoint. El estudio de participación pública de la DSIT para 2025 a 2026 informa que el 31% de los adultos utilizan datos móviles o un punto de acceso en casa, mientras que el 3% depende de ello como su método principal de acceso en el hogar. Esto sugiere que los usuarios están familiarizados con la conectividad asistida por móviles, pero los operadores de las instalaciones aún necesitan una alternativa sencilla para los clientes cuyo terminal, identificador de operador o sistema operativo no soporte el perfil previsto de manera constante.
Los dispositivos Apple y Android también pueden interpretar las indicaciones de itinerancia de forma diferente. Pruebe cada familia compatible, no infiera la compatibilidad por la presencia de un ajuste de Passpoint. Cuando un despliegue que antes funcionaba correctamente falle, compare los últimos cambios en certificados, perfiles, firmware, dominios y políticas de RADIUS antes de reconstruir la WLAN.
Purple ofrece WiFi Passpoint a través de su plataforma SecurePass, utilizando una incorporación basada en perfiles y certificados para la autenticación automática en las redes compatibles. Si desea evaluar este enfoque de capa de identidad junto con su diseño de AP y RADIUS existente, visite Purple y analice el alcance del piloto, la combinación de dispositivos y los requisitos de respaldo con su equipo.
