Integrating RADIUS as a Service with Cloud Directories (Azure AD & 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, la implementación de la autenticación EAP-TLS basada en certificados y las mejores prácticas operativas para proteger el acceso inalámbrico en entornos de hotelería, retail y el 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.

📖 10 min de lectura📝 2,373 palabras🔧 2 ejemplos resueltos❓ 4 preguntas de práctica📚 10 definiciones clave

Escucha esta guía

Ver transcripción del podcast

Welcome to the Purple Technical Briefing. Today, we are covering a topic that sits at the intersection of cloud identity management and physical network security: integrating RADIUS as a Service with cloud directories, specifically Microsoft Entra ID and Google Workspace.

If you are managing enterprise WiFi across a hotel, a retail estate, a stadium, or a public-sector estate, this briefing is directly relevant to your next infrastructure decision.

Let us start with context. For the past two decades, WiFi authentication in enterprise environments relied on a fairly predictable stack. You had on-premise Active Directory, Windows Network Policy Server acting as the RADIUS server, and WPA2-Enterprise on the access points. It worked. But it required on-premise servers, manual certificate management, and a team with specialist knowledge to keep it running.

The problem is that most organisations are no longer on-premise first. They are cloud-first. Microsoft Entra ID and Google Workspace are now the directories of record for millions of organisations. And here is the gap: your wireless access points still speak RADIUS. They do not understand SAML. They do not understand OAuth. They speak RADIUS, and they always will.

So the question is: how do you bridge your cloud identity platform to your physical network infrastructure, without dragging an on-premise server back into the picture?

The answer is RADIUS as a Service. A cloud-hosted RADIUS server that integrates directly with your cloud directory, validates authentication requests in real time, and returns an access decision to your access point. No on-premise servers. No patching. No 2am certificate renewal emergencies.

The foundation is IEEE 802.1X. When a device tries to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point acts as an authenticator. It intercepts the connection attempt and forwards EAP packets to the RADIUS server. The RADIUS server validates the identity and returns either an Access-Accept or an Access-Reject. Only then does the access point grant network access.

Now, the most consequential technical decision in this entire deployment is your choice of EAP method.

PEAP-MSCHAPv2 is the old way. It uses usernames and passwords. It sounds secure. It is not. If a device does not strictly validate the RADIUS server certificate, an attacker can set up a rogue access point with your SSID, intercept the handshake, and capture the credentials. This is called an Evil Twin attack, and it is happening.

EAP-TLS is the right answer. It uses digital certificates on both the server and the client device for mutual authentication. There are no passwords involved. The device presents its certificate. The RADIUS server validates it against your cloud directory in real time. No credential theft possible. No phishing vector. No helpdesk tickets when someone changes their password.

Let us walk through a Microsoft Entra ID deployment.

Step one: licensing and PKI. You need Microsoft 365 E3 or E5 to access Intune and Conditional Access. Establish a cloud PKI using your Cloud RADIUS vendor's managed PKI or Microsoft's own Cloud PKI.

Step two: certificate deployment via Intune. Create a Trusted Certificate profile with your Root CA and deploy it to device groups. Then create a SCEP certificate profile. For user-based authentication, the subject name uses the User Principal Name.

Step three: Cloud RADIUS configuration. Grant the RADIUS service Microsoft Graph API permissions: User.Read.All and GroupMember.Read.All. Define your authentication policies: allow access if the certificate is issued by our trusted CA, the user is a member of the Corporate-WiFi-Users group in Entra ID, and the device is marked compliant in Intune.

Step four: wireless infrastructure. In your controller, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, add the Cloud RADIUS IP addresses and shared secrets. Set the RADIUS timeout to at least five seconds. Create your WPA3-Enterprise SSID.

Step five: WiFi profile deployment. Create a WiFi configuration profile in Intune. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, link the SCEP certificate profile. Devices silently receive the certificate and WiFi profile on their next sync. They connect automatically. No user interaction required.

Now let us look at the Google Workspace path, because it is architecturally different in one important way.

Google does not offer a native RADIUS service. There is no Google equivalent of Windows NPS. So you always need an intermediary: a Cloud RADIUS provider that connects to Google Workspace via Google Secure LDAP or via a SAML and OAuth integration.

Google Secure LDAP is available on Cloud Identity Premium and Google Workspace Enterprise editions. It provides a traditional LDAP interface to your cloud directory. Your Cloud RADIUS server connects to ldap.google.com on port 636 using client certificates that Google generates for you. From that point, the RADIUS server can query Google's directory to validate credentials or group memberships.

For managed Chromebooks, the deployment path uses the Google Admin Console. You configure a cloud PKI to issue certificates, push the Root CA and client certificates to the Chromebooks, and deploy a WiFi profile specifying EAP-TLS. The Chromebooks connect silently. For BYOD devices and guest access, you use a captive portal tied to Google Single Sign-On. That is the right separation: EAP-TLS for managed devices, captive portal for everything else.

Let us talk about pitfalls, because this is where deployments go wrong.

The first and most common is blocked firewall ports. RADIUS authentication uses UDP port 1812. RADIUS accounting uses UDP port 1813. If those ports are not open outbound from your wireless infrastructure to the Cloud RADIUS service, nothing works. Check this first, every time.

The second pitfall is certificate expiry. If your RADIUS server certificate expires, every device on the network loses connectivity simultaneously. Set monitoring alerts at 90 days, 30 days, and 7 days before expiry. Automate renewal where possible.

The third is clock skew. EAP-TLS relies on accurate timekeeping for certificate validation. If a device's system clock is significantly out of sync, certificate validation fails. Ensure NTP is configured correctly across all devices and infrastructure.

The fourth, specific to PEAP deployments, is failing to enforce strict server certificate validation on client devices. Without it, devices will accept any certificate presented by any access point claiming to be yours. This is the single configuration decision that separates a secure deployment from a vulnerable one.

Now for a rapid-fire question and answer.

Can I use Cloud RADIUS for both staff and guest WiFi? Staff WiFi, yes, using EAP-TLS. Guest WiFi should use a separate captive portal. Mixing the two on a single SSID creates unnecessary complexity and security risk.

Does this work with WPA3? Yes. WPA3-Enterprise is fully supported and recommended for all new deployments.

What about compliance? EAP-TLS with Cloud RADIUS supports PCI DSS requirements for strong authentication on cardholder data networks. It also supports GDPR obligations by enabling precise access logging and instant revocation when an employee leaves.

How does this affect our analytics capabilities? Positively. By tying network access to a verified cloud identity, platforms like Purple's WiFi Analytics provide richer data on space utilisation. You move from anonymous MAC addresses to authenticated, named users, which transforms the quality of your insight.

To summarise the key takeaways.

One: Cloud RADIUS eliminates on-premise server dependencies. Your access points authenticate against a cloud-hosted service that integrates directly with Entra ID or Google Workspace.

Two: EAP-TLS is the right authentication method. Certificates replace passwords. No phishing vector, no credential theft, no helpdesk overhead from password resets.

Three: Microsoft Intune and Google Admin Console automate certificate deployment. Devices receive certificates and WiFi profiles silently, with no user interaction.

Four: Dynamic VLAN assignment via RADIUS attributes enables granular network segmentation based on directory group membership. This limits lateral movement and supports compliance.

Five: Always verify ports 1812 and 1813 are open, monitor certificate expiry, and enforce strict server certificate validation.

If you are planning a deployment this quarter, start with a pilot group of 20 to 50 devices. Validate the certificate deployment, the RADIUS authentication, and the VLAN assignment before rolling out globally. The investment in getting this right pays dividends in reduced helpdesk overhead, a stronger security posture, and the ability to use your network data for genuine business intelligence.

Thank you for listening to the Purple Technical Briefing. For detailed deployment steps, configuration examples, and worked scenarios, see the full technical reference guide at purple.ai.

Puntos clave

✓Cloud RADIUS eliminates on-premise NPS and FreeRADIUS servers. Your access points authenticate against a cloud-hosted service that integrates directly with Microsoft Entra ID or Google Workspace.
✓EAP-TLS is the correct authentication method for enterprise WiFi. It uses digital certificates instead of passwords, eliminating credential theft, phishing, and password-related helpdesk overhead.
✓Microsoft Intune and Google Admin Console automate certificate deployment to managed devices via SCEP profiles. Devices receive certificates and WiFi profiles silently, with no user interaction.
✓Google Workspace requires an intermediary for RADIUS integration. Google Secure LDAP (available on Cloud Identity Premium and Enterprise editions) provides the LDAP interface that Cloud RADIUS servers use to query the Google directory.
✓Dynamic VLAN assignment via RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) enables granular network segmentation based on directory group membership, supporting PCI DSS requirements.
✓Check UDP ports 1812 and 1813 first. Blocked firewall ports are the leading cause of initial deployment failure. Monitor certificate expiry at 90, 30, and 7 days. Enforce strict server certificate validation on all PEAP deployments.
✓Disabling a user in Entra ID or Google Workspace immediately revokes their WiFi access at all sites. This is the primary offboarding advantage over PSK-based networks and directly supports GDPR obligations.

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 locales y de Windows Network Policy Server (NPS). A medida que las organizaciones migran a Microsoft Entra ID y Google Workspace, esa pila de autenticación local se convierte en una debilidad: 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 puntos únicos de falla. Combinada con la autenticación basada en certificados EAP-TLS, esta arquitectura elimina el robo de credenciales, respalda el cumplimiento de PCI DSS y GDPR, y ofrece una experiencia fluida para el personal en cada sitio.

Esta guía cubre la decisión arquitectónica entre NPS local y RADIUS nativo de la nube, la implementación de EAP-TLS a través de Microsoft Intune y Google Admin Console, y las mejores prácticas operativas para proteger el acceso inalámbrico en hoteles, tiendas minoristas, estadios y espacios del sector público. Para obtener 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 (Protocolo de autenticación extensible). 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 externo de Cloud RADIUS se integra directamente con Microsoft Entra ID a través de la API de Microsoft Graph, o con Google Workspace a través de Google Secure LDAP o SAML/OAuth. La autenticación ocurre completamente en la nube. Esto se alinea con los principios de acceso a la red zero-trust y reduce significativamente los costos operativos.

La siguiente tabla compara los dos enfoques arquitectónicos principales:

Dimensión	Híbrido local (NPS)	Nativo de la nube (RADIUSaaS)
Infraestructura	Se requiere VM de Windows Server o bare metal	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 balanceo 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 cloud-first gestionadas por MDM
Complejidad operativa	Mayor complejidad inicial y continua	Menor costo operativo

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 esta implementación. PEAP-MSCHAPv2 depende de que los usuarios ingresen sus credenciales de dominio. Esto es vulnerable al robo de credenciales y a ataques de intermediario (man-in-the-middle). Si un dispositivo cliente no valida estrictamente el certificado del servidor RADIUS (y muchos no lo hacen de forma predeterminada), un atacante puede implementar un punto de acceso no autorizado con su SSID, interceptar el saludo EAP y capturar las credenciales. Este es un ataque de gemelo malvado (Evil Twin) y está bien 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 de forma criptográfica. No hay contraseñas que escribir ni robar. En un entorno de Microsoft, los certificados se implementan de forma silenciosa a través de Microsoft Intune utilizando perfiles SCEP (Simple Certificate Enrollment Protocol) o PKCS. Esta es la ruta recomendada para todas las nuevas implementaciones 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 API de Microsoft Graph. Google, sin embargo, no ofrece un servicio RADIUS nativo. Siempre se necesita un intermediario.

Google Secure LDAP es la ruta de integración principal. Disponible en las ediciones Cloud Identity Premium y Google Workspace Enterprise, proporciona una interfaz LDAP tradicional para su directorio en la nube. Su servidor Cloud RADIUS se conecta a ldap.google.com en el puerto 636 utilizando los certificados de cliente que Google gener para usted. A partir de ese momento, el servidor RADIUS consulta el directorio de Google para validar las credenciales o las membresías de grupo, tal como lo haría con 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 al momento de la autenticación para verificar la identidad del usuario y sus membresías de grupo en tiempo real.

Guía de implementación

La implementación de RADIUSaaS con EAP-TLS requiere coordinar la identidad, la gestión de dispositivos y la infraestructura de red. El siguiente enfoque de cinco fases se aplica tanto a entornos de Microsoft Entra ID como de Google Workspace.

Fase 1: preparar la infraestructura de 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 Acceso condicional. Sin Intune, la implementación automatizada de certificados no es posible.

Para Google Workspace: confirme que tiene Cloud Identity Premium o Google Workspace Enterprise para acceder a Google Secure LDAP. Si planea usar EAP-TLS en Chromebooks administrados, asegúrese de que 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 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). Suba el certificado de la CA raíz y despliéguelo en sus grupos de dispositivos de destino. Esto garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el saludo TLS. A continuación, cree un perfil de Certificado SCEP. Para la autenticación basada en el usuario, establezca el Nombre del sujeto (Subject Name) en CN={{UserPrincipalName}}. Para la autenticación basada en el dispositivo, use 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: 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 de SCEP con Google Workspace, o el Google Cloud Certificate Connector que actúa como proxy para las solicitudes a una Autoridad 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

Otorgue 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 cumplimiento 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 administración de Cloud RADIUS. Una política bien estructurada para un entorno corporativo: "Permitir el acceso si el certificado es emitido por [Trusted CA] Y el usuario es miembro del grupo [Corporate-WiFi-Users] Y el dispositivo está marcado como Compliant (Compatible) en Intune". Esto aplica la identidad, la membresía de 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 administración en la nube (Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet), agregue 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 de Hospitalidad , asegúrese de que el SSID corporativo esté en una VLAN separada de cualquier red de WiFi para invitados . Para entornos de Comercio minorista , considere implementar el SSID corporativo únicamente en las áreas internas (back-of-house).

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 el certificado de cliente y especifique el perfil de CA raíz de confianza (Trusted Root CA). 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 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.

Mejores prácticas

Exija EAP-TLS en todas las nuevas implementaciones. 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 este campo en blanco. Esta única decisión de configuración marca la diferencia entre una implementación segura y una vulnerable.

Segmente su red con la 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 asignarlos dinámicamente a diferentes VLAN. El servidor RADIUS devuelve el Tunnel-Private-Group-Id al punto de acceso, lo que 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 de invitados. Utilice EAP-TLS para dispositivos administrados por la empresa. Utilice un Captive Portal con SSO para dispositivos BYOD y de invitados. Intentar configurar manualmente EAP-TLS en dispositivos no administrados genera una sobrecarga de soporte excesiva. La plataforma Guest WiFi de Purple gestiona la incorporación de invitados por separado, manteniendo una separación clara entre el tráfico del personal y el de los visitantes.

Monitoree el vencimiento de los certificados de manera proactiva. Configure el monitoreo y las alertas a los 90 días, 30 días y siete días antes del vencimiento del certificado. Si el certificado de su servidor RADIUS vence, todos los dispositivos perderán la conectividad simultáneamente. Automatice la renovación donde su PKI lo admita.

Pruebe la configuración de tiempo de espera (timeout) de RADIUS. Cloud RADIUS introduce una latencia de ida y vuelta de red que el NPS local (on-premise) no presenta. Establezca el tiempo de espera de RADIUS en sus puntos de acceso en al menos cinco segundos. Un tiempo de espera de dos segundos (común en las configuraciones predeterminadas) provocará fallas de autenticación intermitentes.

Solución de problemas y mitigación de riesgos

Los puertos de firewall bloqueados son la causa principal de fallas en la implementación inicial. La autenticación RADIUS requiere el puerto UDP 1812 de salida desde su infraestructura inalámbrica hacia el servicio Cloud RADIUS. El registro (accounting) de RADIUS requiere el puerto UDP 1813. Verifique que estos estén abiertos antes de realizar cualquier otra solución de problemas.

Fallas de validación de certificados se presentan como rechazos de autenticación sin una causa obvia. Verifique lo siguiente en orden: el vencimiento del certificado tanto en el cliente como en el servidor RADIUS; el desfase de reloj entre el dispositivo cliente y el servidor RADIUS (EAP-TLS depende de una sincronización de tiempo precisa); y si el certificado de la CA raíz se ha implementado correctamente en el dispositivo a través de MDM.

La no aplicación de la 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 grupo. En Entra ID, confirme que la entidad de servicio tenga GroupMember.Read.All. En Google Workspace, confirme que el cliente Secure LDAP tenga permiso para leer la información del grupo.

El fallo en la asignación de VLAN generalmente indica 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é 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 generalmente indican que el certificado de cliente no se implementó correctamente. Para dispositivos administrados por Intune, verifique el almacén de certificados del dispositivo en el centro de administración de Intune. Para Chromebooks administrados por Google, verifique que el perfil de certificado esté asignado a la Unidad Organizativa correcta y que el dispositivo se haya sincronizado recientemente.

ROI e impacto empresarial

Migrar a Cloud RADIUS ofrece ahorros operativos medibles. El RADIUS local (on-premise) 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 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:

Baja inmediata de usuarios. Deshabilitar a un usuario en Entra ID o Google Workspace revoca de inmediato su acceso a la red en todos los sitios. No hay demoras, procesos manuales ni riesgo de que un excolaborador conserve el acceso a la WiFi. Esto respalda directamente las obligaciones de GDPR en torno a los derechos de acceso a los datos.

Analíticas más completas. Las plataformas como WiFi Analytics de Purple proporcionan datos más enriquecidos sobre el uso del espacio y los recorridos de los visitantes cuando el acceso a la red está vinculado a identidades autenticadas. Pasará de direcciones MAC anónimas a usuarios identificados y autenticados, lo que transforma la calidad de la información disponible para los equipos de operaciones y marketing.

Evidencia de cumplimiento. La autenticación EAP-TLS genera registros de acceso detallados: quién se conectó, desde qué dispositivo, en qué ubicación y a qué hora. Este registro de auditoría respalda el Requisito 10 de PCI DSS (registro y monitoreo) y las obligaciones de rendición de cuentas de GDPR.

Consistencia multisitio. Un único servicio de Cloud RADIUS autentica todos sus sitios con políticas consistentes, administradas desde un solo panel de control. Agregar un nuevo hotel, tienda o establecimiento significa agregar sus puntos de acceso a la configuración de RADIUS, no enviar y configurar otro servidor. Para las organizaciones que gestionan grandes propiedades, esta es una ventaja operativa significativa.

Para los operadores de Transporte y los centros de Salud 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 (failover) multirregión integrada. Purple opera con un 99.999% de tiempo de actividad 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 leer más 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)

A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service. The RADIUS server acts as the decision engine between your access points and your identity directory.

Every enterprise WPA2-Enterprise or WPA3-Enterprise WiFi network depends on a RADIUS server. Without it, IEEE 802.1X authentication does not function.

RADIUS as a Service (RADIUSaaS)

A cloud-hosted RADIUS implementation delivered as a managed service. The provider maintains the infrastructure, patching, high availability, and identity provider integrations. You configure authentication policies and point your access points to the cloud RADIUS IPs.

RADIUSaaS eliminates the need for on-premise NPS or FreeRADIUS servers, removing the associated hardware, OS patching, and specialist maintenance overhead.

IEEE 802.1X

An IEEE standard for port-based Network Access Control. It defines the three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS server). The authenticator blocks all traffic until the RADIUS server grants access.

The foundational standard for enterprise WiFi authentication. WPA2-Enterprise and WPA3-Enterprise both rely on 802.1X.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

An authentication method defined in RFC 5216 that uses digital certificates on both the RADIUS server and the client device for mutual authentication. Neither party sends a password. The client presents its certificate; the server validates it against the directory in real time.

The gold standard for enterprise WiFi security. Eliminates credential theft, phishing, and password-related helpdesk overhead. Required for PCI DSS compliance on cardholder data networks.

PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)

An authentication method that creates an encrypted TLS tunnel and then sends the user's username and password through it. Vulnerable to Evil Twin attacks if the client does not strictly validate the RADIUS server certificate.

The legacy default for enterprise WiFi. Still widely deployed but should be migrated to EAP-TLS in all new and existing deployments where possible.

Microsoft Entra ID

Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory (Azure AD). Manages user identities, group memberships, device compliance, and Conditional Access policies.

The primary identity source for Cloud RADIUS in Microsoft-centric environments. Cloud RADIUS providers connect to Entra ID via Microsoft Graph API.

Google Secure LDAP

A managed service available on Cloud Identity Premium and Google Workspace Enterprise editions that provides a traditional LDAP interface to Google's cloud directory. RADIUS servers connect to ldap.google.com on port 636 using client certificates.

The primary integration path for connecting a Cloud RADIUS server to Google Workspace. Google does not offer a native RADIUS service, so Secure LDAP acts as the bridge.

PKI (Public Key Infrastructure)

The set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. A PKI is required to issue the client and server certificates used in EAP-TLS authentication.

Cloud-native PKI options from RADIUS vendors or Microsoft (Cloud PKI) eliminate the need for on-premise Active Directory Certificate Services (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

A protocol that enables devices to request and receive digital certificates from a Certificate Authority automatically. Used by Microsoft Intune and Google Admin Console to deploy client certificates to managed devices without user interaction.

SCEP profiles in Intune are the mechanism by which corporate devices silently receive the client certificates needed for EAP-TLS authentication.

Dynamic VLAN assignment

A RADIUS feature that returns VLAN assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) to the access point based on the authenticated user's directory group membership. The AP places the client on the specified VLAN automatically.

Enables granular network segmentation without manual VLAN configuration per device. Staff in different roles or departments land on different network segments, limiting lateral movement and supporting PCI DSS segmentation requirements.

Ejemplos resueltos

A 200-room hotel is migrating its back-of-house staff network from an ageing on-premise NPS server to a cloud-native solution. The hotel has recently moved to Microsoft Entra ID and Microsoft 365 E5. Staff devices are Windows laptops managed by Intune. The wireless infrastructure is Cisco Meraki. The hotel needs staff to connect automatically without password prompts, and needs instant revocation when a member of staff leaves.

Deploy a Cloud RADIUS solution with Entra ID integration. Step 1: grant the Cloud RADIUS provider Microsoft Graph API permissions (User.Read.All, GroupMember.Read.All, Device.Read.All) in the Entra ID tenant. Step 2: in Intune, create a Trusted Certificate profile with the Cloud RADIUS Root CA and deploy it to the 'All Corporate Devices' group. Step 3: create a SCEP Certificate profile with Subject Name CN={{UserPrincipalName}} and deploy it to the same group. Step 4: configure the Cloud RADIUS authentication policy: allow access if certificate is issued by [Trusted CA] AND user is member of [Hotel-Staff-WiFi] Entra ID group AND device is Intune-compliant. Step 5: in Cisco Meraki dashboard, add the Cloud RADIUS primary and secondary IPs as RADIUS servers on the back-of-house SSID. Set RADIUS timeout to 5 seconds. Step 6: in Intune, create a WPA3-Enterprise WiFi profile for the back-of-house SSID, specifying EAP-TLS and linking the SCEP certificate profile. Deploy to the 'All Corporate Devices' group. Devices silently receive the certificate and WiFi profile on next Intune sync and connect automatically. When a staff member leaves, disabling their Entra ID account immediately revokes network access at all sites.

Comentario del examinador: This approach eliminates the on-premise NPS dependency entirely. EAP-TLS removes the phishing vector of credential-based authentication. Intune automates certificate lifecycle management, removing the manual overhead that caused the previous NPS deployment to fall behind on certificate renewals. The Entra ID group policy means that when HR disables an account, network access is revoked in real time - no manual RADIUS policy update required. The Cisco Meraki integration is straightforward: Cloud RADIUS is hardware-agnostic and works with any 802.1X-capable infrastructure.

A retail chain with 50 stores uses Google Workspace and manages a fleet of 500 Chromebooks used by store associates for inventory and point-of-sale operations. They currently use a shared WPA2 PSK for the store operations network, which creates a security risk when devices are lost or stolen. They want to move to 802.1X authentication without deploying local servers at each store. Their wireless infrastructure is HPE Aruba.

Deploy a Cloud RADIUS solution with Google Workspace integration via Google Secure LDAP. Step 1: in Google Admin Console, navigate to Apps, then LDAP, and add a new LDAP client for the Cloud RADIUS service. Configure read permissions for user information and group membership. Download the generated client certificate and key. Step 2: configure the Cloud RADIUS service with the Google Secure LDAP credentials. Step 3: configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, navigate to Devices, then Networks, then Certificates, and upload the Root CA. Configure the certificate issuance profile and apply it to the Store-Associates Organisational Unit. Step 4: in Google Admin Console, create a WPA3-Enterprise WiFi profile for the store operations SSID. Set EAP-TLS, link the Root CA, and apply to the Store-Associates OU. Chromebooks receive the certificate and WiFi profile on next Admin Console sync. Step 5: in HPE Aruba Central, configure the store operations SSID with WPA3-Enterprise and add the Cloud RADIUS primary and secondary IPs. Set RADIUS timeout to 5 seconds. Configure dynamic VLAN assignment to place store associates on VLAN 20 (store operations) based on their Google Workspace group membership. When a Chromebook is lost or stolen, removing it from the Store-Associates OU immediately revokes its network access.

Comentario del examinador: This deployment eliminates the shared PSK risk. A lost or stolen Chromebook with a shared PSK gives an attacker persistent network access until the PSK is rotated across all 50 stores. With EAP-TLS, the certificate on the lost device can be revoked immediately. The Google Secure LDAP integration is the correct path for Google Workspace environments - it provides a stable, standards-based interface that the Cloud RADIUS service can query without requiring a custom API integration. Dynamic VLAN assignment ensures store associates land on the correct network segment, supporting PCI DSS network segmentation requirements for retail environments.

Preguntas de práctica

Q1. Your organisation is migrating from on-premise Active Directory to Microsoft Entra ID. You currently use PEAP-MSCHAPv2 for WiFi authentication on 300 corporate laptops managed by Intune. You have Microsoft 365 E5 licensing. What is the most secure and operationally efficient path to migrate WiFi authentication to a cloud-native architecture?

Sugerencia: Consider the vulnerabilities of credential-based authentication, the capabilities of Microsoft Intune for certificate deployment, and the need to avoid on-premise infrastructure dependencies.

Ver respuesta modelo

Deploy a Cloud RADIUS solution with Entra ID integration. Use Microsoft Intune to deploy a Trusted Certificate profile (Root CA) and a SCEP Certificate profile to the 300 laptops. Configure the Cloud RADIUS authentication policy to require a valid certificate from the trusted CA and membership of the Corporate-WiFi-Users Entra ID group. Create a WPA3-Enterprise WiFi profile in Intune specifying EAP-TLS and link the SCEP certificate profile. Devices silently receive the certificate and WiFi configuration on next Intune sync. This eliminates PEAP-MSCHAPv2 credential theft risk, removes the on-premise NPS dependency, and provides instant revocation when an Entra ID account is disabled.

Q2. A user at your hotel reports they cannot connect to the back-of-house staff WiFi after returning from a two-week holiday. Other staff are connecting without issue. The network uses EAP-TLS with certificates deployed via Intune. What are the three most likely causes, in order of likelihood?

Sugerencia: EAP-TLS relies on time-sensitive cryptographic assets and real-time directory lookups.

Ver respuesta modelo

The user's client certificate has expired. Certificates have a defined validity period, and if the device was offline during the renewal window, the SCEP profile may not have renewed it. Check the certificate expiry date in the Intune device certificate store. 2. The device's system clock is significantly out of sync (clock skew), causing certificate validation to fail. EAP-TLS validates certificate timestamps; a clock more than five minutes out of sync will cause authentication failures. 3. The user's Entra ID account was placed in a different group during their absence (for example, moved from active staff to a different OU), and the RADIUS authentication policy no longer matches their group membership. Check the user's group memberships in Entra ID against the RADIUS policy.

Q3. You are the IT manager for a retail chain with 80 stores. You use Google Workspace and manage 400 Chromebooks via Google Admin Console. You want to replace the current shared WPA2 PSK on the store operations network with 802.1X authentication. You have no on-premise servers at any store location. What architecture do you deploy, and what is the primary security benefit over the current PSK approach?

Sugerencia: Consider what happens when a Chromebook is lost or stolen under each authentication model.

Ver respuesta modelo

Deploy a Cloud RADIUS service with Google Secure LDAP integration. Configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, deploy the Root CA and a SCEP client certificate profile to the Store-Associates Organisational Unit. Create a WPA3-Enterprise WiFi profile specifying EAP-TLS and deploy it to the same OU. Configure HPE Aruba (or equivalent) access points at each store to point to the Cloud RADIUS service. The primary security benefit: under the current shared PSK, a lost or stolen Chromebook retains WiFi access until the PSK is rotated across all 80 stores - a disruptive, time-consuming process. With EAP-TLS, removing the device from the Store-Associates OU in Google Admin Console immediately revokes its certificate and network access, with no impact on any other device.

Q4. During a Cloud RADIUS deployment, you configure the SSID on Cisco Meraki access points and deploy the Intune WiFi profile to a pilot group of 20 devices. None of the devices can connect. The Intune device status shows the certificate and WiFi profile as successfully deployed. What is the first thing you check?

Sugerencia: The most common cause of initial deployment failure is not a configuration error in the RADIUS policy or the certificate.

Ver respuesta modelo

Check that UDP ports 1812 and 1813 are open outbound from the Cisco Meraki access points (or the Meraki cloud infrastructure) to the Cloud RADIUS server IP addresses. Blocked firewall ports are the leading cause of initial deployment failure. The fact that certificates and WiFi profiles are successfully deployed rules out Intune configuration issues. The next checks are: RADIUS shared secret mismatch between Meraki and the Cloud RADIUS service; RADIUS timeout set too low (increase to at least 5 seconds); and whether the Cloud RADIUS server IPs are correctly entered in the Meraki SSID configuration.

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 fuerzas de trabajo híbridas en entornos distribuidos. Cubre la arquitectura, los beneficios de seguridad y los pasos de implementación para reemplazar la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Para gerentes de TI y arquitectos de redes en hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona la evidencia necesaria para evaluar y ejecutar una migración a RADIUS en la nube este trimestre.

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 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 compatible.