Integrating RADIUS as a Service with Cloud Directories (Azure AD & Google Workspace)
This technical reference guide details how to integrate RADIUS as a Service with cloud directories - Microsoft Entra ID and Google Workspace - for enterprise WiFi authentication. It covers the architectural shift from on-premise NPS to cloud-native RADIUS, the deployment of certificate-based EAP-TLS authentication, and the operational best practices for securing wireless access across hospitality, retail, and public-sector environments. For IT managers and network architects already invested in cloud identity, this guide bridges the gap between directory management and physical network security.
Escucha esta guía
Ver transcripción del podcast
Resumen ejecutivo
Para las empresas modernas que invierten en ecosistemas de identidad en la nube, conectar los directorios en la nube con las redes inalámbricas físicas es un imperativo de seguridad crítico. Históricamente, la autenticación de WiFi dependía de Active Directory Domain Services locales y de Windows Network Policy Server (NPS). A medida que las organizaciones migran a Microsoft Entra ID y Google Workspace, esa pila de autenticación local se convierte en una carga: costosa de mantener, difícil de escalar e incompatible con los modelos de seguridad zero-trust.
RADIUS como Servicio (RADIUSaaS) cambia la ecuación. Un servidor RADIUS alojado en la nube se integra directamente con su directorio en la nube, valida las solicitudes de autenticación en tiempo real y devuelve las decisiones de acceso a sus puntos de acceso, sin servidores locales, sin ciclos de parches y sin un único punto de falla. Combinada con la autenticación basada en certificados EAP-TLS, esta arquitectura elimina el robo de credenciales, respalda el cumplimiento de PCI DSS y GDPR, y ofrece una experiencia fluida para el personal en cada sitio.
Esta guía cubre la decisión arquitectónica entre NPS local y RADIUS nativo de la nube, la implementación de EAP-TLS a través de Microsoft Intune y Google Admin Console, y las mejores prácticas operativas para proteger el acceso inalámbrico en hoteles, complejos comerciales, estadios y sedes del sector público. Para una introducción más amplia al control de acceso a la red, consulte Una guía para su sistema de control de acceso a la red .
Análisis técnico profundo: arquitectura y estándares
El papel de RADIUS y IEEE 802.1X
La base de un WiFi empresarial seguro es el estándar IEEE 802.1X, que proporciona control de acceso a la red basado en puertos. Cuando un dispositivo cliente (el suplicante) intenta conectarse a una red WPA2-Enterprise o WPA3-Enterprise, el punto de acceso inalámbrico (el autenticador) bloquea todo el tráfico excepto los paquetes EAP (Extensible Authentication Protocol). El AP reenvía estos paquetes a un servidor RADIUS. El servidor RADIUS valida la identidad frente a un servicio de directorio y devuelve un mensaje Access-Accept o Access-Reject. Solo entonces el AP otorga acceso a la red.
Este modelo de tres partes (suplicante, autenticador, servidor de autenticación) es la piedra angular de la seguridad inalámbrica empresarial y está definido en IEEE 802.1X. No ha cambiado fundamentalmente desde su introducción. Lo que ha cambiado es dónde reside el servidor RADIUS y cómo se comunica con su directorio.
Arquitectura RADIUS nativa de la nube
Una arquitectura RADIUS nativa de la nube elimina la necesidad de servidores NPS o FreeRADIUS locales. Un proveedor externo de Cloud RADIUS se integra directamente con Microsoft Entra ID a través de la API de Microsoft Graph, o con Google Workspace a través de Google Secure LDAP o SAML/OAuth. La autenticación ocurre completamente en la nube. Esto se alinea con los principios de acceso a la red de confianza cero y reduce significativamente los gastos operativos.
La siguiente tabla compara los dos enfoques arquitectónicos principales:
| Dimensión | Híbrido local (NPS) | Nativo de la nube (RADIUSaaS) |
|---|---|---|
| Infraestructura | Se requiere VM de Windows Server o hardware dedicado | Sin servidores locales |
| Origen de identidad | AD DS a través de LDAP/Kerberos | Entra ID o Google Workspace a través de API |
| Autoridad de certificación | ADCS local + Intune Connector | PKI en la nube del proveedor o de Microsoft |
| Alta disponibilidad | HA manual y balanceo de carga | Escalado automático por el proveedor |
| Tiempo de configuración | Días a semanas | Horas |
| Ideal para | AD híbrido, dispositivos heredados | Organizaciones que priorizan la nube y gestionadas por MDM |
| Complejidad operativa | Mayor complejidad inicial y continua | Menores gastos operativos |
EAP-TLS vs. PEAP-MSCHAPv2: la decisión crítica
La elección del método EAP es la decisión de seguridad más trascendental en esta implementación. PEAP-MSCHAPv2 depende de que los usuarios ingresen sus credenciales de dominio. Esto es vulnerable al robo de credenciales y a ataques de intermediario (man-in-the-middle). Si un dispositivo cliente no valida estrictamente el certificado del servidor RADIUS (y muchos no lo hacen de forma predeterminada), un atacante puede desplegar un punto de acceso no autorizado con su SSID, interceptar el saludo EAP y capturar las credenciales. Este es un ataque de tipo Evil Twin y está ampliamente documentado.
EAP-TLS (Transport Layer Security) utiliza certificados digitales instalados en el dispositivo cliente para la autenticación mutua. Tanto el cliente como el servidor demuestran su identidad de forma criptográfica. No hay contraseñas que escribir ni que puedan ser robadas. En un entorno de Microsoft, los certificados se despliegan de forma silenciosa a través de Microsoft Intune utilizando perfiles SCEP (Simple Certificate Enrollment Protocol) o PKCS. Este es el camino recomendado para todas las nuevas implementaciones y es esencial para cumplir con PCI DSS v4.0 (Requisito 8.3 sobre autenticación sólida) y las obligaciones de protección de datos de la GDPR.
Google Workspace: la diferencia arquitectónica
Microsoft Entra ID y Google Workspace difieren en un aspecto importante para la integración de RADIUS. Microsoft NPS se integra de forma nativa con Active Directory, y los proveedores de Cloud RADIUS se conectan a Entra ID a través de la API de Microsoft Graph. Google, sin embargo, no ofrece un servicio RADIUS nativo. Siempre se necesita un intermediario.
Google Secure LDAP es la ruta de integración principal. Disponible en las ediciones Cloud Identity Premium y Google Workspace Enterprise, proporciona una interfaz LDAP tradicional para su directorio en la nube. Su servidor Cloud RADIUS se conecta a ldap.google.com en el puerto 636 utilizando certificados de cliente que Google genera para usted. A partir de ese punto, el servidor RADIUS consulta el directorio de Google para validar credenciales o membresías de grupo, tal como lo haría con un Active Directory local.
Una ruta alternativa utiliza la integración basada en SAML, donde el proveedor de Cloud RADIUS se registra como una aplicación SAML en la Google Admin Console y realiza una búsqueda OAuth al momento de la autenticación para verificar la identidad del usuario y sus membresías de grupo en tiempo real.
Guía de implementación
La implementación de RADIUSaaS con EAP-TLS requiere coordinar la identidad, la gestión de dispositivos y la infraestructura de red. El siguiente enfoque de cinco fases se aplica tanto a entornos de Microsoft Entra ID como de Google Workspace.
Fase 1: preparar la infraestructura de identidad y gestión de dispositivos
Para Microsoft Entra ID: verifique que su tenant cuente con licencias de Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Esto incluye Microsoft Intune y Conditional Access. Sin Intune, la implementación automatizada de certificados no es posible.
Para Google Workspace: confirme que dispone de Cloud Identity Premium o Google Workspace Enterprise para acceder a Google Secure LDAP. Si planea utilizar EAP-TLS en Chromebooks administrados, asegúrese de que la Google Admin Console esté configurada para administrar certificados de dispositivos.
Establezca su infraestructura de clave pública (PKI). Para nuevas implementaciones, se recomienda encarecidamente una PKI nativa de la nube proporcionada por su proveedor de Cloud RADIUS. Las alternativas incluyen Microsoft Cloud PKI (disponible con la licencia de Intune Suite) o una implementación de ADCS local existente conectada a través del Microsoft Intune Certificate Connector.
Fase 2: configurar la implementación de certificados
Ruta de Microsoft Intune: en el centro de administración de Intune, cree un perfil de configuración de Certificado de confianza. Cargue el certificado de la CA raíz y despliéguelo en sus grupos de dispositivos de destino. Esto garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el saludo TLS. A continuación, cree un perfil de Certificado SCEP. Para la autenticación basada en usuarios, establezca el Nombre del sujeto en CN={{UserPrincipalName}}. Para la autenticación basada en dispositivos, utilice CN={{DeviceName}}. Configure el Nombre alternativo del sujeto para incluir el User Principal Name o el ID del dispositivo.
Ruta de Google Admin Console: vaya a Dispositivos, luego a Redes y después a Certificados. Cargue su CA raíz. Configure un mecanismo de emisión de certificados, ya sea una PKI en la nube que admita la integración de SCEP con Google Workspace, o el Google Cloud Certificate Connector que actúa como proxy para las solicitudes a una entidad de certificación de Microsoft local. Despliegue la CA raíz y los perfiles de certificado de cliente en las unidades organizativas correspondientes.
Fase 3: configurar la integración de Cloud RADIUS
Otorga a tu proveedor de Cloud RADIUS los permisos de API necesarios en tu inquilino de directorio. Para Entra ID, esto requiere como mínimo User.Read.All y GroupMember.Read.All a través de Microsoft Graph API. Algunos proveedores también requieren Device.Read.All para las comprobaciones de cumplimiento de dispositivos. Para Google Workspace a través de Secure LDAP, descarga el certificado de cliente y la clave desde la consola de administración de Google e instálalos en el servicio RADIUS.
Define tus políticas de autenticación dentro del portal de administración de Cloud RADIUS. Una política bien estructurada para un entorno corporativo: "Permitir el acceso si el certificado es emitido por [CA de confianza] Y el usuario es miembro del grupo [Corporate-WiFi-Users] Y el dispositivo está marcado como Compliant en Intune". Esto aplica la identidad, la pertenencia a grupos y el estado del dispositivo de forma simultánea.
Fase 4: configurar la infraestructura inalámbrica
En tu controlador de LAN inalámbrica o panel de administración en la nube (Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet), agrega las direcciones IP y los secretos compartidos del servidor Cloud RADIUS como servidores de autenticación RADIUS. Configura servidores primarios y secundarios para redundancia. Establece el tiempo de espera de RADIUS en un mínimo de cinco segundos para adaptarse a la latencia de ida y vuelta de la nube.
Crea un nuevo SSID configurado para WPA2-Enterprise o WPA3-Enterprise. Para implementaciones en Hospitality , asegúrate de que el SSID corporativo esté en una VLAN separada de cualquier red de Guest WiFi . Para entornos de Retail , considera implementar el SSID corporativo únicamente en las áreas internas.
Fase 5: implementar el perfil de WiFi a través de MDM
Microsoft Intune: crea un perfil de configuración de WiFi. Configura el SSID para que coincida exactamente con la configuración de tu infraestructura. Selecciona WPA2-Enterprise o WPA3-Enterprise. En la configuración de EAP, selecciona EAP-TLS. Vincula el perfil de certificado SCEP como el certificado de cliente y especifica el perfil de CA raíz de confianza. Asigna este perfil de WiFi a los mismos grupos de dispositivos que recibieron los perfiles de certificado. Los dispositivos reciben de forma silenciosa el certificado y la configuración de WiFi durante su próxima sincronización con Intune.
Google Admin Console: navega a Dispositivos, luego a Redes y después a Wi-Fi. Crea un nuevo perfil de red WiFi. Configura el SSID, selecciona WPA3-Enterprise, elige EAP-TLS y envía el certificado de CA raíz de confianza a los dispositivos. Aplica este perfil a tus Unidades Organizativas. Los Chromebooks se conectarán de forma silenciosa y segura.
Mejores prácticas
Exige EAP-TLS en todas las nuevas implementaciones. No implementes redes nuevas utilizando PEAP-MSCHAPv2. Los riesgos de seguridad están bien documentados y la ruta de migración es sencilla con las herramientas de MDM modernas. Exija una validación estricta del certificado del servidor. Si debe utilizar PEAP para dispositivos heredados, configure los dispositivos para que validen el certificado del servidor RADIUS. En el perfil de WiFi de Intune y en el perfil de WiFi de Google Admin Console, hay un campo para especificar la CA de confianza para la validación del servidor. No deje esto en blanco. Esta única decisión de configuración es la diferencia entre una implementación segura y una vulnerable.
Segmente su red con asignación dinámica de VLAN. Utilice su servidor RADIUS para inspeccionar la pertenencia a grupos del usuario en Entra ID o Google Workspace y asígnelos dinámicamente a diferentes VLAN. El servidor RADIUS devuelve el atributo Tunnel-Private-Group-Id al punto de acceso, el cual coloca al cliente en la VLAN correcta. Esto limita el movimiento lateral en caso de un compromiso de seguridad y respalda los requisitos de segmentación de red de PCI DSS.
Separe la autenticación corporativa y la de invitados. Utilice EAP-TLS para dispositivos administrados por la empresa. Utilice un Captive Portal con SSO para dispositivos BYOD y de invitados. Intentar configurar manualmente EAP-TLS en dispositivos no administrados genera una sobrecarga de soporte excesiva. La plataforma de Guest WiFi de Purple gestiona el registro de invitados por separado, manteniendo una separación clara entre el tráfico del personal y el de los visitantes.
Monitoree la expiración de certificados de forma proactiva. Configure el monitoreo y las alertas a los 90 días, 30 días y siete días antes de la expiración del certificado. Si el certificado de su servidor RADIUS expira, todos los dispositivos perderán la conectividad simultáneamente. Automatice la renovación donde su PKI lo admita.
Pruebe la configuración de tiempo de espera (timeout) de RADIUS. Cloud RADIUS introduce una latencia de ida y vuelta de red que el NPS local no presenta. Establezca el tiempo de espera de RADIUS en sus puntos de acceso en al menos cinco segundos. Un tiempo de espera de dos segundos (común en las configuraciones predeterminadas) provocará fallas de autenticación intermitentes.
Resolución de problemas y mitigación de riesgos
Los puertos de firewall bloqueados son la causa principal de fallas en la implementación inicial. La autenticación RADIUS requiere el puerto UDP 1812 de salida desde su infraestructura inalámbrica hacia el servicio Cloud RADIUS. La contabilidad (accounting) de RADIUS requiere el puerto UDP 1813. Verifique que estos estén abiertos antes de realizar cualquier otra acción de resolución de problemas.
Las fallas de validación de certificados se presentan como rechazos de autenticación sin una causa obvia. Verifique lo siguiente en orden: la expiración del certificado tanto en el cliente como en el servidor RADIUS; el desfase de reloj entre el dispositivo cliente y el servidor RADIUS (EAP-TLS depende de un registro de tiempo preciso); y si el certificado de la CA raíz se ha implementado correctamente en el dispositivo a través de MDM.
La no aplicación de la pertenencia a grupos es un problema común cuando las políticas de RADIUS hacen referencia a grupos de Entra ID o Google Workspace. Verifique que el proveedor de Cloud RADIUS tenga los permisos de API correctos para leer las pertenencias a grupos. En Entra ID, confirme que la entidad de servicio tenga GroupMember.Read.All. En Google Workspace, confirme que el cliente de Secure LDAP tenga permiso para leer la información del grupo.
La asignación de VLAN no funciona normalmente indica una discrepancia entre los valores de los atributos RADIUS y los ID de VLAN configurados en la infraestructura inalámbrica. Confirme que Tunnel-Type esté configurado en VLAN (valor 13), Tunnel-Medium-Type esté configurado en 802 (valor 6) y Tunnel-Private-Group-Id coincida con el ID de VLAN configurado en el switch o controlador.
Los dispositivos BYOD que fallan en EAP-TLS usualmente indican que el certificado de cliente no se implementó correctamente. Para dispositivos administrados por Intune, verifique el almacén de certificados del dispositivo en el centro de administración de Intune. Para Chromebooks administrados por Google, verifique que el perfil de certificado esté asignado a la Unidad Organizativa correcta y que el dispositivo se haya sincronizado recientemente.
ROI e impacto empresarial
Migrar a Cloud RADIUS ofrece ahorros operativos medibles. El RADIUS local requiere como mínimo dos servidores para alta disponibilidad, parches continuos del sistema operativo, gestión de certificados y tiempo de ingeniería especializada. El tiempo que un solo ingeniero dedica al mantenimiento de RADIUS durante un año normalmente supera el costo anual de una suscripción a Cloud RADIUS.
El caso de negocio va más allá de la reducción de costos. Al vincular el acceso a la red con identidades en la nube verificadas, usted obtiene:
Bajas inmediatas. Deshabilitar a un usuario en Entra ID o Google Workspace revoca inmediatamente su acceso a la red en todos los sitios. No hay demoras, procesos manuales ni riesgo de que un excolaborador conserve el acceso a la WiFi. Esto respalda directamente las obligaciones de GDPR en torno a los derechos de acceso a los datos.
Analíticas más completas. Las plataformas como WiFi Analytics de Purple proporcionan datos más completos sobre la utilización del espacio y los recorridos de los visitantes cuando el acceso a la red está vinculado a identidades autenticadas. Se pasa de direcciones MAC anónimas a usuarios identificados y autenticados, lo que transforma la calidad de la información disponible para los equipos de operaciones y marketing.
Evidencia de cumplimiento. La autenticación EAP-TLS genera registros de acceso detallados: quién se conectó, desde qué dispositivo, en qué ubicación y a qué hora. Esta pista de auditoría respalda el Requisito 10 de PCI DSS (registro y monitoreo) y las obligaciones de rendición de cuentas de GDPR.
Consistencia multisitio. Un único servicio de Cloud RADIUS autentica todos sus sitios con políticas consistentes, administradas desde un solo panel. Agregar un nuevo hotel, tienda o recinto significa agregar sus puntos de acceso a la configuración de RADIUS, no enviar y configurar otro servidor. Para las organizaciones que administran grandes propiedades, esto representa una ventaja operativa significativa.
Para los operadores de Transport y recintos de Healthcare donde el tiempo de actividad de la red es críticamente operativo, los proveedores de Cloud RADIUS suelen ofrecer SLA de tiempo de actividad del 99.999% con conmutación por error multirregión integrada. Purple opera con un 99.999% de tiempo de actividad en más de 80,000 recintos activos, con 440 millones de inicios de sesión procesados en 2024 (datos internos de Purple, 2024).
For further reading on related topics, see WAN Computer Definition: A Practical Guide for 2026 and World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide .
Definiciones clave
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red definido en RFC 2865 que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan a un servicio de red. El servidor RADIUS actúa como el motor de decisiones entre sus puntos de acceso y su directorio de identidad.
Cada red WiFi empresarial WPA2-Enterprise o WPA3-Enterprise depende de un servidor RADIUS. Sin él, la autenticación IEEE 802.1X no funciona.
RADIUS as a Service (RADIUSaaS)
Una implementación de RADIUS alojada en la nube que se entrega como un servicio gestionado. El proveedor mantiene la infraestructura, el parcheo, la alta disponibilidad y las integraciones con proveedores de identidad. Usted configura las políticas de autenticación y apunta sus puntos de acceso a las direcciones IP de RADIUS en la nube.
RADIUSaaS elimina la necesidad de servidores NPS o FreeRADIUS locales, suprimiendo el hardware asociado, el parcheo del sistema operativo y los costos de mantenimiento especializado.
IEEE 802.1X
Un estándar IEEE para el Control de Acceso a Red basado en puertos. Define el modelo de autenticación de tres partes: el suplicante (dispositivo cliente), el autenticador (punto de acceso o switch) y el servidor de autenticación (servidor RADIUS). El autenticador bloquea todo el tráfico hasta que el servidor RADIUS otorga el acceso.
El estándar fundamental para la autenticación WiFi empresarial. Tanto WPA2-Enterprise como WPA3-Enterprise dependen de 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un método de autenticación definido en RFC 5216 que utiliza certificados digitales tanto en el servidor RADIUS como en el dispositivo cliente para una autenticación mutua. Ninguna de las partes envía una contraseña. El cliente presenta su certificado; el servidor lo valida contra el directorio en tiempo real.
El estándar de oro para la seguridad WiFi empresarial. Elimina el robo de credenciales, el phishing y los costos de soporte técnico relacionados con contraseñas. Requerido para el cumplimiento de PCI DSS en redes de datos de titulares de tarjetas.
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
Un método de autenticación que crea un túnel TLS cifrado y luego envía el nombre de usuario y la contraseña del usuario a través de él. Es vulnerable a ataques de tipo "Evil Twin" si el cliente no valida estrictamente el certificado del servidor RADIUS.
El valor predeterminado heredado para WiFi empresarial. Sigue estando ampliamente implementado, pero debe migrarse a EAP-TLS en todas las implementaciones nuevas y existentes siempre que sea posible.
Microsoft Entra ID
El servicio de gestión de accesos e identidad basado en la nube de Microsoft, anteriormente conocido como Azure Active Directory (Azure AD). Gestiona identidades de usuario, membresías de grupos, cumplimiento de dispositivos y políticas de Acceso Condicional.
La fuente de identidad principal para Cloud RADIUS en entornos centrados en Microsoft. Los proveedores de Cloud RADIUS se conectan a Entra ID a través de la API de Microsoft Graph.
Google Secure LDAP
Un servicio gestionado disponible en las ediciones Cloud Identity Premium y Google Workspace Enterprise que proporciona una interfaz LDAP tradicional para el directorio en la nube de Google. Los servidores RADIUS se conectan a ldap.google.com en el puerto 636 utilizando certificados de cliente.
La ruta de integración principal para conectar un servidor Cloud RADIUS a Google Workspace. Google no ofrece un servicio RADIUS nativo, por lo que Secure LDAP actúa como puente.
PKI (Public Key Infrastructure)
El conjunto de roles, políticas, hardware, software y procedimientos necesarios para crear, gestionar, distribuir, utilizar, almacenar y revocar certificados digitales. Se requiere una PKI para emitir los certificados de cliente y servidor utilizados en la autenticación EAP-TLS.
Las opciones de PKI nativas de la nube de los proveedores de RADIUS o de Microsoft (Cloud PKI) eliminan la necesidad de Active Directory Certificate Services (ADCS) locales.
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo que permite a los dispositivos solicitar y recibir certificados digitales de una Autoridad de Certificación de forma automática. Utilizado por Microsoft Intune y Google Admin Console para implementar certificados de cliente en dispositivos gestionados sin interacción del usuario.
Los perfiles SCEP en Intune son el mecanismo mediante el cual los dispositivos corporativos reciben de forma silenciosa los certificados de cliente necesarios para la autenticación EAP-TLS.
Dynamic VLAN assignment
Una función de RADIUS que devuelve atributos de asignación de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) al punto de acceso según la membresía de grupo de directorio del usuario autenticado. El punto de acceso coloca al cliente en la VLAN especificada de forma automática.
Permite una segmentación de red granular sin configuración manual de VLAN por dispositivo. El personal en diferentes roles o departamentos se ubica en diferentes segmentos de red, lo que limita el movimiento lateral y respalda los requisitos de segmentación de PCI DSS.
Ejemplos resueltos
Un hotel de 200 habitaciones está migrando la red de su personal administrativo de un servidor NPS local antiguo a una solución nativa de la nube. El hotel se ha trasladado recientemente a Microsoft Entra ID y Microsoft 365 E5. Los dispositivos del personal son laptops Windows administradas por Intune. La infraestructura inalámbrica es Cisco Meraki. El hotel necesita que el personal se conecte automáticamente sin solicitudes de contraseña y requiere la revocación instantánea cuando un miembro del personal deja la empresa.
Implemente una solución Cloud RADIUS con integración de Entra ID. Paso 1: otorgue al proveedor de Cloud RADIUS permisos de Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) en el inquilino de Entra ID. Paso 2: en Intune, cree un perfil de Certificado de confianza con la CA raíz de Cloud RADIUS y despliéguelo en el grupo "Todos los dispositivos corporativos". Paso 3: cree un perfil de Certificado SCEP con el nombre de sujeto CN={{UserPrincipalName}} y despliéguelo en el mismo grupo. Paso 4: configure la política de autenticación de Cloud RADIUS: permita el acceso si el certificado es emitido por [CA de confianza] Y el usuario es miembro del grupo de Entra ID [Hotel-Staff-WiFi] Y el dispositivo cumple con Intune. Paso 5: en el panel de Cisco Meraki, agregue las direcciones IP primaria y secundaria de Cloud RADIUS como servidores RADIUS en el SSID administrativo. Establezca el tiempo de espera de RADIUS en 5 segundos. Paso 6: en Intune, cree un perfil de WiFi WPA3-Enterprise para el SSID administrativo, especificando EAP-TLS y vinculando el perfil de certificado SCEP. Despliéguelo en el grupo "Todos los dispositivos corporativos". Los dispositivos reciben de forma silenciosa el certificado y el perfil de WiFi en la siguiente sincronización de Intune y se conectan automáticamente. Cuando un miembro del personal se va, deshabilitar su cuenta de Entra ID revoca inmediatamente el acceso a la red en todos los sitios.
Una cadena de tiendas minoristas con 50 sucursales utiliza Google Workspace y gestiona una flota de 500 Chromebooks utilizados por los asociados de las tiendas para operaciones de inventario y punto de venta. Actualmente utilizan una clave WPA2 PSK compartida para la red de operaciones de la tienda, lo que genera un riesgo de seguridad cuando se pierden o roban dispositivos. Quieren migrar a la autenticación 802.1X sin implementar servidores locales en cada tienda. Su infraestructura inalámbrica es HPE Aruba.
Implemente una solución Cloud RADIUS con integración de Google Workspace a través de Google Secure LDAP. Paso 1: en la consola de administración de Google, vaya a Aplicaciones, luego a LDAP y agregue un nuevo cliente LDAP para el servicio Cloud RADIUS. Configure los permisos de lectura para la información del usuario y la membresía del grupo. Descargue el certificado de cliente y la clave generados. Paso 2: configure el servicio Cloud RADIUS con las credenciales de Google Secure LDAP. Paso 3: configure una PKI en la nube para emitir certificados a las Chromebooks. En la consola de administración de Google, vaya a Dispositivos, luego a Redes, luego a Certificados y cargue la CA raíz. Configure el perfil de emisión de certificados y aplíquelo a la unidad organizativa Store-Associates. Paso 4: en la consola de administración de Google, cree un perfil de WiFi WPA3-Enterprise para el SSID de operaciones de la tienda. Configure EAP-TLS, vincule la CA raíz y aplíquelo a la unidad organizativa Store-Associates. Las Chromebooks reciben el certificado y el perfil de WiFi en la siguiente sincronización de la consola de administración. Paso 5: en HPE Aruba Central, configure el SSID de operaciones de la tienda con WPA3-Enterprise y agregue las direcciones IP primaria y secundaria de Cloud RADIUS. Establezca el tiempo de espera de RADIUS en 5 segundos. Configure la asignación dinámica de VLAN para colocar a los asociados de la tienda en la VLAN 20 (operaciones de la tienda) según su membresía de grupo de Google Workspace. Cuando se pierde o roba una Chromebook, eliminarla de la unidad organizativa Store-Associates revoca inmediatamente su acceso a la red.
Preguntas de práctica
Q1. Su organización está migrando de Active Directory local a Microsoft Entra ID. Actualmente utiliza PEAP-MSCHAPv2 para la autenticación de WiFi en 300 laptops corporativas administradas por Intune. Cuenta con licenciamiento Microsoft 365 E5. ¿Cuál es la ruta más segura y operativamente eficiente para migrar la autenticación de WiFi a una arquitectura nativa de la nube?
Sugerencia: Considere las vulnerabilidades de la autenticación basada en credenciales, las capacidades de Microsoft Intune para el despliegue de certificados y la necesidad de evitar dependencias de infraestructura local.
Ver respuesta modelo
Despliegue una solución Cloud RADIUS con integración de Entra ID. Utilice Microsoft Intune para desplegar un perfil de Certificado de Confianza (Root CA) y un perfil de Certificado SCEP en las 300 laptops. Configure la política de autenticación de Cloud RADIUS para requerir un certificado válido de la CA de confianza y la pertenencia al grupo de Entra ID "Corporate-WiFi-Users". Cree un perfil de WiFi WPA3-Enterprise en Intune especificando EAP-TLS y vincule el perfil de certificado SCEP. Los dispositivos recibirán de forma silenciosa el certificado y la configuración de WiFi en la siguiente sincronización de Intune. Esto elimina el riesgo de robo de credenciales de PEAP-MSCHAPv2, elimina la dependencia de NPS local y proporciona una revocación instantánea cuando se deshabilita una cuenta de Entra ID.
Q2. Un usuario de su hotel reporta que no puede conectarse a la WiFi del personal administrativo tras regresar de unas vacaciones de dos semanas. Otros miembros del personal se conectan sin problemas. La red utiliza EAP-TLS con certificados desplegados a través de Intune. ¿Cuáles son las tres causas más probables, en orden de probabilidad?
Sugerencia: EAP-TLS depende de activos criptográficos sensibles al tiempo y de búsquedas de directorio en tiempo real.
Ver respuesta modelo
- El certificado de cliente del usuario ha expirado. Los certificados tienen un periodo de validez definido y, si el dispositivo estuvo desconectado durante la ventana de renovación, es posible que el perfil SCEP no lo haya renovado. Verifique la fecha de vencimiento del certificado en el almacén de certificados del dispositivo en Intune. 2. El reloj del sistema del dispositivo está significativamente desincronizado (desviación de reloj), lo que provoca que falle la validación del certificado. EAP-TLS valida las marcas de tiempo del certificado; un reloj con más de cinco minutos de desincronización provocará fallas de autenticación. 3. La cuenta de Entra ID del usuario fue colocada en un grupo diferente durante su ausencia (por ejemplo, movida de personal activo a una OU diferente) y la política de autenticación RADIUS ya no coincide con su pertenencia al grupo. Verifique las pertenencias a grupos del usuario en Entra ID contra la política de RADIUS.
Q3. Usted es el gerente de TI de una cadena minorista con 80 tiendas. Utiliza Google Workspace y administra 400 Chromebooks a través de Google Admin Console. Desea reemplazar la clave WPA2 PSK compartida actual en la red de operaciones de las tiendas con autenticación 802.1X. No tiene servidores locales en ninguna de las tiendas. ¿Qué arquitectura despliega y cuál es el principal beneficio de seguridad sobre el enfoque PSK actual?
Sugerencia: Considere qué sucede cuando se pierde o roban una Chromebook bajo cada modelo de autenticación.
Ver respuesta modelo
Despliegue un servicio Cloud RADIUS con integración de Google Secure LDAP. Configure una PKI en la nube para emitir certificados a las Chromebooks. En Google Admin Console, despliegue la Root CA y un perfil de certificado de cliente SCEP en la Unidad Organizativa "Store-Associates". Cree un perfil de WiFi WPA3-Enterprise especificando EAP-TLS y despliéguelo en la misma OU. Configure los puntos de acceso HPE Aruba (o equivalente) en cada tienda para que apunten al servicio Cloud RADIUS. El principal beneficio de seguridad: bajo la PSK compartida actual, una Chromebook perdida o robada conserva el acceso a la WiFi hasta que se rota la PSK en las 80 tiendas, un proceso disruptivo y que consume mucho tiempo. Con EAP-TLS, eliminar el dispositivo de la OU "Store-Associates" en Google Admin Console revoca inmediatamente su certificado y acceso a la red, sin afectar a ningún otro dispositivo.
Q4. Durante un despliegue de Cloud RADIUS, configura el SSID en los puntos de acceso Cisco Meraki y despliega el perfil de WiFi de Intune a un grupo piloto de 20 dispositivos. Ninguno de los dispositivos puede conectarse. El estado del dispositivo en Intune muestra que el certificado y el perfil de WiFi se desplegaron correctamente. ¿Qué es lo primero que debe verificar?
Sugerencia: La causa más común de falla en el despliegue inicial no es un error de configuración en la política de RADIUS o en el certificado.
Ver respuesta modelo
Verifique que los puertos UDP 1812 y 1813 estén abiertos para tráfico de salida desde los puntos de acceso Cisco Meraki (o la infraestructura de nube de Meraki) hacia las direcciones IP del servidor Cloud RADIUS. Los puertos de firewall bloqueados son la causa principal de fallas en el despliegue inicial. El hecho de que los certificados y los perfiles de WiFi se hayan desplegado correctamente descarta problemas de configuración de Intune. Las siguientes verificaciones son: discrepancia en el secreto compartido de RADIUS entre Meraki y el servicio Cloud RADIUS; tiempo de espera (timeout) de RADIUS configurado demasiado bajo (increméntelo a al menos 5 segundos); y si las IPs del servidor Cloud RADIUS están ingresadas correctamente en la configuración del SSID de Meraki.
Continúe leyendo esta serie
Los beneficios de seguridad de RADIUS as a Service para fuerzas de trabajo híbridas
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 instalaciones 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 gerentes de TI y arquitectos de red en hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona la evidencia necesaria para evaluar y actuar en una migración a RADIUS en la nube este trimestre.
Cómo implementar la autenticación 802.1X con Cloud RADIUS
Esta guía de referencia técnica proporciona un marco integral para implementar la autenticación 802.1X con Cloud RADIUS en entornos empresariales distribuidos. Detalla la arquitectura, la selección del método EAP, la secuencia de implementación y las estrategias de mitigación de riesgos necesarias para proteger el acceso a la red, eliminando al mismo tiempo la carga operativa de la infraestructura local.
¿Qué es Cloud RADIUS? Una guía completa de RADIUS como servicio
Esta guía completa explora Cloud RADIUS (RADIUS como servicio), detallando su arquitectura, métodos EAP y estrategias de implementación. Proporciona a los líderes de TI información práctica sobre la migración de servidores locales a un modelo de autenticación basado en la nube que es escalable, seguro y cumple con las normativas.