Autenticación WiFi empresarial sin Active Directory ni servidor local
Esta guía explica cómo implementar una autenticación WiFi WPA2/3-Enterprise segura sin un Active Directory local, Windows NPS o servidor RADIUS. Cubre la incompatibilidad de protocolos entre los proveedores de identidad en la nube y 802.1X, los argumentos a favor de EAP-TLS frente a PEAP-MSCHAPv2 y cómo implementar cloud RADIUS con certificados emitidos por MDM contra Microsoft Entra ID, Okta o Google Workspace. Escrito para responsables de TI en organizaciones cloud-first y con un gran volumen de Mac/Chromebook que estén listas para retirar la infraestructura local.
Escuchar esta guía
Ver transcripción del podcast
📚 Part of our core series: Seguridad y autenticación WiFi empresarial: la guía completa →
Resumen ejecutivo
La mayoría de las organizaciones han migrado su identidad a la nube. Microsoft Entra ID, Okta y Google Workspace gestionan ahora usuarios, grupos y políticas de acceso para el correo electrónico, las aplicaciones SaaS y la gestión de dispositivos. Sin embargo, la red WiFi empresarial no ha seguido el mismo ritmo. Los puntos de acceso siguen esperando un servidor RADIUS, y ese servidor RADIUS ha sido históricamente Windows Network Policy Server (NPS) conectado a un controlador de dominio de Active Directory local.
Esta incompatibilidad obliga a los equipos de TI a mantener una infraestructura local redundante con el único fin de mantener la red WiFi en funcionamiento. La solución es cloud RADIUS: un servicio de autenticación totalmente gestionado que habla RADIUS con sus puntos de acceso y habla OAuth2, SCIM y SAML con su proveedor de identidad en la nube. Al combinarlo con la distribución de certificados EAP-TLS a través de su MDM, dispondrá de un despliegue 802.1X completo sin servidores locales, sin parches de sistema operativo y con una revocación de acceso instantánea vinculada directamente a su directorio en la nube.
Purple opera cloud RADIUS en más de 80 000 establecimientos en todo el mundo, con un tiempo de actividad del 99,999 % (datos internos de Purple, 2024) e integraciones nativas con Microsoft Entra ID, Okta y Google Workspace. Puede estar operativo en sus puntos de acceso existentes de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet en menos de una hora.
Análisis técnico detallado
La incompatibilidad de protocolos en el centro del problema
El desafío fundamental es que los proveedores de identidad en la nube y los puntos de acceso WiFi hablan lenguajes completamente diferentes. Microsoft Entra ID (anteriormente Azure AD) autentica a los usuarios a través de SAML, OIDC y OAuth2, los protocolos que utilizan los navegadores y las aplicaciones SaaS. Los puntos de acceso WiFi utilizan RADIUS (Remote Authentication Dial-In User Service, RFC 2865), un protocolo basado en UDP diseñado en la década de 1990 para conexiones de acceso telefónico y VPN. Microsoft nunca ha ofrecido un punto de conexión RADIUS nativo para Entra ID. No se puede apuntar un punto de acceso de Meraki o Aruba directamente a Azure y esperar que funcione el protocolo 802.1X.
Este es el obstáculo con el que se topa todo equipo de TI cloud-first cuando intenta proteger la red WiFi del personal con WPA2-Enterprise o WPA3-Enterprise. Algo tiene que salvar la distancia entre el punto de acceso y el proveedor de identidad en la nube. Ese algo es cloud RADIUS.
Por qué PEAP-MSCHAPv2 falla sin Active Directory
Históricamente, los despliegues de 802.1X dependían de PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versión 2). El usuario introducía su nombre de usuario y contraseña, el punto de acceso reenviaba la solicitud al servidor RADIUS y el servidor RADIUS validaba la contraseña contra un hash NTLM almacenado en Active Directory.
Microsoft Entra ID no almacena hashes NTLM. No se trata de un fallo de configuración, sino de una decisión arquitectónica deliberada. Entra ID es un proveedor de identidad en la nube moderno, no un controlador de dominio. En consecuencia, un servidor RADIUS que apunte a Entra ID no puede validar un desafío PEAP-MSCHAPv2. La única forma de hacer que PEAP funcione con Entra ID es implementar Entra Domain Services, un Active Directory gestionado de pago que se sincroniza desde Entra ID, y luego ejecutar NPS contra él. Esto vuelve a introducir la mayor parte de lo que se intentaba eliminar: máquinas virtuales de Windows Server, parches de sistema operativo, almacenamiento de hashes NTLM y gestión manual de certificados.
EAP-TLS: la respuesta correcta para organizaciones cloud-first
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) sustituye las contraseñas por certificados digitales X.509. El dispositivo presenta un certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra una entidad de certificación (CA) de confianza. Al no haber contraseñas en el intercambio, el servidor RADIUS no necesita un almacén de hashes NTLM. Solo necesita confiar en la CA y comprobar la pertenencia al grupo del usuario en el proveedor de identidad para aplicar la VLAN y la política de acceso correctas.
EAP-TLS es resistente al phishing por diseño. No hay credenciales que robar. Cumple con las directrices de la CISA sobre autenticación multifactor resistente al phishing y se alinea con los requisitos de PCI DSS para una autenticación sólida en redes que gestionan datos de titulares de tarjetas. Es el método de autenticación recomendado por IEEE 802.1X para flotas de dispositivos gestionados.
Arquitectura de autenticación 802.1X cloud-first: los dispositivos se autentican mediante EAP-TLS a través del cloud RADIUS de Purple, que valida los certificados y aplica políticas basadas en grupos desde Entra ID, Okta o Google Workspace.
Cómo el MDM sustituye a la CA local
En un despliegue 802.1X tradicional, los certificados eran emitidos por una entidad de certificación local que ejecutaba Active Directory Certificate Services (AD CS). En un despliegue cloud-first, el MDM asume esta función utilizando SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro y otras plataformas MDM pueden solicitar certificados a una CA alojada en la nube y distribuirlos silenciosamente a los dispositivos gestionados.
El flujo funciona de la siguiente manera. El administrador de TI crea un perfil de certificado SCEP en el MDM, asignado a los grupos de dispositivos que requieren acceso WiFi. El MDM distribuye el certificado a los dispositivos Windows, macOS, iOS, iPadOS, Android Enterprise y ChromeOS de forma automática. El usuario no ve nada. El certificado se vincula a la identidad del dispositivo en el MDM y se renueva automáticamente antes de caducar. Cuando el dispositivo se conecta a la red WiFi, presenta el certificado al servidor cloud RADIUS, que lo valida contra la CA y aplica la política de red correcta.
Para las organizaciones que utilizan Microsoft Intune, Microsoft Cloud PKI proporciona una CA totalmente gestionada que se integra directamente con los perfiles SCEP de Intune, eliminando la necesidad de un servidor local NDES (Network Device Enrollment Service). Para entornos Mac e iOS gestionados por Jamfets, la CA integrada de Jamf o una CA en la nube de terceros sirven para el mismo propósito.
SCIM y revocación instantánea de acceso
Uno de los aspectos operativamente más importantes de cloud RADIUS es el aprovisionamiento SCIM (System for Cross-domain Identity Management). SCIM es un estándar abierto que envía los cambios de identidad desde la fuente de verdad (su proveedor de identidad en la nube) a los sistemas dependientes en tiempo real. Cuando se deshabilita a un empleado en Entra ID u Okta, SCIM envía ese cambio al servicio cloud RADIUS de inmediato. La próxima vez que el dispositivo intente autenticarse, el servidor RADIUS devolverá Access-Reject. Con un tiempo de espera de sesión corto configurado en el punto de acceso, el dispositivo se elimina de la red a los pocos minutos de haber deshabilitado la cuenta.
Esto representa una mejora de seguridad sustancial con respecto a las redes PSK compartidas, donde la única forma de revocar el acceso es cambiar la contraseña en cada dispositivo, y con respecto a las implementaciones RADIUS heredadas que dependen de sincronizaciones LDAP periódicas con un margen de horas o días.
RadSec: protección del tráfico RADIUS a través de Internet
El RADIUS tradicional utiliza UDP y solo proporciona una autenticación de mensajes básica. Cuando su servidor RADIUS está en el mismo centro de datos que sus puntos de acceso, esto es aceptable. Cuando su servidor RADIUS es un servicio en la nube, el tráfico de autenticación atraviesa la red pública de Internet. RadSec (RADIUS sobre TLS, RFC 6614) cifra el intercambio RADIUS mediante TLS, proporcionando confidencialidad e integridad para el tráfico de autenticación. Purple admite RadSec de forma nativa, con respaldo de IPsec para los puntos de acceso que aún no son compatibles con RadSec.
Guía de implementación
La implementación de cloud RADIUS con EAP-TLS requiere cuatro pasos coordinados. Un SSID piloto puede estar activo en menos de una hora si Entra ID y un MDM ya están configurados.
Paso 1: Conectar cloud RADIUS a su proveedor de identidad
Conecte Purple a su proveedor de identidad mediante el consentimiento de administrador de OAuth2 (para Entra ID) o un token de API (para Okta y Google Workspace). Esto autoriza a Purple a leer usuarios, grupos y pertenencias a grupos desde el directorio. Configure el aprovisionamiento SCIM para enviar los cambios de estado de los usuarios a Purple en tiempo real. No se almacenan credenciales de entidad de servicio en el disco. Los cambios de grupo se propagan en el siguiente evento de autenticación, no según un programa de sincronización.
Paso 2: Configurar su MDM y perfil SCEP
En Microsoft Intune, cree un perfil de certificado de confianza para la CA raíz y, a continuación, cree un perfil de certificado SCEP que apunte a la CA gestionada por Purple. Asigne ambos perfiles a los grupos de dispositivos que requieran acceso WiFi. Para Jamf, configure una carga útil SCEP en un perfil de configuración. El MDM envía los certificados de forma silenciosa. Verifique la entrega de certificados en el panel de cumplimiento del MDM antes de continuar.
Paso 3: Definir políticas de red en el panel de cloud RADIUS
Cree políticas RADIUS que asocien los grupos del proveedor de identidad con VLAN específicas y controles de acceso. For ejemplo, asocie el grupo de Entra ID "Staff-Finance" a la VLAN 20 con acceso total a Internet, y asocie "Staff-Contractors" a la VLAN 30 con un acceso limitado en el tiempo que expira automáticamente. El panel de Purple aplica estas políticas en el momento de la autenticación, sin necesidad de realizar cambios en el cortafuegos.
Paso 4: Actualizar la configuración del punto de acceso
Actualice la configuración del SSID en sus puntos de acceso para utilizar WPA2-Enterprise o WPA3-Enterprise con 802.1X. Introduzca los nombres de host o direcciones IP de los puntos de conexión primario y secundario de cloud RADIUS de Purple, junto con el secreto compartido. Configure los puntos de acceso para utilizar la asignación dinámica de VLAN basada en los atributos RADIUS devueltos por Purple. Realice pruebas con un único SSID en un subconjunto de puntos de acceso antes de implementarlo en toda la infraestructura.
Cloud RADIUS frente a RADIUS local: una comparación directa en cuanto a tiempo de implementación, dependencia de Active Directory, alta disponibilidad, parches del sistema operativo, integración de identidad y gestión del ciclo de vida de los certificados.
Buenas prácticas
Estas recomendaciones reflejan los estándares IEEE 802.1X, los requisitos de PCI DSS v4.0 y la experiencia operativa en los más de 80.000 establecimientos de Purple.
Exija EAP-TLS para los dispositivos gestionados. Las contraseñas son vulnerables al phishing y al relleno de credenciales (credential stuffing). Los certificados proporcionan una prueba criptográfica de la identidad y del cumplimiento del dispositivo. EAP-TLS es el único método 802.1X diseñado para ser resistente al phishing.
Utilice SCIM para la revocación instantánea. Las sincronizaciones periódicas de LDAP dejan un margen de tiempo en el que un empleado despedido conserva el acceso a la red. SCIM garantiza que el acceso se revoque en el momento en que se deshabilita la cuenta en el proveedor de identidad.
Implemente RADIUS multirregión. Configure sus puntos de acceso con al menos dos puntos de conexión RADIUS en diferentes regiones geográficas. Purple proporciona conmutación por error multirregión activo-activo de forma predeterminada, completándose en cuestión de segundos.
Segmente el tráfico con VLAN dinámicas. Utilice las pertenencias a grupos del proveedor de identidad para asignar dinámicamente a los usuarios a VLAN específicas. Esto aísla el tráfico confidencial y limita el radio de impacto de un dispositivo comprometido sin necesidad de realizar cambios manuales en el cortafuegos.
Habilite RadSec. Si sus puntos de acceso son compatibles con RadSec, habilítelo para cifrar el tráfico de autenticación entre el punto de acceso y el servidor cloud RADIUS. Esto es especialmente importante para sucursales y establecimientos donde el punto de acceso se encuentra en un segmento de red no seguro.
Supervise el ciclo de vida de los certificados. Configure la renovación automática del MDM para que se active al 80 % de la vida útil del certificado. Para un certificado de un año, la renovación comienza a los 10 meses. Configure alertas para los dispositivos que no se renueven antes de que expire el certificado.
Para obtener un análisis más amplio de los estándares y marcos de seguridad WiFi para empresas, consulte nuestra guía Seguridad WiFi empresarial: guía completa para 2026 .
Resolución de problemas y mitigación de riesgos
La transición a cloud RADIUS introduce nuevas dependencias. Prepárese para estos fallos comunes antes de que afecten a la producción.
Certificado del certificado. Si el certificado de un dispositivo caduca antes de que el MDM lo renueve, el dispositivo falla la autenticación de forma silenciosa. El usuario ve un error de conexión sin ninguna explicación. Mitigue este problema configurando la renovación automática del MDM al 80% de la vida útil del certificado y supervisando el panel de cumplimiento del MDM para detectar dispositivos con certificados a punto de caducar.
Fallos de sincronización de MDM. Un dispositivo que deja de cumplir con las directivas de MDM o que no se conecta correctamente puede no recibir un certificado renovado. Implemente políticas de cumplimiento que marquen los dispositivos no conformes y alerten a los administradores antes de que caduque el certificado.
Bloqueo del tráfico RADIUS por el cortafuegos. Los puntos de acceso deben poder comunicarse con los endpoints de RADIUS en la nube a través del puerto UDP 1812 (autenticación) y el puerto UDP 1813 (accounting), o el puerto TCP 2083 para RadSec. Las reglas de salida del cortafuegos en las sucursales suelen bloquear estos puertos. Pruebe la conectividad desde la VLAN de gestión de los puntos de acceso antes del despliegue.
Fallos de aprovisionamiento SCIM. Si se interrumpe la conexión SCIM entre el proveedor de identidad y Purple, los cambios de estado de los usuarios no se propagarán. Supervise el estado de sincronización de SCIM tanto en el proveedor de identidad como en el panel de control de Purple. Configure alertas para los fallos de sincronización.
Dispositivos heredados sin soporte de certificados. Los dispositivos IoT, las impresoras y el hardware más antiguo pueden no ser compatibles con EAP-TLS. Para estos dispositivos, utilice iPSK (claves individuales precompartidas) en lugar de una PSK compartida. Purple admite iPSK de forma nativa, asignando una clave única por dispositivo y ubicando cada dispositivo en la VLAN correcta sin necesidad de soporte de suplicante 802.1X.
ROI e impacto empresarial
La migración de un RADIUS local a un RADIUS en la nube ofrece un valor medible en toda la infraestructura, las operaciones y la seguridad.
| Dimensión | NPS local | Cloud RADIUS (Purple) |
|---|---|---|
| Coste de infraestructura | Licencias de Windows Server, computación de VM, almacenamiento | Suscripción por AP, sin hardware de servidor |
| Tiempo de despliegue | De días a semanas | Menos de una hora |
| Alta disponibilidad | Manual: dos servidores más replicación | Activo-activo multirregión, por defecto |
| Parcheado del SO | Mensual, por su equipo | Gestionado por el proveedor |
| WiFi helpdesk tickets | Alto: restablecimiento de contraseñas, incorporación manual | Reducción del 80% (datos de clientes de Purple) |
| Revocación de acceso | De horas a días mediante sincronización LDAP | Segundos mediante SCIM |
Los equipos de TI que utilizan el Staff WiFi de Purple suelen experimentar una reducción del 80% en los tickets de soporte de WiFi (datos internos de Purple, 2024), gracias a la eliminación de los restablecimientos de contraseñas y de la incorporación manual de dispositivos. La autenticación basada en certificados también cumple con el requisito 8.3 de PCI DSS para una autenticación sólida y el control A.9.4 de ISO 27001 para el control de acceso a sistemas y aplicaciones, lo que reduce la carga de auditoría para su equipo de seguridad.
Para las organizaciones de los sectores de comercio minorista y hostelería , la capacidad de gestionar Staff WiFi y Guest WiFi desde un único panel de control en la nube, con una capa de identidad unificada, reduce la complejidad operativa en entornos multisitio. Para los operadores de transporte y proveedores de servicios sanitarios , la capacidad de revocación instantánea y el registro de auditoría completo cumplen con los requisitos normativos sin necesidad de herramientas adicionales.
La capa de WiFi Analytics de Purple añade datos de ocupación y trabajo híbrido sobre la infraestructura de autenticación, transformando el Staff WiFi de un centro de costes a una fuente de inteligencia operativa.
Lectura relacionada: Seguridad WiFi empresarial: una guía completa para 2026 - Integración de firmware personalizado OpenWrt con Purple WiFi
Definiciones clave
802.1X
Un estándar IEEE (IEEE 802.1X-2020) para el control de acceso a la red basado en puertos. Requiere que los dispositivos se autentiquen antes de que el punto de acceso conceda acceso a la red, utilizando un intercambio EAP mediado por un servidor RADIUS.
Los equipos de TI utilizan 802.1X para garantizar que solo los usuarios y dispositivos autorizados se conecten a la red corporativa. Proporciona cifrado por usuario, claves por sesión y un registro de auditoría completo de cada evento de conexión.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA) para el acceso a la red.
Los puntos de acceso reenvían cada solicitud de conexión al servidor RADIUS, que decide si admite el dispositivo y qué VLAN le asigna. Cloud RADIUS sustituye a los servidores locales NPS o FreeRADIUS.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Un método de autenticación 802.1X que utiliza un intercambio mutuo de certificados X.509 en lugar de contraseñas.
EAP-TLS es el estándar de oro para flotas de dispositivos gestionados. Es resistente al phishing, no requiere almacenamiento de hashes de contraseñas y es el único método 802.1X que cumple con las directrices de MFA resistente al phishing de la CISA.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versión 2. Un método 802.1X heredado que valida contraseñas contra hashes NTLM almacenados en Active Directory.
PEAP-MSCHAPv2 falla en entornos exclusivamente en la nube porque Entra ID no almacena hashes NTLM. Las organizaciones que migran desde un AD local deben sustituir PEAP por EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Un protocolo utilizado por las plataformas MDM para solicitar e instalar automáticamente certificados digitales en los dispositivos, sin interacción del usuario.
Los equipos de TI utilizan SCEP con Intune o Jamf para aprovisionar de forma silenciosa certificados WiFi en los dispositivos de los empleados. SCEP sustituye al servidor local NDES (Network Device Enrollment Service) en despliegues cloud-first.
SCIM
System for Cross-domain Identity Management (RFC 7644). Un estándar abierto que automatiza el intercambio en tiempo real de información de identidad de usuarios entre sistemas de TI.
SCIM garantiza que cuando se deshabilita a un empleado en Entra ID o en Okta, ese cambio se envíe inmediatamente al servicio cloud RADIUS, revocando el acceso WiFi en cuestión de segundos en lugar de horas.
NPS
Network Policy Server. La implementación de RADIUS de Microsoft, que normalmente se ejecuta en Windows Server como parte de un entorno de Active Directory local.
Las organizaciones cloud-first están retirando NPS para eliminar las máquinas virtuales de Windows Server, el parcheo del sistema operativo y la dependencia de Active Directory local. Cloud RADIUS es el sustituto directo.
RadSec
RADIUS sobre TLS (RFC 6614). Un protocolo que cifra el tráfico de autenticación RADIUS mediante TLS, sustituyendo el transporte de texto plano basado en UDP utilizado por el RADIUS tradicional.
RadSec es esencial cuando se utiliza cloud RADIUS, ya que el tráfico de autenticación debe atravesar la internet pública entre el punto de acceso y el servicio en la nube. Purple es compatible con RadSec de forma nativa.
iPSK
Individual Pre-Shared Key. Una variante de WPA2-Personal que asigna una clave precompartida única a cada dispositivo, en lugar de una única clave compartida para todos los dispositivos.
iPSK se utiliza para dispositivos IoT, impresoras y otro hardware que no admite 802.1X EAP-TLS. Proporciona trazabilidad por dispositivo y asignación de VLAN sin requerir compatibilidad con certificados.
Dynamic VLAN
Una técnica de segmentación de red en la que el servidor RADIUS devuelve un identificador de VLAN en la respuesta Access-Accept, y el punto de acceso ubica el dispositivo en esa VLAN de forma automática.
Las VLAN dinámicas permiten a los equipos de TI segmentar al personal, contratistas, dispositivos IoT e invitados en segmentos de red independientes según su pertenencia a grupos del proveedor de identidad, sin necesidad de realizar cambios manuales en el firewall.
Ejemplos prácticos
Una cadena de tiendas con 400 establecimientos necesita proteger la red WiFi de los empleados en todas sus ubicaciones. Utilizan puntos de acceso Cisco Meraki y Microsoft Entra ID con Intune para la gestión de dispositivos. Actualmente emplean una clave compartida WPA2-Personal PSK porque no disponen de un Active Directory local para ejecutar NPS. Una auditoría interna reciente señaló la PSK compartida como una brecha de cumplimiento con PCI DSS.
La cadena implementa el cloud RADIUS de Purple. En primer lugar, conectan Purple a Entra ID mediante el consentimiento de administrador de OAuth y configuran el aprovisionamiento SCIM. En Intune, crean un perfil de certificado de confianza para la CA raíz de Purple y un perfil de certificado SCEP asignado al grupo de dispositivos 'Staff-Retail'. Intune distribuye de forma silenciosa los certificados a todos los terminales de punto de venta y tabletas del personal gestionados. En el panel de Meraki, actualizan el SSID del personal a WPA2-Enterprise, introducen los puntos de conexión principal y secundario de cloud RADIUS de Purple y habilitan la asignación dinámica de VLAN. Cuando un dispositivo se conecta, presenta su certificado emitido por Intune, Purple lo valida contra la CA y comprueba el grupo de Entra ID, y el dispositivo se ubica en la VLAN 10 (red del personal) o en la VLAN 20 (red de gestión) según su pertenencia al grupo. Se retira la PSK compartida. El despliegue en los 400 centros se realiza en un solo fin de semana, ya que no se instala hardware local, solo se realizan cambios de configuración de SSID en Meraki.
Una universidad con 15 000 estudiantes utiliza Google Workspace como su proveedor de identidad principal. El equipo de TI desea ofrecer una red WiFi segura para el personal y los estudiantes en un parque de dispositivos BYOD compuesto por MacBooks, Chromebooks y teléfonos Android. No disponen de Active Directory local ni tienen intención de gestionar servidores.
La universidad integra el cloud RADIUS de Purple con Google Workspace. Para los Chromebooks gestionados, utilizan Google Admin para distribuir un perfil de certificado WiFi a través de SCEP, registrando silenciosamente cada dispositivo. Para los MacBooks y teléfonos Android BYOD, implementan una aplicación ligera de incorporación que autentica al usuario con sus credenciales de Google e instala un certificado en el dispositivo con un solo toque. Las conexiones posteriores utilizan EAP-TLS de forma silenciosa. Purple asocia las unidades organizativas de Google Workspace con las VLAN: el personal accede a la VLAN 10, los estudiantes a la VLAN 20 y los visitantes invitados a un SSID con Captive Portal. Cuando un estudiante se gradúa y se suspende su cuenta de Google, SCIM envía el cambio a Purple y su acceso WiFi se revoca en cuestión de minutos.
Preguntas de práctica
Q1. Su organización se ha migrado por completo de un Active Directory local a Microsoft Entra ID. Su red WiFi actual para el personal utiliza PEAP-MSCHAPv2 contra un servidor NPS que estaba unido al antiguo dominio. Tras retirar el controlador de dominio, el personal informa de que ya no puede conectarse a la red WiFi. ¿Cuál es la causa principal y cuál es la solución correcta a largo plazo?
Sugerencia: Considere qué requiere PEAP-MSCHAPv2 del directorio y si Entra ID lo proporciona.
Ver respuesta modelo
La causa principal es que PEAP-MSCHAPv2 requiere que el servidor RADIUS valide la contraseña del usuario contra un hash NTLM almacenado en Active Directory. Al retirar el controlador de dominio, NPS no tiene ningún directorio contra el que realizar la validación. Entra ID no almacena hashes NTLM, por lo que NPS no se puede redirigir a Entra ID. La solución correcta a largo plazo es sustituir NPS por un servicio cloud RADIUS, migrar de PEAP-MSCHAPv2 a EAP-TLS y utilizar el MDM (Intune) para emitir certificados de dispositivo a través de SCEP. Esto elimina la dependencia de cualquier directorio local.
Q2. Está implementando cloud RADIUS para un parque de 200 MacBooks corporativos gestionados por Jamf Pro. Su proveedor de identidad es Okta. ¿Cuál es la forma más segura y operativamente eficiente de aprovisionar las credenciales WiFi en estos dispositivos?
Sugerencia: Busque un método que no requiera interacción del usuario, evite las contraseñas y se integre con su MDM existente.
Ver respuesta modelo
Configure Jamf Pro para utilizar SCEP para distribuir silenciosamente certificados de dispositivo a los MacBooks. Cree una carga útil SCEP en un perfil de configuración de Jamf que apunte a la CA gestionada por su proveedor de cloud RADIUS. Asigne el perfil al grupo de dispositivos correspondiente. Jamf enviará el certificado a cada MacBook automáticamente, sin interacción del usuario. Configure el perfil WiFi en el mismo perfil de configuración para utilizar EAP-TLS con el certificado emitido por SCEP. Conecte el servicio cloud RADIUS a Okta a través de SCIM para garantizar que, cuando se deshabilite a un empleado en Okta, su acceso WiFi se revoque de inmediato.
Q3. Un empleado es despedido a las 9:00 de un lunes. Recursos Humanos deshabilita su cuenta de Entra ID a las 9:05. A las 9:30, una alerta de seguridad indica que el portátil del empleado sigue conectado a la red WiFi corporativa desde el aparcamiento. ¿Qué configuración falta y cómo se soluciona?
Sugerencia: ¿Cómo se entera el servidor RADIUS de que el estado del usuario ha cambiado en el proveedor de identidad?
Ver respuesta modelo
El despliegue depende de sincronizaciones periódicas de LDAP en lugar de un aprovisionamiento SCIM. La sincronización de LDAP aún no se ha ejecutado desde que se deshabilitó la cuenta, por lo que el servicio cloud RADIUS sigue considerando que el usuario está activo. La solución consiste en habilitar el aprovisionamiento SCIM entre Entra ID y el servicio cloud RADIUS. SCIM envía los cambios de estado de los usuarios en tiempo real, de modo que cuando la cuenta se deshabilita en Entra ID a las 9:05, el servicio RADIUS recibe el cambio de inmediato. La próxima vez que el dispositivo intente volver a autenticarse (controlado por el tiempo de espera de la sesión en el punto de acceso), recibirá un Access-Reject. Establecer un tiempo de espera de sesión corto (de 15 a 30 minutos) en el punto de acceso limita el intervalo máximo entre la desactivación de la cuenta y la expulsión de la red.
Q4. Su establecimiento cuenta con 50 dispositivos IoT (reproductores de señalización digital, sensores ambientales e impresoras) que no admiten 802.1X EAP-TLS. ¿Cómo protege estos dispositivos en la misma infraestructura WiFi que la red de su personal basada en EAP-TLS?
Sugerencia: Considere qué método de autenticación proporciona trazabilidad por dispositivo sin requerir compatibilidad con certificados.
Ver respuesta modelo
Utilice iPSK (claves individuales precompartidas) para los dispositivos IoT. Asigne una clave precompartida única a cada dispositivo en el panel de control de cloud RADIUS, junto con una asignación de VLAN. Cada dispositivo se autentica con su clave única, que el servidor RADIUS valida y utiliza para ubicar el dispositivo en la VLAN de IoT, aislada de la red del personal. Si un dispositivo se ve comprometido o se retira del servicio, solo tendrá que revocar la clave de ese dispositivo sin que afecte a los demás. Este enfoque proporciona trazabilidad por dispositivo y segmentación de red sin requerir compatibilidad con el suplicante 802.1X en el hardware de IoT.
Continúe leyendo esta serie
Integración de CommScope Ruckus con Purple WiFi: Guía de instalación y configuración
Esta guía de referencia técnica proporciona un manual de configuración definitivo para integrar arquitecturas de CommScope Ruckus con Purple WiFi. Detalla implementaciones paso a paso para captive portals de Guest WiFi, WiFi seguro para el personal a través de 802.1X y aislamiento de red multiinquilino mediante Ruckus Dynamic PSK.
Integración de puntos de acceso Allied Telesis con Purple WiFi
Esta guía proporciona un manual de configuración completo para integrar los puntos de acceso de la serie TQ de Allied Telesis con Purple WiFi. Cubre la redirección externa de Captive Portal, la autenticación RADIUS 802.1X y el direccionamiento dinámico de VLAN mediante claves precompartidas privadas (PPSK) para despliegues multiinquilino seguros.
The Security Benefits of RADIUS as a Service for Hybrid Workforces
Esta guía de referencia técnica explica cómo RADIUS as a Service protege el acceso a la red para plantillas híbridas en sedes distribuidas. Cubre la arquitectura, los beneficios de seguridad y los pasos de implementación para reemplazar la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Para los responsables de TI y arquitectos de red de hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona las pruebas necesarias para evaluar y llevar a cabo una migración a RADIUS en la nube este trimestre.