Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication

Resumen Ejecutivo

Para los equipos de TI de empresas que gestionan recintos distribuidos —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 moderna en la nube y la infraestructura WiFi 802.1X tradicional, lo que permite a las organizaciones prescindir de los servidores RADIUS locales heredados y de 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 WiFi empresarial, abarcando la arquitectura de proxy, los mecanismos de aplicación de MFA y las ventajas y desventajas entre EAP-TTLS basado en contraseñas 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 Guest WiFi , los operadores de recintos 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 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 consola de administración de Okta 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 empresarial 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 mediante una llamada a la API HTTPS, donde el motor de políticas de Okta evalúa las credenciales con respecto a su directorio de usuarios y a 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 que se devuelva la decisión final.

Este modelo de proxy significa que el agente Okta RADIUS no necesita almacenar las credenciales de los usuarios localmente. 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 en la nube como en el acceso a la red.

Protocolos EAP compatibles y limitaciones críticas

Una restricción arquitectónica fundamental del agente RADIUS de Okta es su dependencia del Protocolo de autenticación de contraseñas (PAP) para la autenticación primaria. Aunque PAP transmite las contraseñas en texto plano en la capa interna, estas se encapsulan y protegen 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 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 tener en cuenta 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 reconfigurar sus suplicantes de cliente para usar EAP-TTLS con PAP, un cambio que normalmente requiere un perfil inalámbrico distribuido a través de MDM o directivas de grupo. No tener esto en cuenta es la causa más común de fallos en las implementaciones de RADIUS de Okta.

EAP-TLS, que se basa completamente en la autenticación mutua basada en certificados, tampoco es compatible de forma nativa con el agente RADIUS de Okta. Las organizaciones que requieran EAP-TLS deben implementar 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 del usuario que deben considerarse cuidadosamente antes de la implementación. Cuando se activa una política de MFA, el agente envía un Access-Challenge de RADIUS al cliente. Okta admite varios factores para las aplicaciones RADIUS:

La limitación práctica es el roaming. En entornos de Hospitality , la tableta de un empleado de limpieza puede realizar roaming entre puntos de acceso docenas de veces por turno, lo que activa la autenticación cada vez. Requerir la aprobación de una notificación push en cada roaming es operativamente inviable. Para el WiFi del personal general, se suelen preferir políticas de contraseñas seguras combinadas con la confianza del dispositivo de Okta y las políticas de zona de red, en lugar de solicitudes de MFA activas. El MFA en WiFi debe reservarse para SSIDs 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 compensaciones no se limitan a la seguridad; 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 una vía rápida hacia la identidad unificada. Si su organización ya gestiona usuarios en Okta, el despliegue se puede completar en horas en lugar de semanas. No hay PKI que construir, ni certificados que distribuir, ni dependencia 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 supone un vector para ataques de tipo "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, proporcionando autenticación mutua. Este es el enfoque recomendado para IEEE 802.1X en redes WPA3-Enterprise, especialmente en entornos sujetos a PCI DSS o NCSC Cyber Essentials Plus. El requisito previo es una PKI en funcionamiento (ya sea un despliegue local de Microsoft ADCS o un servicio de PKI en la nube) y una plataforma MDM capaz de distribuir certificados a todos los puntos finales 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 independientes 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 configurables en la configuración avanzada de RADIUS de la aplicación Okta:

• Atributo 11 (Filter-Id): Un atributo de cadena que contiene el nombre del grupo. Ampliamente compatible entre distintos proveedores.
• Atributo 25 (Class): Un atributo opaco utilizado para la autorización. Compatible con Cisco ISE, Aruba ClearPass y Fortinet.
• Atributo 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 necesarios para la asignación de VLAN:

Por ejemplo, un usuario en el grupo de Okta Retail-POS-Staff recibiría Class: Retail-POS-Staff 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 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 completamente 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 parches o sufre 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 monitorizar 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 (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 seguro y aleatorio de al menos 32 caracteres.
4. En Advanced RADIUS Settings, active Accept password and security token in the same login request si tiene la intención de admitir TOTP añadido a las contraseñas.
5. Opcionalmente, active Permit Automatic Push for Okta Verify Enrolled Users para una MFA fluida basada en notificaciones push.
6. Asigne la aplicación a los grupos de Okta correspondientes que representan 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 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 (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 a los atributos de túnel VLAN correspondientes.

Paso 4: Configurar los suplicantes de cliente

Como PEAP-MSCHAPv2 no es compatible, los dispositivos cliente deben configurarse para utilizar 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 empresarial
• Seguridad: WPA2-Enterprise o WPA3-Enterprise
• Método EAP: EAP-TTLS
• Autenticación interna: PAP
• Validación de certificado de servidor: Activada (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 de los 3-5 segundos predeterminados 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

La implementación de Okta RADIUS para la autenticación de WiFi es sencilla, pero varias buenas prácticas operativas diferencian una implementación de producción resistente de una prueba de concepto frágil.

Segmente el tráfico de invitados y del personal a nivel de SSID. Okta RADIUS es una herramienta de identidad para la fuerza laboral. Para el acceso de visitantes e invitados, implemente una solución de Captive Portal dedicada. Esto evita que los costes de licencia de Okta aumenten con el volumen de invitados y garantiza una separación clara de funciones. Los clientes empresariales 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 de políticas complejos. 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 realizar el proxy de las solicitudes al agente de 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 registro del sistema de Okta. Cada evento de autenticación (éxito, fallo, desafío de MFA y tipo de factor) se registra en el registro del sistema de Okta. 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 las 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 tanto la aplicación de Okta como la configuración de WLC/NAC simultáneamente.

Restringir las direcciones del servicio 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. For guidance on the broader network architecture context, see The Core SD WAN Benefits for Modern Businesses and Wireless Access Points Definition Your Ultimate 2026 Guide .

Troubleshooting & Risk Mitigation

The following table summarises the most common failure modes encountered in Okta RADIUS WiFi deployments and their recommended mitigations.

For Transport and public-sector environments where network uptime is mission-critical, implement synthetic monitoring that periodically tests RADIUS authentication end-to-end and alerts on failure before users are impacted.

ROI & Business Impact

The business case for Okta RADIUS WiFi authentication rests on three pillars: operational efficiency, security posture improvement, and compliance readiness.

Operational Efficiency. Consolidating WiFi authentication into Okta eliminates the need to maintain separate on-premises RADIUS infrastructure (NPS servers, local AD) at each venue or site. For a hotel chain with 50 properties, this can represent a significant reduction in per-site infrastructure costs and IT support overhead. User provisioning and deprovisioning become atomic: adding a user to the correct Okta group grants both application access and the appropriate WiFi VLAN access simultaneously. When an employee leaves, deactivating their Okta account immediately revokes WiFi access across all sites.

Security Posture. Replacing shared PSK WiFi passwords with per-user 802.1X authentication eliminates credential sharing, a common vector for insider threat and unauthorised access. Combined with dynamic VLAN assignment, this enforces the principle of least privilege at the network layer. The Okta System Log provides a complete, tamper-evident audit trail of every WiFi authentication event, which is essential for incident response.

Compliance Readiness. PCI DSS 4.0 Requirement 8.3 mandates MFA for all non-console administrative access. Requirement 1.3 requires network segmentation between the cardholder data environment and other networks. Okta RADIUS with group-based VLAN assignment directly addresses both requirements. For GDPR compliance, the Okta System Log provides the access records required to demonstrate appropriate technical controls over personal data processing systems. For venues deploying Modern Hospitality WiFi Solutions , this unified approach to identity and network access is increasingly a prerequisite for enterprise procurement.

Organisations that have completed this integration typically report a reduction in WiFi-related IT support tickets (fewer password reset requests, fewer VLAN misconfiguration incidents) and a measurable improvement in security audit scores. The investment in deploying and configuring the Okta RADIUS agent — typically measured in days rather than weeks for a single-site deployment — delivers ongoing operational savings that compound across a distributed estate.