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 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 física de la red.
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad WiFi empresarial →
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 los Servicios de dominio de Active Directory 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 un inconveniente: costosa de mantener, difícil de escalar e incompatible con los modelos de seguridad de confianza cero.
RADIUS-as-a-Service 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 puntos únicos 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 cada ubicación.
Esta guía abarca 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, establecimientos comerciales, estadios y recintos del sector público. Para obtener una introducción más amplia al control de acceso a la red, consulte A Guide to Your Network Access Control System.
Análisis técnico detallado: 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 o WPA3 empresarial, 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 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 de Cloud RADIUS de terceros se integra directamente con Microsoft Entra ID a través de la Microsoft Graph API, 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 de confianza cero y reduce significativamente los costes 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 físico | 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 equilibrio 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 costes 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 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 de forma predeterminada - un atacante puede desplegar un punto de acceso no autorizado con su SSID, interceptar el saludo EAP y capturar las credenciales. Esto 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 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 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 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 Microsoft Graph API. Google, sin embargo, no ofrece un servicio RADIUS nativo. Siempre necesitará 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 los certificados de cliente que Google genera para usted. A partir de ese momento, el servidor RADIUS consulta el directorio de Google para validar las credenciales o la pertenencia a grupos, de la misma manera que consultaría 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 consola de administración de Google y realiza una búsqueda OAuth en el momento de la autenticación para verificar la identidad del usuario y sus pertenencias a grupos en tiempo real.
-
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Guía de implementación
La implementación de RADIUS-as-a-Service con EAP-TLS requiere la coordinación de la identidad, la gestión de dispositivos y la infraestructura de red. El siguiente enfoque de cinco fases se aplica tanto a los 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 inquilino tenga licencias de 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 la consola de administración de Google está configurada 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 Intune Suite) o una implementación 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. Suba el certificado de la CA raíz y despliéguelo en sus grupos de dispositivos de destino. Esto garantiza que los dispositivos de 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 como CN={{UserPrincipalName}}. Para la autenticación basada en el dispositivo, utilice CN={{DeviceName}}. Configure el nombre alternativo del sujeto para incluir el nombre principal del usuario o el ID del dispositivo.
Ruta de la consola de administración de Google: navegue a Dispositivos, luego a Redes y después a Certificados. Suba su CA raíz. Configure un mecanismo de emisión de certificados, ya sea una PKI en la nube que admita la integración SCEP con Google Workspace, o el Google Cloud Certificate Connector que actúa como proxy para las solicitudes a una entidad de certificación local de Microsoft. 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
Otorgue a su proveedor de Cloud RADIUS los permisos de API necesarios en su inquilino de directorio. Para Microsoft 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 desde la 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 está emitido por [CA de confianza] Y el usuario es miembro del grupo [Corporate-WiFi-Users] Y el dispositivo está marcado como conforme en Intune". Esto aplica la identidad, la pertenencia al grupo y el estado del dispositivo de forma simultánea.
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 Networks o Fortinet), añada las direcciones IP y los secretos compartidos del servidor Cloud RADIUS como servidores de autenticación RADIUS. Configure servidores primarios y secundarios para redundancia. Establezca 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.
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 independiente de cualquier red de Guest WiFi. Para entornos de Retail, considere la posibilidad de desplegar el SSID corporativo únicamente en las zonas internas de gestión.
Fase 5: desplegar 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 el 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: navegue a Dispositivos, luego a Redes y después a WiFi. Cree un nuevo perfil de red WiFi. Establezca el SSID, seleccione WPA3-Enterprise, elija EAP-TLS y envíe el certificado de la 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 todos los nuevos despliegues. 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.Exija una validación estricta del certificado del servidor. Si debe usar 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 la consola de administración de Google, hay un campo para especificar la CA de confianza para la validación del servidor. No deje este campo en blanco. Esta única decisión de configuración marca la diferencia entre un despliegue seguro y uno 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 asignarle dinámicamente diferentes VLAN. El servidor RADIUS devuelve el atributo Tunnel-Private-Group-Id al punto de acceso, que coloca al cliente en la VLAN correcta. Esto limita el movimiento lateral en caso de que la seguridad se vea comprometida y cumple con los requisitos de segmentación de red de PCI-DSS.
Separe la autenticación corporativa de la de invitados. Utilice EAP-TLS para dispositivos gestionados por la empresa. Utilice un Captive Portal con SSO para dispositivos BYOD y de invitados. Intentar configurar manualmente EAP-TLS en dispositivos no gestionados genera una sobrecarga de soporte excesiva. La plataforma de Guest WiFi de Purple gestiona la incorporación de invitados por separado, manteniendo una clara separación 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 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 allí donde su PKI lo admita.
Pruebe los ajustes de tiempo de espera de RADIUS. Cloud RADIUS introduce una latencia de ida y vuelta en la red que la solución local NPS no tiene. 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 por defecto - provocará fallos de autenticación intermitentes.
Resolución de problemas y mitigación de riesgos
Los puertos de firewall bloqueados son la causa principal del fallo 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. La contabilidad 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 por orden: la expiración del certificado tanto en el cliente como en el servidor RADIUS; el desajuste horario entre el dispositivo cliente y el servidor RADIUS (EAP-TLS depende de un mantenimiento preciso de la hora); 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 tiene los permisos de API correctos para leer las pertenencias a grupos. En Entra ID, confirme que la entidad 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.
La asignación de VLAN no funciona suele indicar 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á establecido en VLAN (valor 13), Tunnel-Medium-Type está establecido en 802 (valor 6) y Tunnel-Private-Group-Id coincide con el ID de VLAN configurado en el conmutador o controlador.
Los dispositivos BYOD fallan en 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 ha sincronizado recientemente.
-
ROI e impacto empresarial
La transición a Cloud RADIUS ofrece ahorros operativos medibles. 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 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 Microsoft 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 WiFi. Esto respalda directamente las obligaciones de la GDPR en materia de derechos de acceso a los datos.
Análisis más enriquecidos. Las plataformas como WiFi Analytics de Purple proporcionan datos más completos sobre la utilización del espacio y el recorrido 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 monitorización) y las obligaciones de rendición de cuentas de la GDPR.
Consistencia multi-sede. 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 recinto 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, esto supone una ventaja operativa significativa.
Para operadores de Transporte y 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 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).
Para más información sobre temas relacionados, consulte WAN Computer Definition: A Practical Guide for 2026 y 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 el 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 con WPA2-Enterprise o WPA3-Enterprise depende de un servidor RADIUS. Sin él, la autenticación 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 se encarga de la infraestructura, los parches, la alta disponibilidad y las integraciones con proveedores de identidad. Usted solo tiene que configurar las políticas de autenticación y apuntar sus puntos de acceso a las direcciones IP de RADIUS en la nube.
RADIUSaaS elimina la necesidad de servidores NPS o FreeRADIUS locales, suprimiendo los costes asociados de hardware, parches de sistema operativo y mantenimiento especializado.
IEEE 802.1X
Un estándar de la IEEE para el control de acceso a redes 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 concede el acceso.
El estándar fundamental para la autenticación WiFi empresarial. Tanto WPA2-Enterprise como WPA3-Enterprise se basan en 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un método de autenticación definido en el RFC 5216 que utiliza certificados digitales tanto en el servidor RADIUS como en el dispositivo cliente para realizar una autenticación mutua. Ninguna de las partes envía una contraseña. El cliente presenta su certificado y el servidor lo valida con el directorio en tiempo real.
El estándar de oro para la seguridad WiFi empresarial. Elimina el robo de credenciales, el phishing y las tareas de soporte técnico relacionadas con contraseñas. Requerido para el cumplimiento de PCI-DSS en redes con datos de titulares de tarjetas.
PEAP-MSCHAPv2 (PEAP protegido - Protocolo de autenticación por desafío mutuo de Microsoft 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.
La opción predeterminada heredada para redes WiFi corporativas. Sigue estando muy implementada, 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, 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 Microsoft Graph API.
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 (Infraestructura de clave pública)
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 proveedores RADIUS o Microsoft (Cloud PKI) eliminan la necesidad de servicios de certificados de Active Directory (ADCS) locales.
SCEP (Protocolo de inscripción de certificados simple)
Un protocolo que permite a los dispositivos solicitar y recibir certificados digitales de una entidad de certificación de forma automática. Utilizado por Microsoft Intune y Google Admin Console para implementar certificados de cliente en dispositivos gestionados sin la 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.
Asignación dinámica de VLAN
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 la configuración manual de VLAN por dispositivo. El personal de 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 del personal interno desde un antiguo servidor NPS local 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 una revocación instantánea cuando un empleado deja la empresa.
Despliegue una solución Cloud RADIUS con integración en Entra ID. Paso 1: conceda 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 "All Corporate Devices". Paso 3: cree un perfil de certificado SCEP con Subject Name 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 las directivas de Intune. Paso 5: en el panel de control de Cisco Meraki, añada las IP primaria y secundaria de Cloud RADIUS como servidores RADIUS en el SSID de 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 de 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 empleado deja la empresa, al desactivar su cuenta de Entra ID se revoca inmediatamente el acceso a la red en todas las sedes.
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 compartida WPA2 PSK para la red de operaciones de la tienda, lo que genera un riesgo de seguridad en caso de pérdida o robo de dispositivos. Desean 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 de RADIUS en la nube con integración de Google Workspace a través de Google Secure LDAP. Paso 1: en la consola de administración de Google, navegue a Aplicaciones, luego LDAP y añada un nuevo cliente LDAP para el servicio RADIUS en la nube. Configure los permisos de lectura para la información de usuario y la pertenencia a grupos. Descargue el certificado de cliente y la clave generados. Paso 2: configure el servicio RADIUS en la nube con las credenciales de Google Secure LDAP. Paso 3: configure una PKI en la nube para emitir certificados a los Chromebooks. En la consola de administración de Google, navegue a Dispositivos, luego Redes, después Certificados y cargue la CA raíz. Configure el perfil de emisión de certificados y aplíquelo a la unidad organizativa de asociados de tienda (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 tienda. Establezca EAP-TLS, vincule la CA raíz y aplíquelo a la unidad organizativa Store-Associates. Los Chromebooks recibirán 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 tienda con WPA3-Enterprise y añada las IP principal y secundaria del RADIUS en la nube. Establezca el tiempo de espera de RADIUS en 5 segundos. Configure la asignación dinámica de VLAN para ubicar a los asociados de tienda en la VLAN 20 (operaciones de tienda) en función de su pertenencia a grupos de Google Workspace. Cuando se pierda o roben un Chromebook, al eliminarlo de la unidad organizativa Store-Associates se revocará de inmediato 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 el camino más seguro 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 la implementación de certificados y la necesidad de evitar dependencias de infraestructura locales.
Ver respuesta modelo
Implemente una solución Cloud RADIUS con integración en Entra ID. Utilice Microsoft Intune para implementar 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 WiFi WPA3-Enterprise en Intune especificando EAP-TLS y vincule el perfil de certificado SCEP. Los dispositivos reciben silenciosamente el certificado y la configuración 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 deshabilita una cuenta de Entra ID.
Q2. Un usuario de su hotel informa que no puede conectarse a la WiFi del personal interno tras regresar de dos semanas de vacaciones. Otros empleados se conectan sin problemas. La red utiliza EAP-TLS con certificados implementados 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 en búsquedas de directorios en tiempo real.
Ver respuesta modelo
- El certificado de cliente del usuario ha caducado. 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 caducidad 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 hora), lo que hace 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 Microsoft Entra ID del usuario se colocó en un grupo diferente durante su ausencia (por ejemplo, se movió de personal activo a una OU diferente) y la política de autenticación RADIUS ya no coincide con su pertenencia al grupo. Verifique la pertenencia al grupo del usuario en Microsoft Entra ID frente 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 clave WPA2 PSK compartida actual en la red de operaciones de las tiendas por una autenticación 802.1X. No dispone de servidores locales en ninguna de las tiendas. ¿Qué arquitectura implementa y cuál es el principal beneficio de seguridad en comparación con el enfoque PSK actual?
Sugerencia: Considere qué sucede cuando se pierde o roban un Chromebook bajo cada modelo de autenticación.
Ver respuesta modelo
Implemente 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, implemente la CA raíz y un perfil de certificado de cliente SCEP en la Unidad Organizativa de Asociados de Tienda. Cree un perfil de WiFi WPA3-Enterprise especificando EAP-TLS e impleméntelo en la misma OU. Configure los puntos de acceso de HPE Aruba (o equivalente) en cada tienda para que apunten al servicio Cloud RADIUS. El principal beneficio de seguridad: con la PSK compartida actual, un Chromebook perdido o robado mantiene el acceso a la WiFi hasta que se rota la PSK en las 80 tiendas, un proceso disruptivo y lento. Con EAP-TLS, eliminar el dispositivo de la OU de Asociados de Tienda en Google Admin Console revoca inmediatamente su certificado y su acceso a la red, sin afectar a ningún otro dispositivo.
Q4. Durante una implementación de Cloud RADIUS, configura el SSID en los puntos de acceso Cisco Meraki e implementa 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 implementado correctamente. ¿Qué es lo primero que debe comprobar?
Sugerencia: La causa más común de fallo en la implementación 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 bloqueados en el cortafuegos son la causa principal de fallos en la implementación inicial. El hecho de que los certificados y los perfiles de WiFi se hayan implementado 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 (aumentar a al menos 5 segundos); y si las IP del servidor Cloud RADIUS están introducidas correctamente en la configuración del SSID de Meraki.
Continúe leyendo esta serie
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 y, al mismo tiempo, eliminar los costes operativos de la infraestructura local.
¿Qué es Cloud RADIUS? Una guía completa sobre RADIUS-as-a-Service
Esta guía completa analiza Cloud RADIUS (RADIUS-as-a-Service), detallando su arquitectura, métodos de 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 en la nube escalable, seguro y compatible.
Migración de RADIUS local (NPS) a RADIUS-as-a-Service
Esta guía autorizada detalla la arquitectura técnica, la metodología de implementación y el impacto empresarial de la migración de un Microsoft Network Policy Server (NPS) local a un modelo RADIUS-as-a-Service nativo de la nube. Proporciona a los líderes de TI y arquitectos de redes marcos prácticos para reducir la sobrecarga operativa, eliminar los puntos únicos de fallo y asegurar la autenticación empresarial en sedes distribuidas.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.