Autenticación WiFi empresarial sin Active Directory ni un 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 sobre PEAP-MSCHAPv2 y cómo implementar RADIUS en la nube con certificados emitidos por MDM contra Microsoft Entra ID, Okta o Google Workspace. Escrita para líderes de TI en organizaciones cloud-first y con un alto uso de Mac/Chromebook que están listas para retirar la infraestructura local.
Escucha 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 ahora administran usuarios, grupos y políticas de acceso para correo electrónico, aplicaciones SaaS y gestión de dispositivos. Pero el WiFi empresarial no ha seguido el 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 con el único fin de mantener el WiFi en funcionamiento. La solución es RADIUS en la nube: un servicio de autenticación totalmente administrado que habla RADIUS con sus puntos de acceso y habla OAuth2, SCIM y SAML con su proveedor de identidad en la nube. Combínelo con la entrega de certificados EAP-TLS a través de su MDM y tendrá una implementación completa de 802.1X sin servidores locales, sin parchado 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 establecimientos 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 profundo
La incompatibilidad de protocolos en el corazón 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 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.
Esta es la pared con la que se topa todo equipo de TI cloud-first cuando intenta proteger 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, las implementaciones de 802.1X dependían de PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versión 2). El usuario escribí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 una brecha 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 apuntado 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 administrado de pago que se sincroniza desde Entra ID, y luego ejecutar NPS contra este. Esto reintroduce la mayor parte de lo que intentaba eliminar: máquinas virtuales de Windows Server, parchado 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) 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. Al no haber contraseñas en el intercambio, el servidor RADIUS no necesita un almacenamiento de hashes NTLM. Solo necesita confiar en la CA y verificar 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 la guía 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 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 cloud-first: los dispositivos se autentican a través de EAP-TLS mediante el RADIUS en la nube de Purple, el cual 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). En una implementación cloud-first, 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 silenciosamente a los dispositivos administrados.
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 envía 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 su vencimiento. Cuando el dispositivo se conecta al 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, eliminando la necesidad de un servidor local NDES (Network Device Enrollment Service). Para flotas de Mac e iOS administradas 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 límite de tiempo 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.
Esta es una mejora de seguridad sustancial en comparación con las redes PSK compartidas, donde la única forma de revocar el acceso es cambiar la contraseña en cada dispositivo, y con 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 se encuentra 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 internet pública. 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.
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: Conecte 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 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 servicio en el disco. Los cambios de grupo se propagan en el siguiente evento de autenticación, no en un programa de sincronización.
Paso 2: Configure su MDM y 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. Asigne ambos perfiles a los grupos de dispositivos que requieren acceso a 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: Defina las políticas de red en el panel de cloud RADIUS
Cree políticas RADIUS que mapeen los grupos de proveedores de identidad con VLAN y controles de acceso específicos. Por ejemplo, mapee el grupo de Entra ID "Staff-Finance" a la VLAN 20 con acceso total a internet, y mapee "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: Actualice la configuración del punto de acceso
Actualice la configuración del SSID en sus puntos de acceso para usar 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 usar la asignación dinámica de VLAN basada en los atributos RADIUS devueltos por Purple. Realice pruebas con un solo 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 entre el tiempo de implementación, la dependencia de Active Directory, la alta disponibilidad, el parcheo 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 la infraestructura de más de 80,000 establecimientos de Purple.
Exija EAP-TLS para los 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 resistente al phishing por diseño.
Utilice SCIM para la revocación instantánea. Las sincronizaciones LDAP periódicas 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 endpoints RADIUS en diferentes regiones geográficas. Purple proporciona conmutación por error multirregión activo-activo de forma predeterminada, la cual se completa en cuestión de segundos.
Segmente el tráfico con VLAN dinámicas. Utilice las membresías de grupo 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 requerir cambios manuales en el firewall.
Habilite RadSec. Si sus puntos de acceso admiten 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 confiable.
Monitoree 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. Genere alertas para los dispositivos que no se renueven antes de que expire el certificado.
Para un análisis más amplio de los estándares y marcos de seguridad de WiFi empresarial, consulte nuestra guía Seguridad de WiFi empresarial: una 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 modos de falla comunes antes de que afecten a la producción.
Cervencimiento de certificados.** Si el certificado de un dispositivo expira antes de que el MDM lo renueve, la autenticación del dispositivo fallará de forma silenciosa. El usuario verá un error de conexión sin ninguna explicación. Mitigue esto configurando la autorenovación de MDM al 80% del tiempo de vida del certificado y monitoreando el panel de cumplimiento de MDM para identificar dispositivos con certificados por vencer.
Fallos de sincronización de MDM. Es posible que un dispositivo que deje de cumplir con las políticas de MDM o que no se reporte no reciba un certificado renovado. Implemente políticas de cumplimiento que marquen los dispositivos en estado no saludable y alerten a los administradores antes de que expire el certificado.
Bloqueo de tráfico RADIUS por firewall. Los puntos de acceso deben 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 firewall de salida en las sucursales suelen bloquear estos puertos. Pruebe la conectividad desde la VLAN de administración del punto de acceso antes de la implementación.
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. Monitoree el estado de sincronización de SCIM tanto en el proveedor de identidad como en el panel de Purple. Configure alertas para fallos de sincronización.
Dispositivos heredados sin soporte de certificados. Los dispositivos IoT, impresoras y 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 es compatible con 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
Migrar de un RADIUS local a un RADIUS en la nube ofrece un valor medible en infraestructura, operaciones y seguridad.
| Dimensión | NPS local | Cloud RADIUS (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 |
| Parcheo de SO | 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 mediante sincronización LDAP | Segundos mediante 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 autenticación robusta 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 en los sectores de retail y hospitalidad , la capacidad de gestionar Staff WiFi y 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 proveedores de atención médica , la capacidad de revocación instantánea y el historial 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 sobre la infraestructura de autenticación, transformando el Staff WiFi de un centro de costos 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 otorgue 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 historial 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 qué VLAN le asigna. RADIUS en la nube reemplaza 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 administrados. Es resistente al phishing, no requiere almacenamiento de hashes de contraseñas y es el único método 802.1X que cumple con 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 exclusivamente en la nube porque Entra ID no almacena hashes NTLM. Las organizaciones que migran desde un 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 aprovisionar silenciosamente certificados WiFi en los dispositivos de los empleados. SCEP reemplaza al servidor local NDES (Network Device Enrollment Service) en implementaciones 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 u Okta, ese cambio se envíe al servicio RADIUS en la nube de inmediato, 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 generalmente 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 parchado del sistema operativo y la dependencia de un Active Directory local. RADIUS en la nube es el reemplazo directo.
RadSec
RADIUS sobre TLS (RFC 6614). Un protocolo que cifra el tráfico de autenticación RADIUS mediante TLS, reemplazando el transporte de texto claro basado en UDP utilizado por el RADIUS tradicional.
RadSec es esencial cuando se utiliza RADIUS en la nube, ya que el tráfico de autenticación debe atravesar el internet público 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 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 en la que 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 VLANs dinámicas permiten a los equipos de TI segmentar al personal, contratistas, dispositivos IoT e invitados en segmentos de red separados según su pertenencia a grupos del proveedor de identidad, sin cambios manuales en el firewall.
Ejemplos resueltos
Una cadena minorista de 400 sucursales necesita proteger la red WiFi del personal en todas sus ubicaciones. Utilizan puntos de acceso Cisco Meraki y Microsoft Entra ID con Intune para la gestión de dispositivos. Actualmente usan una PSK compartida WPA2-Personal 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 de PCI DSS.
La cadena implementa el 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 envía silenciosamente los certificados a todas las terminales de punto de venta y tabletas del personal administradas. En el panel de Meraki, actualizan el SSID del personal a WPA2-Enterprise, ingresan los endpoints 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 contra la CA y verifica el grupo de Entra ID, y el dispositivo se coloca en la VLAN 10 (red del personal) o VLAN 20 (red de administración) según su pertenencia al grupo. Se retira la PSK compartida. El despliegue en las 400 sucursales toma un fin de semana, ya que no se implementa hardware en el sitio, solo cambios de configuración de SSID en Meraki.
Una universidad de 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 entorno BYOD de MacBooks, Chromebooks y teléfonos Android. No tienen un 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 de tipo 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 mapea las Unidades Organizativas de Google Workspace a VLANs: 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 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 WiFi del personal actual utiliza PEAP-MSCHAPv2 contra un servidor NPS que estaba unido al dominio antiguo. Después de desmantelar el controlador de dominio, el personal informa que ya no puede conectarse al WiFi. ¿Cuál es la causa raíz y cuál es la solución correcta a largo plazo?
Sugerencia: Considere lo que PEAP-MSCHAPv2 requiere del directorio y si Entra ID lo proporciona.
Ver respuesta modelo
La causa raíz 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 desmantelado, NPS no tiene un directorio contra el cual validar. 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 RADIUS en la nube, migrar de PEAP-MSCHAPv2 a EAP-TLS y usar el MDM (Intune) para emitir certificados de dispositivo a través de SCEP. Esto elimina la dependencia de cualquier directorio local.
Q2. Está implementando RADIUS en la nube para una flota de 200 MacBooks corporativas administradas por Jamf Pro. Su proveedor de identidad es Okta. ¿Cuál es la forma más segura y operativamente eficiente de aprovisionar las credenciales de 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 silenciosamente certificados de dispositivo a las MacBooks. Cree una carga útil SCEP en un perfil de configuración de Jamf, apuntando a la CA administrada por su proveedor de RADIUS en la nube. 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 de WiFi en el mismo perfil de configuración para usar EAP-TLS con el certificado emitido por SCEP. Conecte el servicio RADIUS en la nube 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 a. m. de un lunes. Recursos Humanos 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 al WiFi corporativo desde el estacionamiento. ¿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
La implementación depende de sincronizaciones periódicas de LDAP en lugar del aprovisionamiento SCIM. La sincronización de LDAP aún no se ha ejecutado desde que se deshabilitó la cuenta, por lo que el servicio RADIUS en la nube todavía considera al usuario como activo. La solución es habilitar el aprovisionamiento SCIM entre Entra ID y el servicio RADIUS en la nube. 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. Configurar un tiempo de espera de sesión corto (de 15 a 30 minutos) en el punto de acceso limita la ventana máxima entre la inhabilitació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 son compatibles con 802.1X EAP-TLS. ¿Cómo protege estos dispositivos en la misma infraestructura WiFi que la red de su personal con EAP-TLS?
Sugerencia: Considere qué método de autenticación proporciona responsabilidad por dispositivo sin requerir soporte de 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 RADIUS en la nube, 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, aislada de la red del personal. Si un dispositivo se ve comprometido o se retira del servicio, usted revoca únicamente 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 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 multi-inquilino mediante Dynamic PSK de Ruckus.
Allied Telesis Access Points Integration with 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 implementaciones multiinquilino seguras.
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 fuerzas de trabajo híbridas en entornos distribuidos. 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 gerentes de TI y arquitectos de redes en hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona la evidencia necesaria para evaluar y ejecutar una migración a RADIUS en la nube este trimestre.