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

Resumen Ejecutivo

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

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 compatibles puedan acceder a las VLANs corporativas críticas. Analizamos la arquitectura técnica, los pasos de implementación y cómo este nivel de seguridad empresarial opera 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, el WiFi empresarial dependía de PEAP-MSCHAPv2, que requiere que los usuarios ingresen sus credenciales de dominio. Sin embargo, debido a su susceptibilidad a los ataques de adversario en el medio (AiTM), Microsoft está desaconsejando activamente la autenticación basada en credenciales. El estándar actual de la industria 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 Autoridad 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 Arquitectónico: RADIUS y Microsoft Entra ID

Microsoft Entra ID es un proveedor de identidad (IdP) en la nube que utiliza protocolos modernos como SAML y OIDC; no se comunica de forma nativa con el protocolo RADIUS utilizado por los puntos de acceso inalámbrico (WAPs). Para cerrar esta brecha, los arquitectos de red deben implementar un servidor RADIUS capaz de comunicarse con Microsoft Entra ID. Esto se logra 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 APIs.
2. Servidor de Políticas de Red (NPS) local: Utilizando la extensión Azure MFA, aunque esto se considera cada vez más como un enfoque heredado en comparación con un RADIUS nativo de la nube.

Guía de implementación

Implementar Microsoft Entra ID para la autenticación de WiFi requiere de la coordinación entre los equipos de identidad, administració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 prioridad, esto suele ser una PKI en la nube integrada con Microsoft Intune a través del protocolo SCEP (Simple Certificate Enrolment Protocol).

Paso 2: Configurar el servidor RADIUS

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

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

No dependa de que los usuarios configuren sus ajustes de WiFi de forma manual. Utilice Intune para enviar un perfil de WiFi completo que contenga:

• El certificado CA raíz de confianza.
• El perfil SCEP utilizado para solicitar el certificado de cliente.
• La configuración de WiFi en sí, 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 establezca 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, aumentándolos habitualmente de 2 a 5 segundos". [1]

Mejores prácticas

• Aislar el tráfico corporativo y de invitados: Los dispositivos corporativos deben usar 802.1X vinculado a Microsoft Entra ID. Los dispositivos de invitados deben usar un SSID abierto con un Captive Portal. Para un acceso de invitados y análisis de datos robustos, aproveche una solución de Guest WiFi . Esto garantiza el aislamiento completo del tráfico no confiable.
• Implementar la omisió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 transport - a menudo no admiten 802.1X. Coloque estos dispositivos en un SSID separado 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 finales de la Lista de revocación de certificados (CRL) o del Protocolo de estado de certificado en línea (OCSP) estén altamente disponibles. Si el servidor RADIUS no puede verificar el estado de revocación, la autenticación fallará.

Solución de problemas y mitigación de riesgos

Cuando las implementaciones fallan, rara vez se debe a un fallo del IdP en la nube. Los modos de fallo comunes incluyen:

• Desviación del reloj: EAP-TLS es extremadamente sensible al tiempo. Asegúrese de que todos los componentes de la infraestructura - especialmente 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. Planifique este retraso durante el proceso de incorporación.
• 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) en el certificado del servidor RADIUS, los clientes se desconectarán de forma silenciosa para protegerse contra AP maliciosos.

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

ROI e impacto empresarial

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

1. Reducción del gasto en soporte técnico: eliminar la autenticación basada en contraseñas reduce drásticamente los tickets de soporte relacionados con bloqueos de contraseñas y renovaciones de credenciales de WiFi.
2. Cumplimiento acelerado: EAP-TLS proporciona la prueba criptográfica de identidad requerida por marcos de trabajo como PCI-DSS e ISO 27001, lo cual es esencial en entornos de atención médica y retail.
3. Bajas automatizadas: cuando un empleado se va, deshabilitar su cuenta en Entra ID revoca instantáneamente su acceso a la red en todas las ubicaciones, reduciendo la amenaza interna.

Al proteger la red central corporativa, los equipos de TI pueden enfocarse en iniciativas que generen ingresos, como el uso de WiFi Analytics para comprender el comportamiento de los visitantes e impulsar la interacción.

Referencias

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