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 de WiFi empresarial. Cubre el cambio arquitectónico de NPS local a un RADIUS nativo de la nube, la implementación de autenticación EAP-TLS basada en certificados y las mejores prácticas operativas para proteger el acceso inalámbrico en entornos de hospitalidad, retail y sector público. Para los gerentes 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.
Escucha 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 Active Directory Domain Services local y 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 lastre - costoso 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 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 sin fricciones para el personal en cada sitio.
Esta guía cubre la decisión de arquitectura 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, propiedades de retail, estadios y recintos del sector público. Para una introducción más amplia al control de acceso a la red, consulte A Guide to Your Network Access Control System.
Inmersión técnica profunda: arquitectura y estándares
El papel de RADIUS y IEEE 802.1X
La base de una red WiFi empresarial segura es el estándar IEEE 802.1X, que proporciona un 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 y 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 mediante 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 (RADIUS-as-a-Service) |
|---|---|---|
| Infraestructura | Se 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 Microsoft |
| Alta disponibilidad | HA manual y equilibrio de carga | Escalamiento automático por parte del proveedor |
| Tiempo de configuración | Días a semanas | Horas |
| Ideal para | AD híbrido, dispositivos heredados | Organizaciones gestionadas por MDM y nativas de la nube |
| Complejidad operativa | Mayor esfuerzo inicial y continuo | Menor gasto operativo |
EAP-TLS vs. 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 ingresen sus credenciales de dominio. Esto es vulnerable al robo de credenciales y a ataques de intermediario. 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 de enlace EAP y capturar las credenciales. Esto es un ataque de gemelo malvado, 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 prueban su identidad criptográficamente. No hay contraseñas que escribir o 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 vía 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 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 mediante 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 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 de OAuth en el momento de la autenticación para verificar la identidad del usuario y la pertenencia a grupos en tiempo real.
-
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Guía de implementación
La implementación de RADIUS-as-a-Service 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 los 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 tenga licencias de Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Esto incluye Microsoft Intune y Conditional Access. Sin Intune, no es posible la implementación automatizada de certificados.
Para Google Workspace: confirme que tiene 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 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 las licencias 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 Trusted Certificate. Cargue el certificado de la CA raíz y impleméntelo en sus grupos de dispositivos de destino. Esto garantiza que los dispositivos de los clientes confíen en el certificado presentado por el servidor RADIUS durante el protocolo de enlace TLS. A continuación, cree un perfil de SCEP Certificate. Para la autenticación basada en el usuario, establezca el nombre del sujeto en CN={{UserPrincipalName}}. Para la autenticación basada en el dispositivo, utilice CN={{DeviceName}}. Configure el nombre alternativo del sujeto para que incluya el nombre principal del usuario o el ID del dispositivo.
Ruta de Google Admin Console: navegue 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 intermediario para las solicitudes a una entidad de certificación de Microsoft local. Implemente la CA raíz y los perfiles de certificado de cliente en las unidades organizativas adecuadas.
Fase 3: configurar la integración de Cloud RADIUS
Otorgue a su proveedor de Cloud RADIUS los permisos de API necesarios en su tenant 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 Google Admin Console e instálelos en el servicio RADIUS.
Defina sus políticas de autenticación dentro del portal de administración de Cloud RADIUS. Una política bien estructurada para un entorno corporativo sería: "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 Compliant en Intune." Esto aplica la identidad, la pertenencia al grupo y el estado de salud del dispositivo de forma simultánea.
Fase 4: configurar la infraestructura inalámbrica
En su controlador de LAN inalámbrica o panel de administración en la nube - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks o Fortinet - agregue las direcciones IP y los secretos compartidos del servidor Cloud RADIUS como servidores de autenticación RADIUS. Configure servidores primarios y secundarios para tener redundancia. Establezca el tiempo de espera (timeout) de RADIUS en un mínimo de cinco segundos para dar margen a la latencia de ida y vuelta de la nube.
Cree un nuevo SSID configurado para WPA2 o WPA3 corporativo (WPA2-Enterprise o WPA3-Enterprise). Para implementaciones en Hotelería, asegúrese de que el SSID corporativo esté en una VLAN separada de cualquier red de Guest WiFi. Para entornos de Retail, considere implementar el SSID corporativo únicamente en las áreas de back office.
Fase 5: desplegar el perfil de WiFi a través de MDM
Microsoft Intune: cree un perfil de configuración de WiFi. Configure 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 la 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 silenciosamente el certificado y la configuración de WiFi durante su próxima sincronización de Intune.
Google Admin Console: navegue a Dispositivos, luego a Redes y después a WiFi. Cree un nuevo perfil de red WiFi. Configure 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 conectarán de forma silenciosa y segura.
Mejores prácticas
Exija EAP-TLS en todos los nuevos despliegues. No implemente 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 Google Admin Console, hay un campo para especificar la CA de confianza para la validación del servidor. No deje esto en blanco. Esta decisión de configuración única 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 membresía de grupo del usuario en Entra ID o Google Workspace y asignarlo dinámicamente a diferentes VLANs. 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 una vulnerabilidad 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 e invitados. Intentar configurar manualmente EAP-TLS en dispositivos no administrados genera una sobrecarga de soporte excesiva. La plataforma Guest WiFi de Purple maneja el registro de invitados por separado, manteniendo una divisió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 en la red que el NPS local no genera. Establezca el tiempo de espera de RADIUS en sus puntos de acceso a un mínimo de cinco segundos. Un tiempo de espera de dos segundos - común en las configuraciones predeterminadas - causará fallas de autenticación intermitentes.
-
Solución de problemas y mitigación de riesgos
Los puertos de firewall bloqueados son la causa principal de fallas 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 (accounting) de RADIUS requiere el puerto UDP 1813. Verifique que estos estén abiertos antes de realizar cualquier otra acción de solució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 la hora del 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 desplegado con éxito en el dispositivo a través de MDM.
La falta de aplicación de la membresía de grupo 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 membresías de los grupos. En Entra ID, confirme que la entidad de servicio tenga GroupMember.Read.All. En Google Workspace, confirme que el cliente LDAP seguro tenga permiso para leer la información del grupo.
La asignación de VLAN no funciona generalmente 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 por lo general 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 comercial
Migrar a Cloud RADIUS ofrece ahorros operativos mensurables. El RADIUS local requiere como mínimo dos servidores para alta disponibilidad, parches de sistema operativo continuos, administración de certificados y tiempo de ingeniería especializada. El tiempo de un solo ingeniero dedicado al mantenimiento de RADIUS durante un año suele superar 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, ni 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 brindan datos más enriquecidos sobre la utilización del espacio y los recorridos de los visitantes cuando el acceso a la red está vinculado a identidades autenticadas. Pasa de direcciones MAC anónimas a usuarios autenticados con nombre, 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 en múltiples sitios. 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, esta es una ventaja operativa significativa.
Para operadores de Transport y recintos de Healthcare 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 failover multirregión integrado. 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 seguir leyendo sobre temas relacionados, consulte Definición de computadora WAN: Una guía práctica para 2026 y Día Mundial del WiFi 2026: Cómo su establecimiento puede ayudar a cerrar la brecha digital.
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 Contabilización (AAA) para los usuarios que se conectan a un servicio de red. El servidor RADIUS actúa como el motor de decisión 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 802.1X no funciona.
RADIUS-as-a-Service (RADIUSaaS)
Una implementación de RADIUS alojada en la nube que se entrega como un servicio administrado. El proveedor mantiene la infraestructura, los parches, la alta disponibilidad y las integraciones con el proveedor de identidad. Usted configura las políticas de autenticación y apunta sus puntos de acceso a las direcciones IP de Cloud RADIUS.
RADIUS-as-a-Service elimina la necesidad de servidores NPS o FreeRADIUS locales, suprimiendo los costos 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 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 el 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 este. 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 empresariales. Sigue estando muy implementada, pero se debe migrar a EAP-TLS en todas las implementaciones nuevas y existentes donde sea posible.
Microsoft Entra ID
El servicio de administración de identidades y accesos basado en la nube de Microsoft, anteriormente conocido como Azure Active Directory (Azure AD). Administra 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 Microsoft Entra ID a través de la Microsoft Graph API.
Google Secure LDAP
Un servicio administrado 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 mediante certificados de cliente.
La ruta de integración principal para conectar un servidor RADIUS en la nube 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 roles, políticas, hardware, software y procedimientos necesarios para crear, administrar, distribuir, usar, 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 de RADIUS o de Microsoft (Cloud PKI) eliminan la necesidad de contar con servicios de certificados de Active Directory (ADCS) de manera local.
SCEP (Protocolo de inscripción de certificados simple)
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 la consola de administración de Google para implementar certificados de cliente en dispositivos administrados 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.
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 membresía de 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 de diferentes roles o departamentos accede a distintos 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 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 laptops Windows administradas por Intune. La infraestructura inalámbrica es Cisco Meraki. El hotel necesita que el personal se conecte automáticamente sin solicitar contraseñas, 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 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 "Todos los dispositivos corporativos". 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 es emitido por la [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 principal 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. Despliegue en el grupo "Todos los dispositivos corporativos". Los dispositivos reciben silenciosamente 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 retail con 50 tiendas utiliza Google Workspace y administra 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 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 Google Admin Console, navegue a Apps, luego 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 los Chromebooks. En la Google Admin Console, navegue a Dispositivos, luego Redes, luego 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. Paso 4: en la Google Admin Console, cree un perfil WiFi WPA3-Enterprise para el SSID de operaciones de la tienda. Establezca EAP-TLS, vincule la CA Raíz y aplíquelo a la Unidad Organizativa de Asociados de Tienda. Los Chromebooks reciben el certificado y el perfil WiFi en la siguiente sincronización de la Admin Console. Paso 5: en HPE Aruba Central, configure el SSID de operaciones de la tienda con WPA3-Enterprise y agregue las direcciones IP principal 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) en función de su membresía de grupo de Google Workspace. Cuando un Chromebook se pierde o es robado, su eliminación de la Unidad Organizativa de Asociados de Tienda revoca 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 de WiFi en 300 laptops corporativas administradas por Intune. Cuenta con licencias de 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 la implementación de certificados y la necesidad de evitar dependencias de infraestructura local.
Ver respuesta modelo
Implemente una solución de Cloud RADIUS con integración con Microsoft Entra ID. Utilice Microsoft Intune para implementar un perfil de certificado de confianza (CA raíz) 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 Microsoft 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 silenciosamente 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 Microsoft Entra ID.
Q2. Un usuario de su hotel informa que no puede conectarse a la WiFi del personal administrativo tras regresar de unas vacaciones de dos semanas. El resto del personal se conecta sin problemas. La red utiliza EAP-TLS con certificados implementados 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 con tiempo de validez limitado y búsquedas de directorio en tiempo real-time.
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 de dispositivos de Intune. 2. El reloj del sistema del dispositivo está significativamente desincronizado (desviación de reloj), lo que provoca que la validación del certificado falle. EAP-TLS valida las marcas de tiempo de los certificados; un reloj desincronizado por más de cinco minutos provocará fallas de autenticación. 3. La cuenta de Entra ID del usuario fue colocada en un grupo diferente durante su ausencia (por ejemplo, se movió de personal activo a una unidad organizativa distinta) y la política de autenticación RADIUS ya no coincide con su membresía de grupo. Verifique las membresías de grupo del usuario en Entra ID en relación con la política 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 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 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 una 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 las 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 unidad organizativa. 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 cambie la PSK en las 80 tiendas, un proceso disruptivo y lento. Con EAP-TLS, eliminar el dispositivo de la unidad organizativa de asociados de tienda en Google Admin Console revoca inmediatamente su certificado y 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 se puede conectar. El estado del dispositivo en Intune muestra que el certificado y el perfil de WiFi se implementaron correctamente. ¿Qué es lo primero que debe verificar?
Sugerencia: La causa más común de falla en la implementación inicial no es un error de configuración en la política RADIUS o en el certificado.
Ver respuesta modelo
Verifique 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 firewall bloqueados son la causa principal de fallas 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 verificaciones 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 direcciones IP del servidor Cloud RADIUS están ingresadas 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 propiedades empresariales distribuidas. 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 costos operativos de la infraestructura local.
¿Qué es Cloud RADIUS? Una guía completa de RADIUS-as-a-Service
Esta guía completa explora Cloud RADIUS (RADIUS-as-a-Service), 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 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 comercial 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 red marcos prácticos para reducir los gastos operativos, eliminar los puntos únicos de falla y asegurar la autenticación empresarial en sedes distribuidas.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.