Integración de RADIUS as a Service con directorios en la nube (Azure AD y Google Workspace)
Esta guía de referencia técnica detalla cómo integrar RADIUS as a Service con directorios en la nube (Microsoft Entra ID y Google Workspace) para la autenticación WiFi empresarial. Cubre la transición arquitectónica de NPS local a RADIUS nativo de la nube, el despliegue de la autenticación EAP-TLS basada en certificados y las mejores prácticas operativas para proteger el acceso inalámbrico en entornos de hostelería, comercio minorista y sector público. Para los responsables de TI y arquitectos de redes que ya han invertido en identidad en la nube, esta guía cierra la brecha entre la gestión de directorios y la seguridad de la red física.
Escuchar esta guía
Ver transcripción del podcast
Resumen ejecutivo
Para las empresas modernas que han invertido 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 WiFi dependía de Active Directory Domain Services local 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 as a Service (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 fallo. 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 todos los sitios.
Esta guía cubre la decisión arquitectónica entre NPS local y RADIUS nativo de la nube, el despliegue 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 recintos 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 e IEEE 802.1X
La base de una red WiFi empresarial segura 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 contra un servicio de directorio y devuelve un mensaje Access-Accept o Access-Reject. Solo entonces el AP concede el 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 se realiza completamente en la nube. Esto se alinea con los principios de acceso a la red zero-trust y reduce significativamente los costes indirectos operativos.
La siguiente tabla compara los dos enfoques arquitectónicos principales:
| Dimensión | Híbrido local (NPS) | Nativo de la nube (RADIUSaaS) |
|---|---|---|
| Infraestructura | Requiere VM de Windows Server o hardware dedicado | Sin servidores locales |
| Fuente 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 equilibrio de carga | Escalado automático por el proveedor |
| Tiempo de configuración | De 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 costes indirectos operativos |
EAP-TLS frente a PEAP-MSCHAPv2: la elección crítica
La elección del método EAP es la decisión de seguridad individual más importante en este despliegue. PEAP-MSCHAPv2 depende de que los usuarios introduzcan sus credenciales de dominio. Esto es vulnerable al robo de credenciales y a los ataques de intermediario (man-in-the-middle). Si un dispositivo cliente no valida estrictamente el certificado del servidor RADIUS (y muchos no lo hacen por defecto), 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 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 criptográficamente. No hay contraseñas que escribir ni robar. 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. Esta es la ruta recomendada para todos los nuevos despliegues y es esencial para el cumplimiento de PCI DSS v4.0 (Requisito 8.3 sobre autenticación sólida) y las obligaciones de protección de datos de GDPR.
Google Workspace: la diferencia arquitectónica
Microsoft Entra ID y Google Workspace diferen en un aspecto importante para la integración con 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 a 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 generados para usted. A partir de ese momento, el servidor RADIUS consulta el directorio de Google para validar las credenciales o la pertenencia a grupos, del mismo modo que consultaría un Active Directory local.
Una vía alternativa utiliza la integración basada en SAML, donde el proveedor de Cloud RADIUS se registra como una aplicación SAML en Google Admin Console y realiza una búsqueda OAuth en el momento de la autenticación para verificar la identidad del usuario y su pertenencia a grupos 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 gestión de identidades y dispositivos
Para Microsoft Entra ID: verifique que su inquilino disponga de licencias Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Esto incluye Microsoft Intune y Acceso condicional. 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 tiene previsto utilizar EAP-TLS en Chromebooks gestionados, asegúrese de que Google Admin Console esté configurado para gestionar los certificados de los 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 de 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 (Trusted Certificate). Cargue el certificado de la CA raíz y despliéguelo en los grupos de dispositivos de destino. Esto garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el protocolo de enlace TLS. A continuación, cree un perfil de Certificado SCEP. Para la autenticación basada en el usuario, establezca el Nombre del sujeto (Subject Name) en CN={{UserPrincipalName}}. Para la autenticación basada en el dispositivo, utilice CN={{DeviceName}}. Configure el Nombre alternativo del sujeto (Subject Alternative Name) para que incluya el Nombre principal del usuario (User Principal Name) o el ID del dispositivo.
Ruta de Google Admin Console: vaya a Dispositivos, luego a Redes y, a continuación, 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
Conceda a su proveedor de Cloud RADIUS los permisos de API necesarios en su 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 conformidad de los dispositivos. Para Google Workspace a través de Secure LDAP, descargue el certificado de cliente y la clave de Google Admin Console e instálelos en el servicio RADIUS.
Defina sus políticas de autenticación dentro del portal de gestió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 [Usuarios-WiFi-Corporativos] Y el dispositivo está marcado como Conforme en Intune". Esto aplica simultáneamente la identidad, la pertenencia a grupos y el estado del dispositivo.
Fase 4: configurar la infraestructura inalámbrica
En su controlador de LAN inalámbrica o panel de gestión en la nube (Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet), añada las direcciones IP del servidor Cloud RADIUS y los secretos compartidos como servidores de autenticación RADIUS. Configure servidores primarios y secundarios para redundancia. Establezca el tiempo de espera (timeout) de RADIUS en un mínimo de cinco segundos para adaptarse a la latencia de ida y vuelta de la nube.
Cree un nuevo SSID configurado para WPA2-Enterprise o WPA3-Enterprise. Para implementaciones en el sector de Hostelería , asegúrese de que el SSID corporativo esté en una VLAN separada de cualquier red de WiFi para invitados . Para entornos de Retail , considere implementar el SSID corporativo únicamente en las zonas internas o de personal.
Fase 5: implementar el perfil de WiFi a través de MDM
Microsoft Intune: cree un perfil de configuración de WiFi. Establezca el SSID para que coincida exactamente con la configuración de su infraestructura. Seleccione WPA2-Enterprise o WPA3-Enterprise. En la configuración de EAP, seleccione EAP-TLS. Vincule el perfil de certificado SCEP como certificado de cliente y especifique el perfil de CA raíz de confianza. Asigne 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: vaya a Dispositivos, luego a Redes y, a continuación, a Wi-Fi. Cree un nuevo perfil de red WiFi. Establezca el SSID, seleccione WPA3-Enterprise, elija EAP-TLS y envíe el certificado de CA raíz de confianza a los dispositivos. Aplique este perfil a sus unidades organizativas. Los Chromebooks se conectan de forma silenciosa y segura.
Buenas prácticas
Exija EAP-TLS en todas las nuevas implementaciones. No despliegue nuevas redes 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.
Aplique 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 lo deje en blanco. Esta única decisión de configuración marca 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 asignarlos dinámicamente a diferentes VLAN. El servidor RADIUS devuelve el Tunnel-Private-Group-Id al punto de acceso, lo que ubica al cliente en la VLAN correcta. Esto limita el movimiento lateral en caso de una vulneración 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 los dispositivos gestionados por la empresa. Utilice un Captive Portal con SSO para los dispositivos BYOD y de invitados. Intentar configurar manualmente EAP-TLS en dispositivos no gestionados genera una sobrecarga de soporte excesiva. La plataforma 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.
Supervise la expiración de los certificados de forma proactiva. Configure la supervisión y las alertas a los 90, 30 y 7 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 allí donde su PKI lo admita.
Pruebe los ajustes de tiempo de espera (timeout) de RADIUS. Cloud RADIUS introduce una latencia de red de ida y vuelta que el NPS local (on-premise) no genera. Establezca el tiempo de espera de RADIUS en sus puntos de acceso en al menos de cinco segundos. Un tiempo de espera de dos segundos (habitual en las configuraciones predeterminadas) provocará fallos de autenticación intermitentes.
Resolución de problemas y mitigación de riesgos
Los puertos de firewall bloqueados son la causa principal de los fallos en el despliegue inicial. La autenticación RADIUS requiere el puerto UDP 1812 de salida desde su infraestructura inalámbrica hacia el servicio Cloud RADIUS. El registro de conexiones (accounting) de RADIUS requiere el puerto UDP 1813. Verifique que estén abiertos antes de realizar cualquier otra acción de resolución de problemas.
Los fallos de validación de certificados se presentan como rechazos de autenticación sin una causa obvia. Compruebe lo siguiente en este orden: la expiración del certificado tanto en el cliente como en el servidor RADIUS; el desfase horario (clock skew) entre el dispositivo cliente y el servidor RADIUS (EAP-TLS depende de una sincronización horaria precisa); y si el certificado de la CA raíz se ha desplegado 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 el principal de servicio tiene GroupMember.Read.All. En Google Workspace, confirme que el cliente de LDAP seguro tiene permiso para leer la información del grupo.
El fallo en la asignación de VLAN suele indicar una discrepancia entre los valores de los atributos de RADIUS y los ID de VLAN configurados en la infraestructura inalámbrica. Confirme que Tunnel-Type está establecido en VLAN (valor 13), Tunnel-Medium-Type en 802 (valor 6) y Tunnel-Private-Group-Id coincide con el ID de VLAN configurado en el switch o controlador.
El fallo de los dispositivos BYOD con EAP-TLS suele indicar que el certificado de cliente no se ha desplegado correctamente. Para dispositivos gestionados por Intune, compruebe el almacén de certificados del dispositivo en el centro de administración de Intune. Para Chromebooks gestionados 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
La migración a Cloud RADIUS ofrece un ahorro operativo medible. 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 a lo largo de un año suele superar el coste anual de una suscripción a Cloud RADIUS.
El caso de negocio va más allá de la reducción de costes. Al vincular el acceso a la red con identidades en la nube verificadas, obtiene:
Bajas instantáneas. Deshabilitar a un usuario en Entra ID o Google Workspace revoca inmediatamente su acceso a la red en todas las sedes. No hay retrasos, ni procesos manuales, ni riesgo de que un antiguo empleado 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.
Pruebas 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 supervisión) y las obligaciones de responsabilidad proactiva de GDPR.
Consistencia multisitio. Un único servicio Cloud RADIUS autentica todas sus sedes con políticas consistentes, gestionadas desde un solo panel de control. Añadir un nuevo hotel, tienda o establecimiento significa añadir sus puntos de acceso a la configuración de RADIUS, no enviar y configurar otro servidor. Para las organizaciones que gestionan grandes patrimonios inmobiliarios, esto representa una ventaja operativa significativa.
Para los operadores de Transporte y los centros de Sanidad donde el tiempo de actividad de la red es operativamente crítico, 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 tiempo de actividad del 99,999 % en más de 80 000 establecimientos activos, con 440 millones de inicios de sesión procesados en 2024 (datos internos de Purple, 2024).
Para seguir leyendo sobre temas relacionados, consulte Definición de ordenador WAN: una guía práctica para 2026 y Día Mundial de la WiFi 2026: cómo su establecimiento puede ayudar a reducir la brecha digital .
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 identidades.
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 ofrece como un servicio gestionado. El proveedor mantiene la infraestructura, los parches, 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 IP de Cloud RADIUS.
RADIUSaaS elimina la necesidad de servidores NPS o FreeRADIUS locales, suprimiendo los costes indirectos asociados de hardware, parches de sistema operativo y mantenimiento especializado.
IEEE 802.1X
Un estándar IEEE para el control de acceso a la red basado en puertos. Define el modelo de autenticación de tres partes: el suplicante (dispositivo cliente), el autenticador (punto de acceso o conmutador) y el servidor de autenticación (servidor RADIUS). El autenticador bloquea todo el tráfico hasta que el servidor RADIUS concede 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 la 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 costes indirectos de soporte técnico relacionados con las 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 desplegado, pero debe migrarse a EAP-TLS en todos los despliegues nuevos y existentes siempre que sea posible.
Microsoft Entra ID
El servicio de gestión de accesos e identidades basado en la nube de Microsoft, anteriormente conocido como Azure Active Directory (Azure AD). Gestiona identidades de usuario, pertenencias a 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 al 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 funciones, 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 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 desplegar 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 pertenencia al grupo de directorio del usuario autenticado. El AP coloca al cliente en la VLAN especificada automáticamente.
Permite una segmentación de red granular sin configuración manual de VLAN por dispositivo. El personal con diferentes funciones o departamentos accede a diferentes segmentos de red, lo que limita el movimiento lateral y respalda los requisitos de segmentación de PCI DSS.
Ejemplos prácticos
Un hotel de 200 habitaciones está migrando la red de su personal interno 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 portátiles Windows gestionados 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.
Despliegue una solución Cloud RADIUS con integración de Entra ID. Paso 1: conceda al proveedor de Cloud RADIUS permisos de la API de Microsoft Graph (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 'All Corporate Devices'. 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 está emitido por [Trusted CA] 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, añada las IP primaria y secundaria de Cloud RADIUS como servidores RADIUS en el SSID del personal interno. Establezca el tiempo de espera de RADIUS en 5 segundos. Paso 6: en Intune, cree un perfil de WiFi WPA3-Enterprise para el SSID del personal interno, especificando EAP-TLS y vinculando el perfil de certificado SCEP. Despliéguelo en el grupo 'All Corporate Devices'. 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 marcha, al desactivar su cuenta de Entra ID se revoca inmediatamente el acceso a la red en todos los sitios.
Una cadena de tiendas con 50 establecimientos utiliza Google Workspace y gestiona una flota de 500 Chromebooks utilizados por los empleados 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 desplegar servidores locales en cada tienda. Su infraestructura inalámbrica es HPE Aruba.
Despliegue una solución Cloud RADIUS con integración de Google Workspace a través de Google Secure LDAP. Paso 1: en Google Admin Console, navegue a Aplicaciones, luego a LDAP y añada un nuevo cliente LDAP para el servicio Cloud RADIUS. Configure los permisos de lectura para la información del usuario y la pertenencia a grupos. 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 los Chromebooks. En Google Admin Console, navegue 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 Google Admin Console, 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 OU Store-Associates. Los Chromebooks reciben el certificado y el perfil de WiFi en la siguiente sincronización de Admin Console. Paso 5: en HPE Aruba Central, configure el SSID de operaciones de la tienda con WPA3-Enterprise y añada las 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 ubicar a los empleados de la tienda en la VLAN 20 (operaciones de la tienda) según su pertenencia a grupos de Google Workspace. Cuando un Chromebook se pierde o se roba, al eliminarlo de la OU Store-Associates se 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 WiFi en 300 portátiles corporativos gestionados por Intune. Dispone de licencias Microsoft 365 E5. ¿Cuál es la ruta más segura y operativamente eficiente para migrar la autenticación 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 (CA raíz) y un perfil de Certificado SCEP en los 300 portátiles. 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 reciben 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, suprime la dependencia de NPS local y proporciona una revocación instantánea cuando se desactiva una cuenta de Entra ID.
Q2. Un usuario de su hotel informa de que no puede conectarse a la WiFi del personal interno tras regresar de unas vacaciones de dos semanas. El resto del personal se conecta sin problemas. La red utiliza EAP-TLS con certificados desplegados a través de Intune. ¿Cuáles son las tres causas más probables, por orden de probabilidad?
Sugerencia: EAP-TLS se basa en activos criptográficos sensibles al tiempo y consultas de directorio en tiempo real.
Ver respuesta modelo
- El certificado de cliente del usuario ha caducado. Los certificados tienen un período 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. Compruebe la fecha de caducidad del certificado en el almacén de certificados de dispositivos de Intune. 2. El reloj del sistema del dispositivo está significativamente desincronizado (desviación del reloj), lo que provoca que falle la validación del certificado. EAP-TLS valida las marcas de tiempo de los certificados; un reloj desincronizado por más de cinco minutos provocará fallos de autenticación. 3. La cuenta de Entra ID del usuario se asignó a un grupo diferente durante su ausencia (por ejemplo, se trasladó de personal activo a una OU diferente) y la política de autenticación RADIUS ya no coincide con su pertenencia al grupo. Compruebe las pertenencias a grupos del usuario en Entra ID con respecto a la política de RADIUS.
Q3. Usted es el responsable de TI de una cadena de tiendas con 80 establecimientos. Utiliza Google Workspace y gestiona 400 Chromebooks a través de Google Admin Console. Desea reemplazar la PSK WPA2 compartida actual en la red de operaciones de la tienda con autenticación 802.1X. No tiene servidores locales en ninguna ubicación de tienda. ¿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 roba un 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 los Chromebooks. En Google Admin Console, despliegue la CA raíz 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, un Chromebook perdido o robado conserva el acceso WiFi hasta que se rote la PSK en las 80 tiendas, un proceso disruptivo y que requiere 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 en 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 han desplegado correctamente. ¿Qué es lo primero que comprueba?
Sugerencia: La causa más común del fallo del despliegue inicial no es un error de configuración en la política de RADIUS o en el certificado.
Ver respuesta modelo
Compruebe que los puertos UDP 1812 y 1813 estén abiertos de salida desde los puntos de acceso Cisco Meraki (o la infraestructura en la nube de Meraki) hacia las direcciones IP del servidor Cloud RADIUS. Los puertos de cortafuegos bloqueados son la causa principal del fallo del despliegue inicial. El hecho de que los certificados y los perfiles de WiFi se despli queen correctamente descarta problemas de configuración de Intune. Las siguientes comprobaciones son: discrepancia en el secreto compartido de RADIUS entre Meraki y el servicio Cloud RADIUS; tiempo de espera de RADIUS configurado demasiado bajo (auméntelo a al menos 5 segundos); y si las IP del servidor Cloud RADIUS se han introducido correctamente en la configuración del SSID de Meraki.
Continúe leyendo esta serie
The Security Benefits of RADIUS as a Service for Hybrid Workforces
Esta guía de referencia técnica explica cómo RADIUS as a Service protege el acceso a la red para plantillas híbridas en sedes distribuidas. Cubre la arquitectura, los beneficios de seguridad y los pasos de implementación para reemplazar la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Para los responsables de TI y arquitectos de red de hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona las pruebas necesarias para evaluar y llevar a cabo una migración a RADIUS en la nube este trimestre.
How to Implement 802.1X Authentication with 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 asegurar el acceso a la red, eliminando al mismo tiempo la sobrecarga operativa de la infraestructura local.
What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service
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 escalable, seguro y conforme.