Cómo configurar Azure Entra ID (Azure AD) para la autenticación de WiFi

Resumen ejecutivo

Para los CTO y arquitectos de red que gestionan entornos complejos - desde grandes espacios de hostelería hasta dinámicos entornos de retail - proteger la red corporativa ya no es solo cuestión de contraseñas seguras. Las claves precompartidas (PSK) tradicionales y la validación de credenciales básica son fundamentalmente incompatibles con la arquitectura zero-trust moderna.

Esta guía detalla la transición a la autenticación WiFi basada en certificados 802.1X integrada directamente con Microsoft Entra ID (anteriormente Azure AD). Al migrar a EAP-TLS (protocolo de autenticación extensible con seguridad de la capa de transporte), las empresas pueden eliminar los riesgos asociados con el robo de credenciales, automatizar el registro de dispositivos mediante la gestión de dispositivos móviles (MDM) y garantizar que solo los dispositivos gestionados y conformes puedan acceder a las VLAN corporativas sensibles. Analizamos la arquitectura técnica, los pasos de implementación y cómo este enfoque de seguridad empresarial funciona en paralelo con las estrategias de redes de invitados gestionadas por plataformas como Purple.

Análisis técnico detallado

El cambio de credenciales a certificados digitales

Históricamente, la red WiFi empresarial dependía de PEAP-MSCHAPv2, que requiere que los usuarios introduzcan sus credenciales de dominio. Sin embargo, debido a su susceptibilidad a los ataques de adversario en el medio (AiTM), Microsoft está desestimando activamente la autenticación basada en credenciales. El estándar actual del sector es EAP-TLS, que utiliza la validación mutua de certificados.

En una implementación de EAP-TLS, tanto el servidor RADIUS como el dispositivo cliente presentan certificados digitales. Si un dispositivo carece de un certificado válido emitido por su entidad de certificación (CA) de confianza, el servidor RADIUS rechaza la conexión incluso antes de que el dispositivo obtenga una dirección IP.

El puente de la arquitectura: RADIUS y Entra ID

Microsoft Entra ID es un proveedor de identidad (IdP) en la nube que utiliza protocolos modernos como SAML y OIDC; no admite de forma nativa el protocolo RADIUS utilizado por los puntos de acceso inalámbrico (WAP). Para salvar esta distancia, los arquitectos de red deben implementar un servidor RADIUS capaz de comunicarse con Microsoft Entra ID. Esto se consigue normalmente a través de:

1. Soluciones RADIUS en la nube: Plataformas diseñadas específicamente (como SecureW2, SCEPman o Portnox) que se integran directamente con Microsoft Entra ID e Intune a través de las API.
2. Servidor de políticas de red (NPS) local: Utilizando la extensión Azure MFA, aunque esto se considera cada vez más un enfoque heredado en comparación con las soluciones RADIUS nativas de la nube.

Guía de implementación

La implementación de Azure Entra ID para la autenticación WiFi requiere la coordinación entre los equipos de identidad, gestión de dispositivos e infraestructura de red.

Paso 1: Establecer la infraestructura de clave pública (PKI)

Debe establecer una CA para emitir certificados de cliente y servidor. En entornos donde la nube es lo primero, suele tratarse de una PKI en la nube integrada con Microsoft Intune a través de SCEP (Simple Certificate Enrolment Protocol).

Paso 2: Configurar el servidor RADIUS

Implemente su infraestructura RADIUS y vincúlela a su inquilino de Entra ID. El servidor RADIUS necesita su propio certificado de servidor - en el que confíen sus dispositivos cliente - para demostrar su identidad durante el saludo de EAP.

Paso 3: Desplegar perfiles de MDM a través de Intune

No dependa de que los usuarios configuren sus ajustes de WiFi manualmente. Utilice Intune para distribuir un perfil de WiFi completo que contenga:

• El certificado de la CA raíz de confianza.
• El perfil SCEP utilizado para solicitar el certificado de cliente.
• La propia configuración de WiFi, definiendo explícitamente el SSID y los nombres de servidor exactos de la infraestructura RADIUS para evitar ataques de tipo Evil Twin.

Paso 4: Configurar el controlador de LAN inalámbrica (WLC)

Configure sus puntos de acceso o WLC para utilizar WPA2/WPA3-Enterprise (802.1X). Dirija el tráfico de autenticación y contabilidad a las nuevas direcciones IP de su servidor RADIUS y configure el secreto compartido de RADIUS.

> "Al configurar 802.1X, asegúrese de que los valores de tiempo de espera de RADIUS en el WLC sean suficientes para la latencia de la validación de certificados en la nube, aumentando normalmente de 2 a 5 segundos". [1]

Buenas prácticas

• Aislar el tráfico corporativo y el de invitados: Los dispositivos corporativos deben utilizar 802.1X vinculado a Entra ID. Los dispositivos de invitados deben utilizar un SSID abierto con un Captive Portal. Para un acceso de invitados y análisis robustos, aproveche una solución de Guest WiFi . Esto garantiza el aislamiento completo del tráfico no seguro.
• Implementar la derivación de autenticación MAC (MAB) con precaución: Los dispositivos IoT y el hardware heredado - como los escáneres más antiguos en los centros de transporte - a menudo no admiten 802.1X. Coloque estos dispositivos en un SSID independiente mediante MAB o una PSK dedicada, y restrinja su acceso a la red con ACL estrictas.
• Priorizar la revocación de certificados: Asegúrese de que sus puntos de conexión de la lista de revocación de certificados (CRL) o del protocolo de estado de certificados en línea (OCSP) estén altamente disponibles. Si el servidor RADIUS no puede verificar el estado de revocación, la autenticación fallará.

Resolución de problemas y mitigación de riesgos

Cuando las implementaciones fallan, rara vez es culpa del IdP en la nube. Los modos de fallo habituales incluyen:

• Desviación del reloj: EAP-TLS es extremadamente sensible al tiempo. Asegúrese de que todos los componentes de la infraestructura - en particular los WLC y los servidores RADIUS - estén sincronizados a través de NTP.
• Latencia de sincronización de Intune: Al registrar nuevos dispositivos, puede haber un retraso entre la emisión del certificado SCEP y el intento de conexión del dispositivo. Tenga en cuenta este retraso durante la incorporación de los usuarios.
• Discrepancia en el nombre del servidor RADIUS: si el nombre del servidor definido en el perfil de WiFi de Intune no coincide exactamente con el Nombre común (CN) o el Nombre alternativo del sujeto (SAN) del certificado del servidor RADIUS, los clientes se desconectarán de forma silenciosa para protegerse contra puntos de acceso maliciosos.

Para un análisis más profundo sobre cómo proteger su infraestructura, consulte nuestra guía sobre cómo proteger su red con DNS y seguridad robustos .

ROI e impacto empresarial

La transición a la autenticación WiFi de Azure Entra ID ofrece importantes beneficios:

1. Reducción del gasto en soporte técnico: la eliminación de la autenticación basada en contraseñas reduce drásticamente los tickets de soporte relacionados con el bloqueo de contraseñas y la renovación de credenciales de WiFi.
2. Cumplimiento acelerado: EAP-TLS proporciona la prueba criptográfica de identidad requerida por marcos como PCI-DSS e ISO 27001, lo cual es esencial en entornos de sanidad y comercio minorista.
3. Bajas automatizadas: cuando un empleado se marcha, la desactivación de su cuenta en Entra ID revoca instantáneamente su acceso a la red en todas las ubicaciones, lo que reduce las amenazas internas.

Al proteger la red corporativa central, los equipos de TI pueden centrarse en iniciativas que generen ingresos, como el uso de analíticas de WiFi con nuestra plataforma de WiFi Analytics para comprender el comportamiento de los visitantes y fomentar la interacción.

Referencias

[1] Microsoft Learn. (2023). Secure Wi-Fi access with Intune and EAP-TLS.