Autenticación WiFi empresarial sin Active Directory ni servidor local
Esta guía explica cómo implementar una autenticación WiFi segura WPA2/3-Enterprise sin un Active Directory local, Windows NPS o un servidor RADIUS físico. Cubre la incompatibilidad de protocolos entre los proveedores de identidad en la nube y 802.1X, los argumentos a favor de EAP-TLS sobre PEAP-MSCHAPv2 y cómo implementar RADIUS-as-a-Service con certificados emitidos por MDM para Microsoft Entra ID, Okta o Google Workspace. Escrito para líderes de TI en organizaciones que priorizan la nube y con una gran presencia de Mac/Chromebook que están listos para retirar la infraestructura local.
Video overview
Escucha esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad para WiFi empresarial →
Resumen ejecutivo
La mayoría de las organizaciones han migrado su identidad a la nube. Microsoft Entra ID, Okta y Google Workspace ahora gestionan usuarios, grupos y políticas de acceso para correo electrónico, aplicaciones SaaS y gestión de dispositivos. Sin embargo, el WiFi empresarial no ha seguido el mismo ritmo. Los puntos de acceso siguen esperando un servidor RADIUS, y ese servidor RADIUS históricamente ha sido 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 únicamente para mantener el WiFi en funcionamiento. La solución es un RADIUS en la nube: un servicio de autenticación totalmente gestionado que se comunica mediante RADIUS con sus puntos de acceso y mediante 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, obtendrá un despliegue completo de 802.1X sin servidores locales, sin parches de sistema operativo y con revocación de acceso instantánea vinculada directamente a su directorio en la nube.
Purple opera RADIUS en la nube en más de 80,000 ubicaciones a nivel mundial, 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 activo 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 idiomas 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 marcado telefónico y VPN. Microsoft nunca ha ofrecido un endpoint RADIUS nativo para Entra ID. No se puede apuntar un punto de acceso Meraki o Aruba directamente a Azure y esperar que funcione 802.1X.
Este es el obstáculo con el que se topa todo equipo de TI que prioriza la nube cuando intenta asegurar el WiFi del personal con WPA2-Enterprise o WPA3-Enterprise. Algo tiene que cerrar la brecha entre el punto de acceso y el proveedor de identidad en la nube. Ese algo es el RADIUS en la nube.
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. Esto no es un vacío de configuración - es 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 dirigido a Entra ID no puede validar un desafío PEAP-MSCHAPv2. La única manera de hacer que PEAP funcione con Entra ID es implementar Entra Domain Services, un Active Directory administrado de pago que se sincroniza desde Entra ID, y luego ejecutar NPS contra este. Esto vuelve a introducir la mayor parte de lo que intentaba eliminar: máquinas virtuales de Windows Server, parches de sistema operativo, almacenamiento de hashes NTLM y administración manual de certificados.
EAP-TLS: la respuesta correcta para organizaciones que priorizan la nube
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) reemplaza las contraseñas con certificados digitales X.509. El dispositivo presenta un certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra una Autoridad de Certificación (CA) de confianza. Debido a que no hay contraseña en el intercambio, el servidor RADIUS no necesita un almacén de hashes NTLM. Solo necesita confiar en la CA y verificar la membresía de 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 la guía de 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 manejan datos de titulares de tarjetas. Es el método de autenticación recomendado por IEEE 802.1X para flotas de dispositivos administrados.
Arquitectura de autenticación 802.1X que prioriza la nube: los dispositivos se autentican a través de EAP-TLS a través del RADIUS en la nube de Purple, que valida los certificados y aplica políticas basadas en grupos desde Entra ID, Okta o Google Workspace.
Cómo el MDM reemplaza a la CA local
En una implementación tradicional de 802.1X, los certificados eran emitidos por una Autoridad de Certificación local que ejecutaba Active Directory Certificate Services (AD CS). In una implementación que prioriza la nube, el MDM asume este rol 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 enviarlos de forma silenciosa a los dispositivos administrados.
El flujo funciona de la siguiente manera. El administrador de TI crea un perfil de certificado SCEP en el MDM, delimitado a los grupos de dispositivos que requieren acceso a la WiFi. El MDM envía el certificado a los dispositivos Windows, macOS, iOS, iPadOS, Android Enterprise y ChromeOS automáticamente. El usuario no ve nada. El certificado se vincula a la identidad del dispositivo en el MDM y se renueva automáticamente antes de su vencimiento. Cuando el dispositivo se conecta a la WiFi, presenta el certificado al servidor RADIUS en la nube, el cual 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 administrada que se integra directamente con los perfiles SCEP de Intune, lo que elimina la necesidad de un servidor NDES (Network Device Enrollment Service) de infraestructura local. Para las flotas de Mac y iOS administradas por Jamf, la CA integrada de Jamf o una CA en la nube de terceros cumple el mismo propósito.
SCIM y revocación de acceso instantánea
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 Microsoft 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 devuelve un 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 sobre las implementaciones heredadas de RADIUS que dependen de sincronizaciones periódicas de LDAP con una ventana 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 el internet público. RadSec (RADIUS sobre TLS, RFC 6614) cifra el intercambio RADIUS mediante TLS, lo que proporciona 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.
-
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Guía de implementación
La implementación de cloud RADIUS con EAP-TLS requiere cuatro pasos coordinados. Un SSID de prueba puede estar activo en menos de una hora si Microsoft Entra ID y un MDM ya están configurados.
Paso 1: Conecte cloud RADIUS a su proveedor de identidad
Conecte Purple a su proveedor de identidad mediante el consentimiento de administrador de OAuth2 (para Microsoft Entra ID) o un token de API (para Okta y Google Workspace). Esto autoriza a Purple a leer usuarios, grupos y membresías de 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 seguridad en el disco. Los cambios de grupo se propagan en el siguiente evento de autenticación, no en una programación de sincronización.
Paso 2: Configure su MDM y su perfil SCEP
En Microsoft Intune, cree un Perfil de certificado de confianza para la CA raíz, luego cree un perfil de certificado SCEP que apunte a la CA administrada por Purple. Defina el alcance de ambos perfiles para los grupos de dispositivos que requieren acceso a la 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 de RADIUS que asocien los grupos del proveedor de identidad con VLANs y controles de acceso específicos. Por 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 acceso limitado en el tiempo que expira automáticamente. El panel de Purple aplica estas políticas en el punto de autenticación, sin necesidad de realizar cambios en el firewall.
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. Ingrese los nombres de host o direcciones IP de los endpoints 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 según los atributos de RADIUS devueltos por Purple. Realice pruebas con un solo SSID en un subconjunto de puntos de acceso antes de implementarlo en toda la propiedad.
Cloud RADIUS frente a RADIUS local: una comparación directa entre el tiempo de implementación, la dependencia de Active Directory, la alta disponibilidad, el parchado del sistema operativo, la integración de identidad y la gestión del ciclo de vida de los certificados.
Mejores prácticas
Estas recomendaciones reflejan los estándares IEEE 802.1X, los requisitos de PCI-DSS v4.0 y la experiencia operativa en las más de 80,000 ubicaciones de Purple.
Exigir EAP-TLS para dispositivos administrados. Las contraseñas son susceptibles al phishing y al relleno de credenciales (credential stuffing). Los certificados proporcionan una prueba criptográfica de identidad y cumplimiento del dispositivo. EAP-TLS es el único método 802.1X que es resistente al phishing por diseño.
Utilizar SCIM para la revocación instantánea. Las sincronizaciones periódicas de LDAP dejan una ventana de tiempo en la 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.
Implementar RADIUS multirregión. Configure sus puntos de acceso con al menos dos endpoints de RADIUS en diferentes regiones geográficas. Purple proporciona tolerancia a fallas multirregión activo-activo de forma predeterminada, completando la transición en segundos.
Segmentar el tráfico con VLANs dinámicas. Utilice las membresías de grupo del proveedor de identidad para asignar a los usuarios a VLANs específicas de forma dinámica. Esto aísla el tráfico confidencial y limita el radio de impacto de un dispositivo comprometido sin requerir cambios manuales en el firewall.
Habilitar 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 de especial importancia para sucursales y ubicaciones donde el punto de acceso se encuentra en un segmento de red no confiable.
Monitorear el ciclo de vida de los certificados. Configure la renovación automática de 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. Genere alertas para los dispositivos que no se renueven antes de que expire el certificado. Para un análisis más amplio de las normas y marcos de seguridad de WiFi empresarial, consulte nuestro Enterprise WiFi Security: A Complete Guide for 2026.
Solución de problemas y mitigación de riesgos
La transición a RADIUS en la nube introduce nuevas dependencias. Prepárese para estos modos de falla comunes antes de que afecten a la producción.
Vencimiento de certificados. Si el certificado de un dispositivo vence antes de que el MDM lo renueve, la autenticación del dispositivo falla de forma silenciosa. El usuario ve un error de conexión sin ninguna explicación. Mitigue esto configurando la renovación automática de MDM al 80% de la vida útil del certificado y monitoreando el panel de cumplimiento de MDM para identificar dispositivos con certificados por vencer.
Fallas de sincronización de MDM. Es posible que un dispositivo que no cumple con las políticas de MDM o que no se registra no reciba un certificado renovado. Implemente políticas de cumplimiento que marquen los dispositivos en estado no óptimo y alerten a los administradores antes de que expire el certificado.
Bloqueo de tráfico RADIUS por firewall. Los puntos de acceso deben alcanzar los endpoints de RADIUS en la nube en el puerto UDP 1812 (autenticación) y el puerto UDP 1813 (contabilidad), o en el puerto TCP 2083 para RadSec. Las reglas de firewall salientes en las sucursales suelen bloquear estos puertos. Pruebe la conectividad desde la VLAN de gestión del punto de acceso antes de la implementación.
Fallas 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. Monitoree el estado de sincronización de SCIM tanto en el proveedor de identidad como en el panel de Purple. Configure alertas para fallas de sincronización.
Dispositivos heredados sin soporte de certificados. Es posible que los dispositivos IoT, impresoras y hardware más antiguo no admitan 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 requerir 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 | RADIUS en la nube (Purple) |
|---|---|---|
| Costo de infraestructura | Licencias de Windows Server, cómputo de VM, almacenamiento | Suscripción por AP, sin hardware de servidor |
| Tiempo de implementación | Días a semanas | Menos de una hora |
| Alta disponibilidad | Manual - dos servidores más replicación | Activo-activo multirregión por defecto |
| Parches de OS | Mensual, por su equipo | Gestionado por el proveedor |
| Tickets de soporte de WiFi | Alto - restablecimiento de contraseñas, incorporación manual | Reducción del 80% (datos de clientes de Purple) |
| Revocación de acceso | Horas a días a través de sincronización LDAP | Segundos a través de SCIM |
Los equipos de TI que utilizan el Staff WiFi de Purple suelen ver una reducción del 80% en los tickets de soporte de WiFi (datos internos de Purple, 2024), impulsada por la eliminación de los restablecimientos de contraseñas y 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 en su equipo de seguridad.
Para las organizaciones de los sectores de retail y hospitalidad, la capacidad de administrar el Staff WiFi y el Guest WiFi desde un único panel en la nube - con una capa de identidad unificada - reduce la complejidad operativa en propiedades de múltiples sitios. Para los operadores de transporte y los proveedores de atención médica, la capacidad de revocación instantánea y el registro de auditoría completo cumplen con los requisitos regulatorios sin necesidad de herramientas adicionales.
La capa de WiFi Analytics de Purple añade datos de ocupación y trabajo híbrido a la infraestructura de autenticación, transformando el Staff WiFi de un centro de costos a una fuente de inteligencia operativa.
-
Lectura relacionada: Enterprise WiFi Security: A Complete Guide for 2026 - OpenWrt Custom Firmware Integration with Purple WiFi
Definiciones clave
802.1X
Un estándar IEEE (IEEE 802.1X-2020) para el control de acceso a redes 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, el cual decide si admite el dispositivo y a qué VLAN asignarlo. El Cloud RADIUS reemplaza los servidores NPS o FreeRADIUS locales.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Un método de autenticación 802.1X que utiliza el intercambio mutuo de certificados X.509 en lugar de contraseñas.
EAP-TLS es el estándar de oro para flotas de dispositivos administrados. Es resistente al phishing, no requiere almacenamiento de hash de contraseñas y es el único método 802.1X que satisface la guía 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 que son exclusivamente en la nube debido a que Entra ID no almacena hashes NTLM. Las organizaciones que migran desde AD local deben reemplazar PEAP con EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Un protocolo utilizado por las plataformas MDM para solicitar e instalar certificados digitales en dispositivos de forma automática, sin interacción del usuario.
Los equipos de TI utilizan SCEP con Intune o Jamf para proporcionar silenciosamente certificados de WiFi a los dispositivos de los empleados. SCEP reemplaza al servidor local NDES (Network Device Enrollment Service) en despliegues con enfoque de nube primero.
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 usuario entre sistemas de TI.
SCIM garantiza que cuando se deshabilita a un empleado en Entra ID u Okta, ese cambio se envíe de inmediato al servicio de cloud RADIUS, revocando el acceso a WiFi en cuestión de segundos en lugar de horas.
NPS
Network Policy Server. La implementación RADIUS de Microsoft, que normalmente se ejecuta en Windows Server como parte de un entorno de Active Directory local.
Las organizaciones con enfoque de nube primero están retirando NPS para eliminar las VM de Windows Server, el parchado del sistema operativo y la dependencia de Active Directory local. Cloud RADIUS es el reemplazo directo.
RadSec
RADIUS sobre TLS (RFC 6614). Un protocolo que cifra el tráfico de autenticación de RADIUS utilizando TLS, reemplazando el transporte de texto sin formato 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 compartida previa ú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 es compatible con 802.1X EAP-TLS. Proporciona responsabilidad por dispositivo y asignación de VLAN sin requerir soporte de certificados.
Dynamic VLAN
Una técnica de segmentación de red donde el servidor RADIUS devuelve un identificador de VLAN en la respuesta Access-Accept, y el punto de acceso coloca el dispositivo en esa VLAN automáticamente.
Las VLAN dinámicas permiten a los equipos de TI segmentar al personal, contratistas, dispositivos IoT y visitantes en segmentos de red independientes en función de su pertenencia a grupos de proveedores de identidad, sin necesidad de realizar cambios manuales en el firewall.
Ejemplos resueltos
Una cadena minorista con 400 sucursales necesita proteger la red WiFi del personal en todas sus ubicaciones. Utilizan puntos de acceso Cisco Meraki y emplean Microsoft Entra ID con Intune para la gestión de dispositivos. Actualmente utilizan una clave compartida WPA2-Personal PSK porque no tienen 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 servicio de RADIUS en la nube de Purple. Primero, 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 todas las terminales de punto de venta administradas y a las tablets del personal. En el panel de administración de Meraki, actualizan el SSID del personal a WPA2-Enterprise, ingresan los puntos de conexión primario y secundario de RADIUS en la nube 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 con la CA y comprueba el grupo de Entra ID, y el dispositivo se coloca en la VLAN 10 (red del personal) o en la VLAN 20 (red de administración) según su pertenencia al grupo. Se retira la PSK compartida. El despliegue en las 400 sucursales se realiza en un solo fin de semana, ya que no se implementa hardware físico en el sitio, 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 proporcionar WiFi seguro para el personal y los estudiantes en un parque de dispositivos BYOD compuesto por MacBooks, Chromebooks y teléfonos Android. No tienen Active Directory local ni interés en administrar servidores.
La universidad integra el RADIUS en la nube de Purple con Google Workspace. Para las Chromebooks administradas, utilizan Google Admin para enviar un perfil de certificado WiFi a través de SCEP, registrando silenciosamente cada dispositivo. Para las MacBooks y teléfonos Android BYOD, implementan una aplicación de incorporación ligera 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 mapea las Unidades Organizacionales de Google Workspace a las VLAN: el personal se asigna 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 su cuenta de Google se suspende, SCIM envía el cambio a Purple y su acceso a la WiFi se revoca en cuestión de minutos.
Preguntas de práctica
Q1. Su organización se ha migrado por completo de Active Directory local a Microsoft Entra ID. Su WiFi de personal actual utiliza PEAP-MSCHAPv2 contra un servidor NPS que estaba unido al antiguo dominio. Después de retirar el controlador de dominio, el personal informa que ya no puede conectarse a la 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. Con el controlador de dominio retirado, NPS no tiene un directorio contra el cual realizar la validación. Entra ID no almacena hashes NTLM, por lo que NPS no puede redirigirse a Entra ID. La solución correcta a largo plazo es reemplazar NPS con un servicio de 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 una flota de 200 dispositivos MacBook corporativos administrados 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 contraseñas y se integre con su MDM existente.
Ver respuesta modelo
Configure Jamf Pro para usar SCEP para enviar de forma silenciosa certificados de dispositivo a las MacBook. Cree una carga útil SCEP en un perfil de configuración de Jamf, apuntando a la CA administrada por su proveedor de cloud RADIUS. Asigne el alcance del perfil al grupo de dispositivos correspondiente. Jamf enviará el certificado a cada MacBook automáticamente, sin interacción del usuario. Configure el perfil de WiFi en el mismo perfil de configuración para usar EAP-TLS con el certificado emitido por SCEP. Conecte el servicio de cloud RADIUS a Okta a través de SCIM para garantizar que cuando se deshabilite a un empleado en Okta, su acceso a la WiFi se revoque de inmediato.
Q3. Un empleado es despedido a las 9:00 a. m. de un lunes. RR. HH. deshabilita su cuenta de Entra ID a las 9:05 a. m. A las 9:30 a. m., una alerta de seguridad muestra que la laptop del empleado todavía está conectada a la WiFi corporativa desde el estacionamiento. ¿Qué configuración hace 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
La implementación depende de sincronizaciones periódicas de LDAP en lugar de un aprovisionamiento SCIM. La sincronización LDAP aún no se ha ejecutado desde que se deshabilitó la cuenta, por lo que el servicio cloud RADIUS todavía considera que el usuario está activo. La solución es habilitar el aprovisionamiento SCIM entre Entra ID y el servicio cloud RADIUS. SCIM envía los cambios de estado del usuario en tiempo real, por lo que cuando la cuenta se deshabilita en Entra ID a las 9:05 a. m., 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 inhabilitación de la cuenta y la expulsión de la red.
Q4. Su sede tiene 50 dispositivos IoT - reproductores de señalización digital, sensores ambientales e impresoras - que no son compatibles con 802.1X EAP-TLS. ¿Cómo protege estos dispositivos en la misma infraestructura WiFi que su red de personal con EAP-TLS?
Sugerencia: Considere qué método de autenticación proporciona responsabilidad por dispositivo sin requerir soporte para certificados.
Ver respuesta modelo
Utilice iPSK (claves precompartidas individuales) para los dispositivos IoT. Asigne una clave precompartida única a cada dispositivo en el panel de cloud RADIUS, junto con una asignación de VLAN. Cada dispositivo se autentica con su clave única, la cual el servidor RADIUS valida y utiliza para colocar el dispositivo en la VLAN de IoT, de forma aislada de la red de personal. Si un dispositivo se ve comprometido o se retira, solo revoca la clave de ese dispositivo sin afectar a ningún otro. Este enfoque proporciona responsabilidad por dispositivo y segmentación de red sin requerir soporte de suplicante 802.1X en el hardware IoT.
Continúe leyendo esta serie
Cómo revocar el acceso a WiFi cuando un empleado se va
Esta guía muestra a los equipos de TI y de operaciones de recintos cómo eliminar el acceso de un empleado a la WiFi del personal cuando este se retira, sin interrumpir al resto de los trabajadores. Compara la desvinculación basada en certificados 802.1X, iPSK de identidad específica y aprovisionamiento controlado por SCIM, para luego ofrecer un manual de procedimientos para el mismo día, un método de prueba y un modelo de evidencia de auditoría.
WiFi seguro para BYOD: Incorporación con certificados Passpoint vs xPSK (iPSK)
Una guía técnica completa para equipos de TI sobre cómo proteger los dispositivos no gestionados de empleados y estudiantes (BYOD) mediante certificados Passpoint EAP-TLS de instalación sin intervención frente a tecnologías xPSK específicas de cada proveedor (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal frente a Enterprise: ¿cuál es la diferencia y cuál debería utilizar?
Esta guía de referencia técnica ofrece una comparación detallada de los protocolos de seguridad WPA2 Personal y WPA2 Enterprise en entornos de WiFi empresariales. Describe las diferencias de arquitectura, las metodologías de implementación y las implicaciones de seguridad de cada estándar para ayudar a los arquitectos de red y a los líderes de TI a tomar decisiones de implementación fundamentadas.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.