Autenticación WiFi con Azure AD y Entra ID: Guía de integración y configuración

Resumen Ejecutivo

Para las empresas modernas que han apostado fuertemente por el ecosistema de Microsoft, conectar la infraestructura de identidad 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 (AD DS) locales y de Windows Network Policy Server (NPS). Sin embargo, a medida que las organizaciones migran a Microsoft Entra ID (anteriormente Azure AD) y adoptan modelos de seguridad zero-trust, el enfoque tradicional de autenticación basado en credenciales (PEAP-MSCHAPv2) ya no es suficiente ni seguro.

Esta guía proporciona a los responsables de TI, arquitectos de red y directores de operaciones de instalaciones una hoja de ruta práctica para implementar la autenticación WiFi con Azure AD. Exploramos las diferencias arquitectónicas entre mantener una infraestructura NPS local y migrar a una solución RADIUS nativa de la nube. De manera crucial, detallamos cómo aprovechar Microsoft Intune para la autenticación basada en certificados (EAP-TLS), lo que elimina las vulnerabilidades relacionadas con las contraseñas y proporciona una experiencia fluida y sin fricciones para los usuarios finales. Ya sea que gestione un hotel de 500 habitaciones, una cadena de tiendas minoristas o un gran despliegue en el sector público, esta guía le ayudará a proteger su extremo inalámbrico utilizando sus inversiones existentes en identidad de Microsoft. Para un análisis más amplio de los modelos de despliegue, consulte nuestra Guía de decisión para equipos de TI: Cloud RADIUS frente a RADIUS local .

Análisis Técnico Profundo: Arquitectura y Estándares

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. En un entorno centrado en Microsoft, la integración de 802.1X con Entra ID requiere una planificación arquitectónica cuidadosa en tres capas: la infraestructura inalámbrica, el servidor de autenticación y el directorio de identidad.

El papel de RADIUS y 802.1X

Cuando un dispositivo cliente (el suplicante) intenta conectarse a una red WPA2/WPA3-Enterprise, el punto de acceso inalámbrico (el autenticador) bloquea todo el tráfico excepto los paquetes EAP (Extensible Authentication Protocol). El punto de acceso reenvía estos paquetes a un servidor RADIUS. El servidor RADIUS valida la identidad del usuario o dispositivo contra un servicio de directorio y devuelve un mensaje Access-Accept o Access-Reject. Este modelo de tres partes (suplicante, autenticador y servidor de autenticación) es la piedra angular de la seguridad inalámbrica empresarial y se describe en detalle en nuestra Guía definitiva de 2026 sobre la definición de puntos de acceso inalámbricos .

Enfoques arquitectónicos para entornos de Microsoft

Existen dos arquitecturas principales para integrar la identidad de Microsoft con la autenticación WiFi, cada una con sus propias ventajas y desventajas:

Híbrida local (Windows NPS + AD DS + Azure AD Connect): Este es el enfoque tradicional. Windows NPS actúa como el servidor RADIUS, autenticando las solicitudes contra un Active Directory local. Para vincular esto a la nube, Azure AD Connect sincroniza las identidades locales con Entra ID. Aunque es robusto, requiere mantener la infraestructura de servidores locales, gestionar la alta disponibilidad y desplegar una PKI compleja (ADCS) si se implementa EAP-TLS.

Nativa de la nube (Cloud RADIUS + Entra ID + Intune): Este enfoque moderno elimina la necesidad de servidores NPS locales. Un proveedor externo de Cloud RADIUS se integra directamente con Entra ID a través de la Microsoft Graph API. La autenticación se realiza completamente en la nube. Esta arquitectura se alinea con una estrategia cloud-first, reduciendo significativamente la sobrecarga operativa y alineándose con los principios de acceso a la red de confianza cero (zero-trust).

EAP-TLS frente a PEAP-MSCHAPv2: La decisión crítica

La elección del método EAP es la decisión de seguridad más trascendental en este despliegue. PEAP-MSCHAPv2 depende de que los usuarios introduzcan sus credenciales de dominio. Esto es vulnerable al robo de credenciales, a ataques de intermediario (man-in-the-middle) y genera una mala experiencia de usuario cuando las contraseñas caducan. Diversas investigaciones han demostrado sistemáticamente que PEAP-MSCHAPv2 puede verse comprometido mediante ataques de puntos de acceso no autorizados.

EAP-TLS (Transport Layer Security) es el estándar de oro del sector para un WiFi seguro. Utiliza certificados digitales instalados en el dispositivo cliente para la autenticación mutua: tanto el cliente como el servidor demuestran su identidad. No hay que escribir contraseñas y la conexión es criptográficamente sólida. En un entorno de Microsoft, los certificados se suelen desplegar utilizando Microsoft Intune a través de 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 (Requisito 8) y las obligaciones de protección de datos de la GDPR.

Guía de implementación: Despliegue paso a paso

La implementación de la autenticación de Entra ID WiFi mediante EAP-TLS e Intune requiere la coordinación de varios componentes en la infraestructura de identidad, gestión de dispositivos y red. Se recomienda el siguiente enfoque de cinco fases para un despliegue nativo en la nube.

Fase 1: Preparar la infraestructura de gestión de identidades y dispositivos

Comience por verificar que su inquilino de Entra ID dispone de las licencias adecuadas. Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5 incluyen las capacidades de gestión de dispositivos de Intune y de acceso condicional necesarias para este despliegue. Sin Intune, el despliegue automatizado de certificados no es posible.

A continuación, establezca su infraestructura de clave pública (PKI). Dispone de tres opciones: una PKI nativa en la nube proporcionada por su proveedor de Cloud RADIUS, la propia Cloud PKI de Microsoft (disponible con la licencia de Intune Suite) o un despliegue de ADCS local existente conectado a Intune a través del conector de certificados de Microsoft Intune. Para nuevos despliegues, se recomienda encarecidamente una PKI nativa en la nube para evitar dependencias locales.

Fase 2: Configurar Intune para el despliegue de certificados

En el centro de administración de Microsoft Intune, cree un perfil de configuración de Certificado de confianza. Suba el certificado de la CA raíz de su PKI y despliéguelo en sus grupos de dispositivos de destino. Este paso es fundamental: garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el saludo TLS, evitando ataques de intermediario.

A continuación, cree un perfil de Certificado SCEP (o PKCS si su PKI lo requiere). Configure el formato del nombre del sujeto: para la autenticación basada en el usuario, utilice CN={{UserPrincipalName}}; para la autenticación basada en el dispositivo, utilice CN={{DeviceName}} o el número de serie del dispositivo. Configure el nombre alternativo del sujeto (SAN) para que incluya el nombre principal del usuario o el ID del dispositivo. Asigne ambos perfiles a los grupos de usuarios o dispositivos de Entra ID correspondientes.

Fase 3: Configurar la integración de Cloud RADIUS

Otorgue a su proveedor de Cloud RADIUS los permisos necesarios de Microsoft Graph API en su inquilino de Entra ID. Como mínimo, el proveedor requiere User.Read.All y GroupMember.Read.All para validar las pertenencias a grupos durante la autenticación. Algunos proveedores también requieren Device.Read.All para las políticas basadas en dispositivos.

Dentro del portal de gestión de Cloud RADIUS, defina sus políticas de autenticación. Una política bien estructurada para un entorno corporativo podría ser: "Permitir el acceso si el certificado está emitido por [CA de confianza] Y el usuario es miembro del grupo de Entra ID [Corporate-WiFi-Users] Y el dispositivo está marcado como Compliant en Intune." Esta política por capas aplica simultáneamente tanto la identidad como el estado de salud del dispositivo.

Fase 4: Configurar la infraestructura inalámbrica

En su controlador de LAN inalámbrica o panel de gestión en la nube (como Cisco Meraki, Aruba Central o Juniper Mist), añada las direcciones IP y los secretos compartidos del servidor Cloud RADIUS 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 5 segundos para dar margen a la latencia de ida y vuelta de la nube.

Cree un nuevo SSID configurado para WPA2-Enterprise o WPA3-Enterprise. Asigne los servidores RADIUS a este SSID. Para despliegues en el sector de Hostelería , asegúrese de que este SSID corporativo esté en una VLAN separada de cualquier red de invitados. Para entornos de Retail , considere desplegar el SSID corporativo únicamente en las zonas internas, manteniendo separada la red de la zona de ventas.

Fase 5: Desplegar el perfil de WiFi a través de Intune

Cree un perfil de configuración de WiFi en Intune. Establezca el SSID para que coincida exactamente con el que configuró en la infraestructura inalámbrica. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad. En la configuración de EAP, seleccione EAP-TLS como método de autenticación. Vincule el perfil de certificado SCEP como certificado de cliente y especifique el perfil de CA raíz de confianza que desplegó en la Fase 2.

Asigne este perfil de WiFi a los mismos grupos de dispositivos que recibieron los perfiles de certificado. Los dispositivos recibirán de forma silenciosa el certificado y la configuración de WiFi durante su próxima sincronización con Intune, y se conectarán automáticamente cuando estén dentro del alcance del SSID, sin necesidad de interacción por parte del usuario.

Buenas prácticas para entornos empresariales

Las siguientes recomendaciones representan el consenso del sector para despliegues seguros y escalables de Microsoft 802.1X en centros empresariales.

Exija EAP-TLS en todos los nuevos despliegues. No despliegue nuevas redes utilizando PEAP-MSCHAPv2. Los riesgos de seguridad de la WiFi basada en credenciales están ampliamente documentados y son incompatibles con una postura de seguridad de confianza cero (Zero Trust). EAP-TLS es fundamental para el cumplimiento de PCI DSS, GDPR y ISO 27001.

Automate el ciclo de vida de los certificados. Asegúrese de que cuando se deshabilite a un usuario en Entra ID o se retire un dispositivo en Intune, el certificado correspondiente se revoque automáticamente o la política de RADIUS bloquee el acceso de inmediato. Esto es especialmente importante en entornos con alta rotación de personal, como Hospitality y Retail , donde los cambios de plantilla son frecuentes.

Implemente el Acceso condicional de Entra ID. Aproveche las políticas de Acceso condicional para exigir el cumplimiento del dispositivo como condición para el acceso a la red. Requerir que los dispositivos estén marcados como "Conforme" en Intune antes de que puedan autenticarse en RADIUS garantiza que solo los dispositivos parcheados y que cumplan con las políticas accedan a la red corporativa.

Segmente rigurosamente las redes corporativas y de invitados. 802.1X está diseñado para dispositivos corporativos gestionados. Para visitantes, contratistas y BYOD, implemente una solución de Guest WiFi dedicada con un Captive Portal. Esta puede integrarse con Entra ID B2B para el acceso de contratistas, o utilizar inicios de sesión sociales y verificación por SMS para el acceso del público en general. Nunca permita que dispositivos no gestionados accedan al SSID corporativo 802.1X.

Planifique para dispositivos heredados e IoT. Las impresoras, los sensores IoT y los dispositivos heredados que no admiten certificados requieren una estrategia independiente. Utilice la omisión de autenticación MAC (MAB) para dispositivos conocidos, o un SSID WPA2-Personal dedicado con una PSK compleja y rotativa, aislado en una VLAN dedicada. La plataforma Sensors de Purple, por ejemplo, puede funcionar en una VLAN de IoT dedicada, independiente de la infraestructura de autenticación corporativa.

Supervise los eventos de autenticación. Integre los registros de RADIUS con su SIEM o utilice la plataforma WiFi Analytics para supervisar los fallos de autenticación, las advertencias de caducidad de certificados y los patrones de acceso inusuales. La supervisión proactiva evita interrupciones antes de que afecten a las operaciones.

Resolución de problemas y mitigación de riesgos

Incluso las implementaciones bien planificadas presentan problemas. A continuación se detallan los modos de fallo más comunes y sus soluciones.

Fallos en la implementación de certificados. El problema más común en una implementación de EAP-TLS es que los dispositivos no reciben los certificados de Intune. Esto suele deberse a un Intune Certificate Connector mal configurado (si se utiliza ADCS local), a una URL de SCEP incorrecta o a que los dispositivos no se sincronizan con Intune. Verifique siempre el estado del Certificate Connector en el centro de administración de Intune y compruebe los registros de sincronización del dispositivo. Asegúrese de que la cuenta de servicio de SCEP tiene los permisos necesarios en la CA.

Problemas de tiempo de espera (timeout) de RADIUS. Si el punto de acceso no puede comunicarse con el servidor RADIUS dentro del tiempo de espera configurado, los clientes no podrán conectarse. Asegúrese de que las reglas de su cortafuegos permitan los puertos UDP 1812 (autenticación) y 1813 (accounting) de salida hacia los rangos de IP del proveedor de Cloud RADIUS. Si utiliza NPS local, implemente un mínimo de dos servidores NPS y configure sus puntos de acceso para que realicen una conmutación por error entre ellos.

Fallos de confianza en el certificado. Si los clientes reciben un error de "certificado de servidor no confiable", el perfil de CA raíz de confianza no se ha implementado correctamente en el dispositivo. Verifique la asignación del perfil en Intune y compruebe el almacén de certificados del dispositivo. Este es un problema común en dispositivos recién registrados que aún no han completado su primera sincronización con Intune.

Extensión NPS para Azure MFA. Aunque técnicamente es posible utilizar la extensión NPS para aplicar la autenticación multifactor en la red WiFi, se desaconseja encarecidamente para el acceso principal. La experiencia de usuario al recibir una solicitud de MFA cada vez que un dispositivo realiza un roaming entre puntos de acceso es muy molesta. Confíe en la autenticación sólida que proporciona el certificado del dispositivo y aplique la MFA en la capa de aplicación en su lugar.

Conflictos de directivas de grupo. En entornos híbridos, los objetos de directiva de grupo (GPO) que configuran el cliente inalámbrico de Windows pueden entrar en conflicto con los perfiles de WiFi de Intune. Asegúrese de que los perfiles de Intune tengan prioridad revisando la configuración de registro de MDM y, cuando sea necesario, bloqueando la configuración inalámbrica basada en GPO para los dispositivos gestionados por Intune.

ROI e impacto empresarial

La migración a una arquitectura RADIUS nativa de la nube integrada con Entra ID ofrece un valor medible y cuantificable en varios aspectos.

Reducción de tickets de soporte. Los problemas de WiFi relacionados con las contraseñas (bloqueos, contraseñas caducadas, suplicantes mal configurados) son una fuente importante de tickets de soporte de TI en entornos basados en credenciales. EAP-TLS los elimina por completo. Las organizaciones suelen registrar una reducción del 30 al 50 % en el volumen de soporte técnico relacionado con el WiFi tras la migración a la autenticación basada en certificados.

Ahorro en costes de infraestructura. El desmantelamiento de los servidores NPS locales reduce los costes de computación, las tarifas de licencia del sistema operativo y los gastos operativos de parchear y mantener clústeres de alta disponibilidad. Para una organización mediana que ejecute dos servidores NPS, esto puede representar un ahorro de entre 15 000 y 30 000 libras al año en costes operativos y de infraestructura.

Mejora de la seguridad y el cumplimiento. Abandonar la autenticación basada en credenciales mitiga el riesgo de robo de credenciales y movimiento lateral, protegiendo los datos corporativos confidenciales. Para las organizaciones sujetas a PCI DSS, esto aborda directamente los requisitos de control de acceso a la red. Para las organizaciones de Sanidad que gestionan datos de pacientes, respalda el cumplimiento de DSPT. Para los operadores de Transporte , se alinea con los requisitos de la Directiva NIS2 para la seguridad de las redes.

Experiencia de usuario mejorada. La conexión WiFi automática y fluida (sin solicitudes de contraseña, sin bloqueos y sin configuración manual) mejora la productividad y reduce las fricciones para el personal. Esto es especialmente importante en entornos de alta movilidad, como centros de distribución, salas de hospitales y tiendas minoristas. Al tratar su red WiFi como una extensión de su estrategia de identidad en la nube, garantiza un acceso seguro y sin fricciones que se escala con su organización. Para obtener más orientación sobre los aspectos de integración de SD-WAN en las redes empresariales modernas, consulte The Core SD-WAN Benefits for Modern Businesses . Para consideraciones de despliegue específicas del sector hotelero, consulte Modern Hospitality WiFi Solutions Your Guests Deserve .