Saltar al contenido principal

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

Esta guía autorizada detalla la arquitectura, los pasos de implementación y el impacto empresarial de integrar Azure Entra ID con 802.1X para la autenticación WiFi empresarial. Proporciona a los arquitectos de red y directores de TI estrategias prácticas de despliegue, sustituyendo las PSK heredadas por un acceso a la red basado en certificados y de confianza cero (zero-trust).

📖 4 min de lectura📝 945 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 8 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
[INTRO - 1 MIN] Host: Bienvenido al Purple Enterprise Network Briefing. Soy su anfitrión, y hoy abordamos una actualización de infraestructura crítica que es prioritaria para los CTO y arquitectos de red: migrar la autenticación de su WiFi corporativo a Azure Entra ID (anteriormente Azure AD). Si gestiona una cadena de hoteles, un estadio o un despliegue a gran escala en el sector público, conoce el dolor de cabeza que suponen los servidores RADIUS locales heredados y las PSK compartidas. Hoy hablaremos del acceso a la red de confianza cero (zero-trust), específicamente de cómo implementar la autenticación basada en certificados 802.1X utilizando Azure Entra ID. Sin rodeos, solo la realidad técnica de cómo desplegarlo. [TECHNICAL DEEP-DIVE - 5 MIN] Host: Vayamos directos a la arquitectura. Los días de WPA2-Personal con una contraseña compartida en una nota adhesiva han terminado. En una empresa moderna, ya sea para proteger las operaciones internas en un entorno minorista o las redes del personal en un hospital, se necesita un acceso basado en la identidad. Cuando hablamos de Azure Entra ID para WiFi, nos referimos fundamentalmente a EAP-TLS. Es decir, Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte. Es el estándar de oro. ¿Por qué? Porque se basa en certificados, no en contraseñas. Las contraseñas se pueden pescar (phishing), compartir o descifrar por fuerza bruta. Los certificados vinculados a un dispositivo gestionado a través de Intune, no. Entonces, ¿cómo fluye el tráfico? Un dispositivo corporativo (por ejemplo, un portátil gestionado) intenta conectarse al SSID corporativo. El punto de acceso inalámbrico, que actúa como autenticador, bloquea el acceso y pasa las credenciales a través de RADIUS a su servidor de autenticación. Ahora bien, Azure Entra ID no habla RADIUS de forma nativa. Este es el puente arquitectónico crítico. Necesita un proveedor de RADIUS en la nube o un Servidor de Políticas de Red (NPS) local con la extensión Azure MFA. El dispositivo presenta su certificado de cliente. El servidor RADIUS valida ese certificado contra su Autoridad de Certificación (CA), a menudo gestionada a través de SCEP en Intune. Si el certificado es válido, el servidor RADIUS comprueba Azure Entra ID para asegurarse de que la cuenta de usuario está activa, no deshabilitada, y cumple con las políticas de Acceso Condicional. Solo entonces el servidor RADIUS envía un mensaje de Access-Accept de vuelta al AP, colocando al usuario en la VLAN correcta. [IMPLEMENTATION RECOMMENDATIONS & PITFALLS - 2 MIN] Host: Ahora, ¿dónde suelen fallar los despliegues? Veo tres errores comunes. Primero: la disponibilidad de la Lista de Revocación de Certificados (CRL). Si su servidor RADIUS no puede acceder a la CRL, la autenticación falla. Asegúrese de que sus endpoints de CRL sean de alta disponibilidad y accesibles desde la infraestructura RADIUS. Segundo: la configuración del suplicante. No deje esto en manos del usuario final. Utilice su MDM (Microsoft Intune, Workspace ONE, el que sea que use) para insertar el perfil de WiFi. El perfil debe definir explícitamente la CA raíz de confianza y especificar que el cliente solo debe conectarse a sus nombres de servidor RADIUS específicos. Si no hace esto, será vulnerable a ataques de tipo Evil Twin. Tercero: Dispositivos heredados. Los dispositivos IoT, los terminales de punto de venta o los escáneres de códigos de barras más antiguos de un almacén a menudo no son compatibles con 802.1X o EAP-TLS. Debe planificar una estrategia de MAC Authentication Bypass (MAB) o una red dedicada con clave precompartida con un aislamiento de red estricto para estos dispositivos. No comprometa su SSID corporativo principal por una impresora heredada. [PREGUNTAS Y RESPUESTAS RÁPIDAS - 1 MIN] Presentador: Vamos con algunas preguntas rápidas que solemos escuchar de los arquitectos de red. Pregunta uno: ¿Podemos usar PEAP-MSCHAPv2 con Azure Entra ID? Respuesta: Sí, a través de NPS, pero Microsoft está desbancando activamente la autenticación basada en credenciales. Cambie a EAP-TLS. Es más seguro y ofrece una mejor experiencia de usuario. Pregunta dos: ¿Cómo se integra esto con el WiFi para invitados de Purple? Respuesta: Manténgalos separados. Su red corporativa utiliza 802.1X vinculado a Azure Entra ID. Su red de invitados utiliza un SSID abierto con un Captive Portal gestionado por Purple para analíticas, aceptación de términos y captura de datos de marketing. Incluso puede utilizar la autenticación basada en perfiles de Purple para visitas de invitados recurrentes sin interrupciones, manteniendo ese tráfico completamente aislado de sus datos corporativos. [RESUMEN Y PRÓXIMOS PASOS - 1 MIN] Presentador: Para resumir: Migrar a Azure Entra ID para la autenticación WiFi es un paso fundamental hacia una arquitectura zero-trust. Elimina los tickets de soporte para el restablecimiento de contraseñas, mitiga el robo de credenciales y garantiza que solo los dispositivos gestionados y conformes accedan a su red interna. ¿Su próximo paso? Audite su infraestructura RADIUS actual. Si ejecuta un NPS heredado de forma local, evalúe soluciones RADIUS en la nube que se integren directamente con Azure Entra ID e Intune. Planifique su estrategia de despliegue de certificados. Gracias por asistir a esta sesión técnica. Proteja sus redes y nos vemos la próxima vez.

header_image.png

Resumen Ejecutivo

Para los CTO y arquitectos de red que gestionan entornos complejos —desde espacios de Hostelería a gran escala hasta entornos dinámicos de Retail — proteger la red corporativa ya no es solo cuestión de contraseñas seguras. Las claves precompartidas (PSK) heredadas y la autenticación básica mediante credenciales son fundamentalmente incompatibles con las arquitecturas modernas de confianza cero (Zero Trust).

Esta guía detalla la transición a la autenticación WiFi basada en certificados 802.1X integrada directamente con Azure Entra ID (anteriormente Azure AD). Al migrar a EAP-TLS (Protocolo de autenticación extensible con seguridad de la capa de transporte), las organizaciones pueden eliminar los riesgos asociados al robo de credenciales, automatizar la incorporación 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 críticas. Analizaremos la arquitectura técnica, los pasos de implementación y cómo este enfoque de seguridad corporativa coexiste con las estrategias de redes de invitados gestionadas por plataformas como Purple.

Análisis Técnico Detallado

El paso de las credenciales a los certificados

Históricamente, el WiFi empresarial dependía de PEAP-MSCHAPv2, lo que requería que los usuarios introdujeran sus credenciales de dominio. Sin embargo, Microsoft está dejando de admitir activamente la autenticación basada en credenciales debido a su vulnerabilidad a los ataques de intermediario (AiTM). El estándar del sector es ahora EAP-TLS, que utiliza la autenticación mutua mediante 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 antes incluso de que el dispositivo obtenga una dirección IP.

architecture_overview.png

El puente arquitectónico: RADIUS y Entra ID

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

  1. Soluciones RADIUS en la nube: Plataformas diseñadas específicamente (por ejemplo, SecureW2, SCEPman o Portnox) que se integran directamente con Entra ID e Intune a través de 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 RADIUS nativo de la nube.

eap_comparison_chart.png

Guía de Implementación

La implementación de Azure Entra ID para la autenticación de 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 un entorno que prioriza la nube, a menudo se trata de una PKI en la nube integrada con Microsoft Intune a través del Protocolo de inscripción de certificados simple (SCEP).

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

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

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

  • El certificado de la CA raíz de confianza.
  • El perfil SCEP para solicitar el certificado de cliente.
  • La propia configuración de WiFi, definiendo explícitamente el SSID y los nombres de servidor exactos de su 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 los secretos compartidos de RADIUS.

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

Buenas prácticas

  • Separar 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 las soluciones de Guest WiFi . Esto garantiza el aislamiento completo del tráfico no confiable.
  • Implementar la omisión de autenticación MAC (MAB) con cuidado: Los dispositivos IoT y el hardware heredado (por ejemplo, escáneres antiguos en centros de Transporte ) a menudo no son compatibles con 802.1X. Colóquelos en un SSID independiente utilizando MAB o una PSK dedicada, y restrinja su acceso a la red mediante 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 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á.

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 comunes incluyen:

  • Desviación del reloj: EAP-TLS es muy sensible al tiempo. Asegúrese de que todos los componentes de la infraestructura, especialmente el WLC y los servidores RADIUS, estén sincronizados a través de NTP.
  • Retrasos de sincronización de Intune: Cuando se registra un nuevo dispositivo, puede pasar algún tiempo antes de que se emita el certificado SCEP y el dispositivo intente conectarse. Planifique esta latencia durante la incorporación.- Radius Server Name Mismatch: Si el nombre del servidor definido en el perfil de WiFi de Intune no coincide exactamente con el Common Name (CN) o el Subject Alternative Name (SAN) del certificado del servidor RADIUS, el cliente interrumpirá la conexión de forma silenciosa para protegerse contra AP no autorizados.

Para obtener más información 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 un retorno de la inversión medible:

  1. Reducción de la carga de trabajo de soporte técnico: Al eliminar la autenticación basada en contraseñas, se reducen drásticamente los tickets relacionados con el bloqueo de contraseñas y las actualizaciones de credenciales de WiFi.
  2. Aceleración del cumplimiento normativo: EAP-TLS proporciona la prueba criptográfica de identidad requerida por marcos como PCI DSS e ISO 27001, algo crucial para entornos de Sanidad y comercio minorista.
  3. Bajas automatizadas: Cuando un empleado se marcha, al desactivar su cuenta en Entra ID se revoca inmediatamente su acceso a la red en todas las ubicaciones, mitigando las amenazas internas.

Al proteger la infraestructura corporativa principal, los equipos de TI pueden centrarse en iniciativas que generen ingresos, como aprovechar 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.

Definiciones clave

802.1X

Un estándar IEEE para el control de acceso a la red basado en puertos, que requiere que los dispositivos se autentiquen antes de obtener acceso a la LAN o WLAN.

Este es el protocolo subyacente que hace que el WiFi empresarial sea seguro, yendo más allá de las simples contraseñas compartidas.

EAP-TLS

Protocolo de autenticación extensible con seguridad de la capa de transporte. Un método de autenticación que requiere certificados digitales tanto en el cliente como en el servidor.

Considerado el método más seguro para la autenticación WiFi, evitando el robo de credenciales y los ataques de tipo AiTM (Adversary-in-the-Middle).

RADIUS

Servicio de usuario de marcación de autenticación remota. Un protocolo de red que proporciona autenticación, autorización y contabilidad (AAA) centralizadas.

El protocolo que utilizan sus puntos de acceso para preguntar al servidor de autenticación: "¿Debo permitir que este dispositivo acceda a la red?"

SCEP

Protocolo simple de inscripción de certificados. Un protocolo utilizado para emitir certificados de forma segura a dispositivos de red.

Utilizado por plataformas MDM como Intune para solicitar e instalar de forma silenciosa certificados de cliente en portátiles y teléfonos corporativos.

MAC Authentication Bypass (MAB)

Un método para conceder acceso a la red basado en la dirección MAC del dispositivo en lugar de en un nombre de usuario o certificado.

Utilizado como alternativa para dispositivos heredados (como impresoras antiguas o sensores IoT) que carecen del software para realizar un protocolo de enlace 802.1X.

Evil Twin Attack

Un punto de acceso no autorizado que se hace pasar por un SSID corporativo legítimo para interceptar el tráfico o robar credenciales.

EAP-TLS mitiga esto porque el dispositivo cliente está configurado para confiar únicamente en el certificado específico del servidor RADIUS corporativo legítimo.

Supplicant

El cliente de software en el dispositivo final (por ejemplo, el administrador de WiFi de Windows) que gestiona el proceso de autenticación 802.1X.

Los equipos de TI deben configurar el suplicante a través de MDM para garantizar que se comporte de forma segura y no pida a los usuarios que acepten certificados de servidor no confiables.

Conditional Access

Políticas de Azure Entra ID que evalúan señales (usuario, ubicación, conformidad del dispositivo) para tomar decisiones de acceso.

Las soluciones modernas de Cloud RADIUS pueden comprobar el Acceso Condicional durante el protocolo de enlace WiFi, denegando el acceso a la red si Intune marca el dispositivo como no conforme.

Ejemplos prácticos

Una cadena minorista con 500 establecimientos necesita proteger los iPads de la trastienda utilizados para la gestión de inventario. Actualmente, utilizan una única PSK compartida en todas las tiendas. ¿Cómo deberían migrar a la autenticación de Azure Entra ID?

  1. Registrar todos los iPads en Microsoft Intune.
  2. Desplegar una solución Cloud RADIUS integrada con el inquilino corporativo de Entra ID.
  3. Configurar Intune para desplegar un certificado SCEP en cada iPad.
  4. Insertar un perfil de WiFi a través de Intune que configure los iPads para conectarse al SSID "Corporate-BOH" mediante EAP-TLS, validando el certificado del servidor Cloud RADIUS.
  5. Actualizar los puntos de acceso Meraki/Aruba en las 500 tiendas para que apunten a las direcciones IP de Cloud RADIUS para el SSID "Corporate-BOH".
  6. Despliegue gradual: habilitar el nuevo SSID, verificar la conectividad de los iPads a través de los informes de Intune y, a continuación, retirar el SSID con la PSK heredada.
Comentario del examinador: Este enfoque elimina la PSK compartida, que representa un riesgo de seguridad masivo si se roba un dispositivo. Al utilizar EAP-TLS e Intune, la autenticación queda vinculada al estado de gestión del dispositivo. Si se pierde un iPad, el equipo de TI simplemente revoca el certificado o borra el dispositivo en Intune, cortando instantáneamente el acceso a la red sin afectar a las otras 499 tiendas.

El campus de una universidad está migrando de Active Directory local a Azure Entra ID. Tienen miles de portátiles de estudiantes BYOD (Bring Your Own Device) que actualmente se conectan mediante PEAP-MSCHAPv2 (usuario y contraseña). ¿Cómo gestionan el BYOD en un entorno Entra ID centrado en la nube?

  1. Desplegar un portal de incorporación (por ejemplo, SecureW2 JoinNow o una herramienta de incorporación BYOD similar).
  2. Los estudiantes se conectan a un SSID de "Incorporación" abierto, que los redirige al portal.
  3. El portal solicita al estudiante que se autentique en Azure Entra ID (utilizando su correo electrónico universitario y MFA).
  4. Tras una autenticación correcta, el portal genera un certificado de cliente único y configura automáticamente el dispositivo del estudiante para EAP-TLS.
  5. El dispositivo se conecta automáticamente al SSID seguro "Edu-Secure" utilizando el nuevo certificado.
Comentario del examinador: La gestión de certificados para dispositivos BYOD no gestionados es la parte más difícil de 802.1X. No se puede utilizar Intune porque la universidad no es propietaria de los portátiles. El uso de un portal de incorporación salva esta distancia, permitiendo el uso de un EAP-TLS seguro sin necesidad de que el departamento de TI intervenga manualmente en miles de portátiles de estudiantes.

Preguntas de práctica

Q1. Su organización está migrando a Azure Entra ID e Intune. Actualmente utiliza PEAP-MSCHAPv2 para WiFi. El equipo de seguridad exige que la autenticación WiFi sea resistente al robo de credenciales. ¿Qué método EAP debería implementar?

Sugerencia: ¿Qué método se basa completamente en certificados en lugar de contraseñas?

Ver respuesta modelo

Debería implementar EAP-TLS. EAP-TLS utiliza autenticación mutua mediante certificados, lo que significa que el dispositivo cliente debe presentar un certificado válido emitido por su PKI. Al no utilizar contraseñas, es altamente resistente al robo de credenciales y a los ataques de tipo adversary-in-the-middle.

Q2. Después de implementar EAP-TLS a través de Intune, los usuarios informan que no pueden conectarse a la WiFi. Al revisar los registros de RADIUS, observa el error "Certificate Revocation Check Failed". ¿Cuál es la causa más probable?

Sugerencia: ¿Con qué infraestructura debe comunicarse el servidor RADIUS para verificar que un certificado no ha sido comprometido?

Ver respuesta modelo

El servidor RADIUS no puede comunicarse con la Lista de Revocación de Certificados (CRL) o el endpoint OCSP de su Entidad Certificadora. Asegúrese de que los firewalls permitan al servidor RADIUS el acceso saliente a las URL HTTP especificadas en los certificados de cliente.

Q3. Un hospital necesita conectar 50 monitores de ritmo cardíaco antiguos a la red. Estos dispositivos solo admiten WPA2-Personal (clave precompartida) y no se pueden registrar en Intune. ¿Cómo debería protegerlos mientras mantiene su implementación de Entra ID 802.1X para los portátiles corporativos?

Sugerencia: No mezcle tipos de autenticación en el mismo SSID.

Ver respuesta modelo

Cree un SSID dedicado y separado específicamente para los dispositivos IoT médicos. Utilice una clave precompartida sólida y única (o Identity PSK/iPSK si lo admite su proveedor de red) o MAC Authentication Bypass (MAB). Es fundamental ubicar este SSID en una VLAN altamente restringida con Listas de Control de Acceso (ACL) estrictas que solo permitan a los monitores comunicarse con su servidor médico específico, bloqueando cualquier otro acceso lateral a la red.

Continúe leyendo esta serie

PSK por dispositivo según el fabricante: comparación de iPSK, DPSK, MPSK y PPSK (y compatibilidad con WPA3)

Una comparación exhaustiva de las implementaciones de PSK por dispositivo en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet y Ubiquiti UniFi. Descubra cómo afecta WPA3-SAE a las estrategias de claves por dispositivo y cuándo implementar modos de transición en lugar de migrar a 802.1X.

Leer la guía →

Comparativa de métodos de autenticación de Captive Portal

Esta guía de referencia técnica autorizada evalúa las ventajas y desventajas arquitectónicas, operativas y de cumplimiento de cinco métodos principales de autenticación de Captive Portal. Proporciona a los arquitectos de red, directores de TI y directores de marketing los datos cuantitativos y los marcos de decisión necesarios para equilibrar la fricción en el registro de invitados con los requisitos de recopilación de datos en los recintos empresariales.

Leer la guía →

¿Qué es la autenticación por dirección MAC? Cuándo usarla y cuándo evitarla

Esta guía de referencia técnica autorizada aborda la autenticación por dirección MAC en entornos WiFi empresariales: cómo funciona la autenticación MAC basada en RADIUS en la Capa 2, sus vulnerabilidades de seguridad inherentes (incluido el spoofing de MAC y el impacto de la aleatorización de MAC a nivel de sistema operativo) y los contextos operativos precisos donde sigue siendo una herramienta válida para gestionar dispositivos IoT y headless. Proporciona orientación de despliegue práctica para responsables de TI y arquitectos de red en sectores como hostelería, retail, sanidad y espacios públicos, con ejemplos prácticos reales, marcos de decisión y contexto de integración para la plataforma de analítica y WiFi de invitados de Purple.

Leer la guía →