Okta y RADIUS: Extensión de su proveedor de identidad a la autenticación WiFi

Resumen ejecutivo

Para los equipos de TI de empresas que gestionan ubicaciones distribuidas - desde cadenas hoteleras hasta estadios -, unificar el control de acceso a la red con un proveedor de identidad en la nube es un paso crítico hacia Zero Trust. El agente Okta RADIUS cierra la brecha entre la identidad en la nube moderna y la infraestructura WiFi 802.1X tradicional, lo que permite a las organizaciones dejar de utilizar los servidores RADIUS locales heredados y la infraestructura de Active Directory para la autenticación de red.

Esta guía detalla cómo implementar el agente Okta RADIUS para la autenticación de WiFi corporativa, cubriendo la arquitectura proxy, los mecanismos de aplicación de MFA y las diferencias entre EAP-TTLS basado en contraseña y EAP-TLS basado en certificados. También proporciona orientación práctica sobre cómo mapear la pertenencia a grupos de Okta con atributos RADIUS para la asignación dinámica de VLAN, una capacidad que respalda directamente los requisitos de segmentación de red de PCI-DSS. Al integrar Okta para la autenticación del personal junto con las soluciones de WiFi para invitados, los operadores de las instalaciones pueden lograr una capa de acceso unificada, segura y conforme a las normativas sin duplicar la infraestructura de identidad.

Análisis técnico detallado

Cómo funciona el agente Okta RADIUS

El agente Okta RADIUS es un servicio de sistema ligero que actúa como un proxy entre los Servidores de Acceso a la Red (NAS) - como los puntos de acceso inalámbricos (WAP) o los controladores de LAN inalámbrica (WLC) - y la nube de Okta. Normalmente se implementa en un servidor Windows o Linux de forma local o dentro de una VPC en la nube, y se gestiona por completo desde la Okta Admin Console tras la instalación inicial.

El flujo de autenticación sigue un modelo de proxy 802.1X estándar. El dispositivo de un usuario (el suplicante) se conecta a un SSID corporativo y presenta las credenciales. El WAP o WLC (el autenticador) reenvía una solicitud RADIUS Access-Request al agente Okta RADIUS a través del puerto UDP 1812. El agente tuneliza de forma segura esta solicitud a la nube de Okta a través de una llamada API HTTPS, donde el motor de políticas de Okta evalúa las credenciales con respecto a su directorio de usuarios y cualquier política de inicio de sesión configurada. Si la autenticación tiene éxito, el agente devuelve un mensaje RADIUS Access-Accept al autenticador, incluyendo opcionalmente atributos RADIUS para la autorización, como la asignación de VLAN. Si se requiere MFA, el agente envía un mensaje RADIUS Access-Challenge de vuelta al cliente, solicitando un segundo factor antes de devolver la decisión final.

Este modelo de proxy significa que el agente Okta RADIUS no necesita almacenar las credenciales de los usuarios de forma local. Toda la lógica de autenticación, la evaluación de políticas y el registro de auditoría ocurren en la nube de Okta, lo que proporciona a los administradores un panel de control único para la gobernanza de la identidad tanto en las aplicaciones de la nube como en el acceso a la red.

Protocolos EAP compatibles y limitaciones críticas

Una limitación de diseño fundamental del agente RADIUS de Okta es su dependencia del Protocolo de autenticación de contraseña (PAP) para la autenticación principal. Aunque PAP transmite las contraseñas en texto claro en la capa interna, esto se encapsula y protege mediante el túnel TLS externo del Protocolo de autenticación extensible (EAP). Los protocolos externos compatibles son EAP-TTLS (con PAP como método interno) y EAP-GTC. Para obtener una comparación más detallada de los métodos EAP, consulte la guía de referencia Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST.

Es fundamental destacar que PEAP-MSCHAPv2 no es compatible. Este es el protocolo 802.1X predeterminado para clientes Windows y muchos entornos empresariales heredados. Las organizaciones que migren desde una configuración RADIUS tradicional de NPS/Active Directory deben volver a configurar los suplicantes de sus clientes para que utilicen EAP-TTLS con PAP, un cambio que normalmente requiere un perfil de WiFi distribuido a través de un MDM o una directiva de grupo. No tener esto en cuenta es la causa más común de fallos en los despliegues de RADIUS de Okta.

EAP-TLS, que se basa por completo en la autenticación mutua mediante certificados, tampoco es compatible de forma nativa con el agente RADIUS de Okta. Las organizaciones que requieran EAP-TLS deben desplegar una PKI dedicada o una solución RADIUS en la nube que se integre con Okta como IdP a través de SAML o OIDC, en lugar de utilizar el agente RADIUS de Okta directamente.

Aplicación de MFA en conexiones WiFi

El agente RADIUS de Okta admite MFA para el acceso a WiFi, pero introduce desafíos en la experiencia de usuario que deben evaluarse cuidadosamente antes del despliegue. Cuando se activa una directiva MFA, el agente envía un mensaje Access-Challenge de RADIUS al cliente. Okta admite varios factores para las aplicaciones RADIUS:

La limitación práctica es la itinerancia. En entornos de Hostelería, la tableta de un empleado de limpieza puede alternar entre puntos de acceso docenas de veces por turno, lo que activa la autenticación cada vez. Exigir la aprobación de una notificación push en cada itinerancia es inviable a nivel operativo. Para la red WiFi del personal general, se suelen preferir directivas de contraseñas sólidas combinadas con la confianza del dispositivo de Okta y las directivas de zona de red, en lugar de solicitudes MFA activas. El uso de MFA en la red WiFi debe reservarse para SSID administrativos o escenarios de acceso con privilegios elevados.

Autenticación basada en contraseñas frente a autenticación basada en certificados

La elección entre RADIUS basado en contraseña (a través del agente Okta RADIUS) y EAP-TLS basado en certificados es una de las decisiones más trascendentales en un despliegue de WiFi empresarial. Las ventajas y desventajas no se limitan únicamente a la seguridad; también implican la complejidad del despliegue, la madurez de la gestión de dispositivos y los costes operativos.

La autenticación basada en contraseña a través del agente Okta RADIUS ofrece un camino rápido hacia una identidad unificada. Si su organización ya gestiona usuarios en Okta, el despliegue se puede completar en horas en lugar de semanas. No hay ninguna PKI que construir, ni certificados que distribuir, ni dependencias de MDM. La contrapartida es que las contraseñas siguen siendo la credencial principal, y la ausencia de autenticación mutua significa que el cliente no puede verificar criptográficamente la identidad de la red, lo que representa un vector para ataques de "evil twin" en entornos de alto riesgo.

EAP-TLS basado en certificados elimina por completo las contraseñas de la ecuación de autenticación WiFi. El cliente presenta un certificado de dispositivo y el servidor RADIUS presenta un certificado de servidor, lo que proporciona una autenticación mutua. Este es el enfoque recomendado para IEEE 802.1X en redes WPA3-Enterprise, particularmente en entornos sujetos a PCI-DSS o Cyber Essentials de NCSC. El requisito previo es una PKI en funcionamiento (ya sea un despliegue de Microsoft ADCS local o un servicio de PKI en la nube) y una plataforma MDM capaz de distribuir certificados a todos los terminales gestionados. Para entornos de Retail con cientos de dispositivos de punto de venta gestionados, esta inversión está plenamente justificada. Para entornos con un uso intensivo de BYOD o despliegues rápidos, Okta RADIUS con EAP-TTLS es la opción más pragmática.

Mapeo de Atributos RADIUS para Asignación Dinámica de VLAN

La asignación dinámica de VLAN es donde la integración de Okta RADIUS aporta su valor operativo más tangible. Al mapear la pertenencia a grupos de Okta con los atributos de RADIUS, los administradores de red pueden aplicar la segmentación de red basada en roles sin tener que mantener políticas de VLAN separadas por dispositivo o por ubicación.

Okta transmite los datos de pertenencia a grupos en el mensaje Access-Accept de RADIUS utilizando uno de los tres atributos siguientes, configurables en los Ajustes Avanzados de RADIUS de la aplicación Okta:

• Attribute 11 (Filter-Id): Un atributo de cadena que contiene el nombre del grupo. Ampliamente compatible con diversos proveedores.
• Attribute 25 (Class): Un atributo opaco utilizado para la autorización. Compatible con Cisco ISE, Aruba ClearPass y Fortinet.
• Attribute 26 (Vendor-Specific): Permite subatributos específicos del proveedor para un control más granular.

El controlador de red (WLC, dispositivo NAC) recibe el nombre del grupo de Okta en el atributo seleccionado y lo mapea con los atributos de túnel RADIUS estándar requeridos para la asignación de VLAN:

Por ejemplo, un usuario en el grupo de Okta Retail-POS-Staff recibiría Class: Retail-POS-Staff devuelto en el Access-Accept. La política del WLC mapearía esto a Tunnel-Private-Group-ID: 40, colocando el dispositivo en la VLAN 40, la red de POS aislada. Un usuario en Store-Management se colocaría en la VLAN 50. Esta lógica se aplica en el extremo de la red, no en Okta, pero está impulsada por completo por la pertenencia al grupo de Okta.

Guía de implementación

Paso 1: Desplegar el agente RADIUS de Okta (alta disponibilidad)

Despliegue el agente RADIUS de Okta en un mínimo de dos servidores, ya sea de forma local o en una VPC en la nube, para garantizar la alta disponibilidad. Los despliegues con un solo agente representan un riesgo crítico: si el servidor no está disponible por aplicación de parches o experimenta un fallo, toda la autenticación WiFi 802.1X fallará en toda la infraestructura. Configure su WLC o dispositivo NAC para equilibrar la carga de las solicitudes RADIUS entre ambos agentes.

Durante la instalación, el agente solicitará un inicio de sesión de administrador de Okta para autorizar el agente y vincularlo al tenant de Okta. Una vez autorizado, el agente aparece en la consola de administración de Okta en Settings > Downloads > RADIUS Agent Status, donde se puede supervisar el estado y la conectividad.

Paso 2: Configurar la aplicación RADIUS en Okta

1. En la consola de administración de Okta, navegue a Applications > Applications y busque en el catálogo de aplicaciones RADIUS Application.
2. Añada la aplicación, asígnele un nombre descriptivo (p. ej., Corporate-WiFi-Staff) y haga clic en Next.
3. En la pestaña Sign On, configure el RADIUS Port (por defecto 1812) y genere un Shared Secret fuerte, generado aleatoriamente, de al menos 32 caracteres.
4. En Advanced RADIUS Settings, active Accept password and security token in the same login request si tiene previsto admitir TOTP añadido a las contraseñas.
5. Opcionalmente, active Permit Automatic Push for Okta Verify Enrolled Users para una MFA basada en push sin interrupciones.
6. Asigne la aplicación a los grupos de Okta correspondientes que representen a su personal.

Paso 3: Configurar la asignación de VLAN basada en grupos

1. En la configuración de Sign On de la aplicación RADIUS, haga clic en Edit en la sección Advanced RADIUS Settings.
2. Marque Include groups in RADIUS response.
3. Seleccione el atributo RADIUS: se recomienda 25 Class para entornos de Aruba y Cisco; 11 Filter-Id para Fortinet y otros.
4. Añada los nombres de los grupos de Okta específicos que desea incluir (p. ej., Retail-POS-Staff, Store-Management, IT-Admins).
5. En su WLC o dispositivo NAC, cree políticas de aplicación que mapeen cada nombre de grupo con los atributos de túnel de VLAN correspondientes.

Paso 4: Configurar los suplicantes del cliente

Debido a que PEAP-MSCHAPv2 no es compatible, los dispositivos de los clientes deben configurarse para usar EAP-TTLS con PAP como método interno. Implemente un perfil de red inalámbrica a través de su plataforma MDM (por ejemplo, Microsoft Intune, Jamf Pro) o mediante objetos de directiva de grupo (GPO) para dispositivos unidos al dominio de Windows. El perfil debe especificar:

• SSID: El nombre de su SSID corporativo
• Seguridad: WPA2-Enterprise o WPA3-Enterprise
• Método EAP: EAP-TTLS
• Autenticación interna: PAP
• Validación de certificado de servidor: Activado (vincular al CN del certificado de servidor de su agente RADIUS)

Paso 5: Configurar los tiempos de espera de RADIUS

Aumente el tiempo de espera de RADIUS en su WLC desde el valor predeterminado de 3 a 5 segundos a 30 - 60 segundos. Esto es fundamental si se utilizan notificaciones push de MFA, ya que el usuario debe disponer de tiempo suficiente para aprobar la notificación en su dispositivo antes de que el WLC abandone el intento de autenticación.

Buenas prácticas

Implementar Okta RADIUS para la autenticación de WiFi es un proceso sencillo, pero varias buenas prácticas operativas diferencian una implementación de producción resiliente de una prueba de concepto inestable.

Segmente el tráfico de invitados y de personal a nivel de SSID. Okta RADIUS es una herramienta de identidad para el personal. Para el acceso de visitantes e invitados, implemente una solución de Captive Portal dedicada. Esto evita que los costes de licencia de Okta escalen con el volumen de invitados y garantiza una separación clara de funciones. Los clientes corporativos de Purple pueden implementar Guest WiFi en un SSID independiente mientras utilizan Okta RADIUS para la autenticación del personal en la misma infraestructura física.

Utilice un dispositivo NAC para entornos con políticas complejas. Si su entorno requiere acceso condicional basado en el estado del dispositivo, el filtrado de direcciones MAC o el estado del certificado junto con la identidad del usuario, implemente un dispositivo NAC intermedio (Aruba ClearPass, Cisco ISE o Portnox) para enviar las solicitudes mediante proxy al agente Okta RADIUS. El dispositivo NAC puede enriquecer la respuesta de RADIUS con atributos de túnel adicionales que el agente de Okta por sí solo no puede generar.

Supervise a través del Okta System Log. Cada evento de autenticación (éxito, fallo, desafío de MFA y tipo de factor) se registra en el Okta System Log. Configure la transmisión de registros a su SIEM para recibir alertas en tiempo real sobre anomalías de autenticación. Esto es especialmente valioso para organizaciones del sector público y de Sanidad sujetas a requisitos de auditoría.

Rotar los secretos compartidos de forma programada. El secreto compartido entre la aplicación Okta RADIUS y su NAS es una credencial de seguridad fundamental. Implemente un programa de rotación (se recomienda trimestralmente) y actualice simultáneamente tanto la aplicación de Okta como la configuración del WLC/NAC.

Restringir las direcciones de servicio de RADIUS. En la configuración del agente de Okta RADIUS, restrinja qué direcciones IP tienen permitido enviar solicitudes RADIUS. Esto evita que dispositivos NAS no autorizados intenten autenticarse contra su inquilino de Okta. Para obtener orientación sobre el contexto de la arquitectura de red general, consulte The Core SD WAN Benefits for Modern Businesses y Wireless Access Points Definition Your Ultimate 2026 Guide.

Resolución de problemas y mitigación de riesgos

La siguiente tabla resume los fallos más comunes encontrados en los despliegues de Okta RADIUS WiFi y sus mitigaciones recomendadas.

Para entornos de Transporte y del sector público donde el tiempo de actividad de la red es fundamental para la actividad, implemente una monitorización sintética que compruebe periódicamente la autenticación RADIUS de extremo a extremo y envíe alertas en caso de fallo antes de que afecte a los usuarios.

ROI e impacto empresarial

La viabilidad económica de la autenticación de Okta RADIUS WiFi se basa en tres pilares: eficiencia operativa, mejora de la seguridad y preparación para el cumplimiento normativo.

Eficiencia operativa. Consolidar la autenticación WiFi en Okta elimina la necesidad de mantener una infraestructura de RADIUS local independiente (servidores NPS, AD local) en cada establecimiento o sede. Para una cadena hotelera con 50 propiedades, esto puede representar una reducción significativa de los costes de infraestructura por sede y de los gastos generales de soporte de TI. El aprovisionamiento y desaprovisionamiento de usuarios se vuelve unificado: añadir a un usuario al grupo de Okta correcto le otorga acceso tanto a la aplicación como a la VLAN de WiFi correspondiente de forma simultánea. Cuando un empleado se marcha, la desactivación de su cuenta de Okta revoca inmediatamente el acceso a la WiFi en todas las sedes.

Postura de seguridad. Sustituir las contraseñas compartidas de WiFi WPA2/WPA3 por la autenticación 802.1X por usuario elimina el uso compartido de credenciales, un vector común para amenazas internas y accesos no autorizados. Combinado con la asignación dinámica de VLAN, esto aplica el principio de mínimo privilegio en la capa de red. El registro del sistema de Okta proporciona un registro de auditoría completo y a prueba de manipulaciones de cada evento de autenticación de WiFi, lo cual es esencial para la respuesta ante incidentes.

Cumplimiento normativo. El requisito 8.3 de PCI-DSS 4.0 exige MFA para todo acceso administrativo que no sea por consola. El requisito 1.3 exige la segmentación de la red entre el entorno de datos de los titulares de tarjetas y otras redes. Okta RADIUS con asignación de VLAN basada en grupos aborda directamente ambos requisitos. Para el cumplimiento de GDPR, el registro del sistema de Okta proporciona los registros de acceso necesarios para demostrar los controles técnicos adecuados sobre los sistemas de procesamiento de datos personales. Para los establecimientos que despliegan Modern Hospitality WiFi Solutions, este enfoque unificado de la identidad y el acceso a la red es cada vez más un requisito previo para las adquisiciones empresariales.

Las organizaciones que han completado esta integración suelen registrar una reducción de los tickets de soporte de TI relacionados con WiFi (menos solicitudes de restablecimiento de contraseñas, menos incidentes de configuración incorrecta de VLAN) y una mejora cuantificable en las puntuaciones de las auditorías de seguridad. La inversión en el despliegue y la configuración del agente Okta RADIUS - que suele medirse en días en lugar de semanas para un despliegue en un solo sitio - ofrece un ahorro operativo continuo que se acumula en todo un patrimonio distribuido.