Azure AD and Entra ID WiFi Authentication: Integration and Configuration Guide
Esta guía de referencia técnica proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de establecimientos una hoja de ruta práctica para integrar Microsoft Entra ID (Azure AD) con redes WiFi empresariales utilizando RADIUS y 802.1X. Cubre la decisión arquitectónica entre Windows NPS local y RADIUS nativo de la nube, el despliegue de autenticación EAP-TLS basada en certificados a través de Microsoft Intune, y las mejores prácticas operativas para asegurar el acceso inalámbrico en entornos de hotelería, retail y sector público. Para las organizaciones que ya han invertido en el ecosistema de Microsoft 365 y Entra ID, esta guía cierra la brecha entre la gestión de identidad en la nube y la seguridad de la red física.
Resumen Ejecutivo
Para las empresas modernas que han invertido fuertemente en 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 de 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 gerentes de TI, arquitectos de redes y directores de operaciones de establecimientos una hoja de ruta práctica para implementar la autenticación de 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 brinda una experiencia fluida y sin fricciones para los usuarios finales. Ya sea que administre un hotel de 500 habitaciones, una cadena de tiendas minoristas o un despliegue a gran escala en el sector público, esta guía le ayudará a proteger su entorno 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 vs RADIUS local .
Análisis Técnico Profundo: Arquitectura y Estándares
La base de un WiFi empresarial seguro 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 Rol 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 (Protocolo de Autenticación Extensible). El punto de acceso reenvía estos paquetes a un servidor RADIUS. El servidor RADIUS valida la identidad del usuario o dispositivo frente a un servicio de directorio y devuelve un mensaje Access-Accept o Access-Reject. Este modelo de tres partes (suplicante, autenticador, servidor de autenticación) es la piedra angular de la seguridad inalámbrica empresarial y se describe en detalle en nuestra Guía Definitiva 2026 sobre Puntos de Acceso Inalámbricos .
Enfoques Arquitectónicos para Entornos Microsoft
Existen dos arquitecturas principales para integrar la identidad de Microsoft con la autenticación WiFi, cada una con distintas ventajas y desventajas:
| Dimensión | Híbrida Local (NPS) | Nativa en la Nube (Cloud RADIUS) |
|---|---|---|
| Infraestructura | Requiere VM de Windows Server o hardware dedicado | Sin servidores locales |
| Origen de Identidad | AD DS a través de LDAP/Kerberos | Entra ID directamente a través de API |
| Autoridad de Certificación | ADCS local + Intune Connector | Intune Cloud PKI o PKI del proveedor |
| Escalabilidad | Balanceo de carga/HA manual | Escalado automático por el proveedor |
| Ideal Para | AD híbrido, dispositivos heredados | Organizaciones cloud-first gestionadas por Intune |
| Complejidad Operativa | Mayor complejidad inicial y continua | Menor sobrecarga operativa |
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 en 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 API de Microsoft Graph. La autenticación ocurre 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 zero-trust.
EAP-TLS vs. PEAP-MSCHAPv2: La Decisión Crítica
La elección del método EAP es la decisión de seguridad más importante en este despliegue. PEAP-MSCHAPv2 depende de que los usuarios ingresen sus credenciales de dominio. Esto es vulnerable al robo de credenciales, ataques de intermediario (man-in-the-middle) y genera una mala experiencia de usuario cuando las contraseñas expiran. Las investigaciones han demostrado consistentemente que PEAP-MSCHAPv2 puede verse comprometido a través de ataques de puntos de acceso no autorizados.
EAP-TLS (Transport Layer Security) es el estándar de oro de la industria 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 contraseñas que escribir y la conexión es criptográficamente sólida. En un entorno de Microsoft, los certificados se despliegan normalmente utilizando Microsoft Intune a través de SCEP (Simple Certificate Enrollment Protocol) o PKCS. Este es el camino recomendado 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 utilizando EAP-TLS e Intune requiere coordinar varios componentes a través de la identidad, la gestión de dispositivos y la infraestructura de red. Se recomienda el siguiente enfoque de cinco fases para un despliegue nativo de la nube.
Fase 1: Preparar la Infraestructura de Gestión de Identidades y Dispositivos
Comience verificando que su inquilino de Entra ID tenga las licencias adecuadas. Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5 incluye la gestión de dispositivos de Intune y las capacidades de Acceso Condicional requeridas para este despliegue. Sin Intune, el despliegue automatizado de certificados no es posible.
A continuación, establezca su Infraestructura de Clave Pública (PKI). Tiene tres opciones: una PKI nativa de 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 Microsoft Intune Certificate Connector. Para nuevos despliegues, se recomienda encarecidamente una PKI nativa de 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 (Trusted Certificate). Cargue el certificado de la CA Raíz de su PKI y despliéguelo en sus grupos de dispositivos de destino. Este paso es crítico: garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el saludo TLS, evitando ataques de intermediario.
Luego, cree un perfil de Certificado SCEP (o PKCS si su PKI lo requiere). Configure el formato del Nombre del Sujeto (Subject Name): para la autenticación basada en el usuario, use CN={{UserPrincipalName}}; para la autenticación basada en el dispositivo, use CN={{DeviceName}} o el número de serie del dispositivo. Configure el Nombre Alternativo del Sujeto (SAN) para incluir el Nombre Principal del Usuario o el ID del dispositivo. Asigne ambos perfiles a los grupos de usuarios o dispositivos de Entra ID correspondientes.
Phase 3: Configure the Cloud RADIUS Integration
Grant your Cloud RADIUS provider the necessary Microsoft Graph API permissions in your Entra ID tenant. At minimum, the provider requires User.Read.All and GroupMember.Read.All to validate group memberships during authentication. Some providers also require Device.Read.All for device-based policies.
Within the Cloud RADIUS management portal, define your authentication policies. A well-structured policy for a corporate environment might read: "Allow access if the certificate is issued by [Trusted CA] AND the user is a member of the [Corporate-WiFi-Users] Entra ID group AND the device is marked Compliant in Intune." This layered policy enforces both identity and device health simultaneously.
Phase 4: Configure the Wireless Infrastructure
In your wireless LAN controller or cloud management dashboard (such as Cisco Meraki, Aruba Central, or Juniper Mist), add the Cloud RADIUS server IP addresses and shared secrets as RADIUS authentication servers. Configure primary and secondary servers for redundancy. Set the RADIUS timeout to a minimum of 5 seconds to accommodate cloud round-trip latency.
Create a new SSID configured for WPA2-Enterprise or WPA3-Enterprise. Assign the RADIUS servers to this SSID. For Hospitality deployments, ensure this corporate SSID is on a separate VLAN from any guest network. For Retail environments, consider deploying the corporate SSID only in back-of-house areas, keeping the sales floor network separate.
Phase 5: Deploy the WiFi Profile via Intune
Create a WiFi configuration profile in Intune. Set the SSID to match exactly what you configured on the wireless infrastructure. Select WPA2-Enterprise or WPA3-Enterprise as the security type. Under EAP settings, select EAP-TLS as the authentication method. Link the SCEP certificate profile as the client certificate and specify the Trusted Root CA profile you deployed in Phase 2.
Assign this WiFi profile to the same device groups that received the certificate profiles. Devices will silently receive the certificate and the WiFi configuration during their next Intune sync, and will connect automatically when in range of the SSID — with no user interaction required.
Best Practices for Enterprise Environments
The following recommendations represent the industry consensus for secure, scalable Microsoft 802.1X deployments across enterprise venues.
Mandate EAP-TLS across all new deployments. Do not deploy new networks using PEAP-MSCHAPv2. The security risks of credential-based WiFi are well-documented and incompatible with a zero-trust security posture. EAP-TLS is essential for compliance with PCI DSS, GDPR, and ISO 27001.
Automate the certificate lifecycle. Ensure that when a user is disabled in Entra ID or a device is retired in Intune, the corresponding certificate is automatically revoked or the RADIUS policy immediately blocks access. This is particularly important in high-turnover environments such as Hospitality and Retail , where staff changes are frequent.
Implement Entra ID Conditional Access. Leverage Conditional Access policies to enforce device compliance as a condition of network access. Requiring devices to be marked 'Compliant' in Intune before they can authenticate to RADIUS ensures that only patched, policy-compliant devices access the corporate network.
Segment corporate and guest networks rigorously. 802.1X is designed for managed corporate devices. For visitors, contractors, and BYOD, implement a dedicated Guest WiFi solution with a captive portal. This can integrate with Entra ID B2B for contractor access, or use social logins and SMS verification for general public access. Never allow unmanaged devices onto the corporate 802.1X SSID.
Plan for legacy and IoT devices. Printers, IoT sensors, and legacy devices that cannot support certificates require a separate strategy. Use MAC Authentication Bypass (MAB) for known devices, or a dedicated WPA2-Personal SSID with a complex, rotated PSK, isolated on a dedicated VLAN. Purple's Sensors platform, for example, can operate on a dedicated IoT VLAN separate from the corporate authentication infrastructure.
Monitor authentication events. Integrate RADIUS logs with your SIEM or use the WiFi Analytics platform to monitor authentication failures, certificate expiry warnings, and unusual access patterns. Proactive monitoring prevents outages before they impact operations.
Troubleshooting & Risk Mitigation
Even well-planned deployments encounter issues. The following are the most common failure modes and their resolutions.
Certificate Deployment Failures. The most common issue in an EAP-TLS deployment is devices failing to receive certificates from Intune. This is typically caused by a misconfigured Intune Certificate Connector (if using on-premise ADCS), incorrect SCEP URL, or devices not syncing with Intune. Always verify the Certificate Connector status in the Intune admin center and check the device sync logs. Ensure the SCEP service account has the necessary permissions on the CA.
RADIUS Timeout Issues. If the access point cannot reach the RADIUS server within the configured timeout, clients will fail to connect. Ensure your firewall rules allow UDP ports 1812 (authentication) and 1813 (accounting) outbound to the Cloud RADIUS provider's IP ranges. If using on-premise NPS, deploy a minimum of two NPS servers and configure your access points to failover between them.
Fallas de confianza en el certificado. Si los clientes reciben un error de "certificado de servidor no confiable", el perfil de CA raíz confiable no se ha implementado correctamente en el dispositivo. Verifique la asignación del perfil en Intune y revise el almacén de certificados del dispositivo. Este es un problema común con los dispositivos recién inscritos 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 para WiFi, se desaconseja firmemente para el acceso principal. La experiencia del usuario al recibir una solicitud de MFA cada vez que un dispositivo realiza roaming entre puntos de acceso es sumamente disruptiva. Confíe en la autenticación sólida que proporciona el certificado del dispositivo y, en su lugar, aplique MFA en la capa de aplicación.
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 inscripción de MDM y, cuando sea necesario, bloqueando la configuración inalámbrica basada en GPO para los dispositivos administrados por Intune.
ROI e impacto empresarial
Migrar a una arquitectura RADIUS nativa de la nube integrada con Entra ID ofrece un valor medible y cuantificable en varias dimensiones.
Reducción de tickets de soporte. Los problemas de WiFi relacionados con 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 elimina esto por completo. Las organizaciones suelen reportar una reducción del 30 al 50% en el volumen de soporte técnico relacionado con WiFi tras la migración a la autenticación basada en certificados.
Ahorro en costos de infraestructura. Retirar los servidores NPS locales reduce los costos de cómputo, las tarifas de licencia del sistema operativo y la sobrecarga operativa de aplicar parches y mantener clústeres de alta disponibilidad. Para una organización mediana que ejecuta dos servidores NPS, esto puede representar ahorros de £15,000 a £30,000 al año en costos de infraestructura y operativos.
Mejora de la postura de seguridad y el cumplimiento. Dejar atrás 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 Healthcare que manejan datos de pacientes, respalda el cumplimiento de DSPT. Para los operadores de Transport , se alinea con los requisitos de la Directiva NIS2 para la seguridad de la red.
Experiencia de usuario mejorada. La conexión WiFi automática y sin interrupciones (sin solicitudes de contraseña, sin bloqueos y sin configuración manual) mejora la productividad y reduce la fricción para el personal. Esto es particularmente impactante en entornos de alta movilidad, como centros de distribución, salas de hospitales y pisos de venta de retail. 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 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 implementación específicas del sector hotelero, consulte Modern Hospitality WiFi Solutions Your Guests Deserve .
Definiciones clave
802.1X
Un estándar IEEE para el Control de Acceso a Redes basado en puertos (PNAC). Proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, evitando el acceso no autorizado antes de que se complete la autenticación.
El protocolo fundamental que evita que dispositivos no autorizados accedan a la red empresarial. Todas las implementaciones de WPA2/WPA3-Enterprise dependen de 802.1X.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan y utilizan un servicio de red. Definido en el RFC 2865.
El componente del servidor que valida las credenciales o certificados contra el directorio (Entra ID o AD DS) e instruye al punto de acceso para otorgar o denegar el acceso.
Supplicant
El dispositivo cliente (laptop, smartphone, dispositivo IoT) que intenta conectarse a la red. En Windows, el cliente inalámbrico integrado actúa como el supplicant.
En las implementaciones de Intune, el supplicant debe configurarse con el perfil de WiFi y el certificado de cliente correctos para comunicarse con éxito con el servidor RADIUS.
Authenticator
El dispositivo de red — típicamente un Punto de Acceso Inalámbrico o un switch administrado — que facilita el proceso de autenticación entre el supplicant y el servidor RADIUS. Aplica el control de acceso basado en la respuesta de RADIUS.
El punto de acceso debe configurarse con la dirección IP del servidor RADIUS y el secreto compartido. Actúa como un intermediario, reenviando paquetes EAP entre el cliente y el servidor RADIUS.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un método EAP que se basa en certificados digitales para la autenticación mutua entre el cliente y el servidor RADIUS. Está definido en el RFC 5216 y se considera uno de los estándares EAP más seguros disponibles.
El método de autenticación recomendado para todas las nuevas implementaciones de Microsoft 802.1X. Elimina por completo las contraseñas y es necesario para cumplir con PCI DSS y los marcos de acceso a la red de confianza cero (zero-trust).
NPS (Network Policy Server)
La implementación de Microsoft de un servidor y proxy RADIUS, disponible como un rol en Windows Server. NPS puede autenticar usuarios y dispositivos contra Active Directory Domain Services.
La solución tradicional on-premise para la autenticación de WiFi empresarial en entornos de Microsoft. Muchas organizaciones están migrando actualmente de NPS a soluciones de Cloud RADIUS a medida que se trasladan a Entra ID.
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo utilizado para emitir certificados digitales a dispositivos de red de manera escalable y automatizada. Definido en el RFC 8894.
El método principal que utiliza Microsoft Intune para implementar de forma silenciosa certificados de cliente en dispositivos administrados para la autenticación WiFi EAP-TLS. Requiere una Autoridad de Certificación compatible con SCEP.
Microsoft Entra ID
El servicio de gestión de accesos e identidad basado en la nube de Microsoft, anteriormente conocido como Azure Active Directory. Proporciona autenticación de usuarios, gestión de grupos, Acceso Condicional e integración con miles de aplicaciones.
El proveedor de identidad central en los entornos modernos de Microsoft. Las soluciones de Cloud RADIUS se integran con Entra ID a través de la Microsoft Graph API para validar las identidades de usuarios y dispositivos durante la autenticación WiFi.
Conditional Access
Una función de Entra ID que aplica políticas de acceso basadas en señales como la identidad del usuario, el estado de cumplimiento del dispositivo, la ubicación y el nivel de riesgo. Las políticas pueden requerir que los dispositivos cumplan con Intune antes de otorgar el acceso.
Se utiliza en implementaciones avanzadas de RADIUS para garantizar que solo los dispositivos administrados y que cumplen con las políticas puedan autenticarse en la red WiFi corporativa, incluso si presentan un certificado válido.
PEAP-MSCHAPv2
EAP protegido con el Protocolo de autenticación por desafío mutuo de Microsoft versión 2. Un método EAP basado en credenciales que utiliza un nombre de usuario y una contraseña para la autenticación, transmitido dentro de una sesión TLS.
El método de autenticación heredado que se utiliza en muchas implementaciones de NPS existentes. Es vulnerable al robo de credenciales y a ataques de intermediario (man-in-the-middle), por lo que se debe migrar a EAP-TLS en todas las nuevas implementaciones.
Ejemplos resueltos
Una cadena de retail de 200 sucursales necesita proteger su WiFi de oficina administrativa para las laptops de los gerentes de tienda. Actualmente utilizan una contraseña compartida WPA2-Personal (PSK) en todas las tiendas, la cual rara vez se cambia. Utilizan Entra ID e Intune para la gestión de dispositivos. ¿Cómo deberían modernizar su seguridad inalámbrica?
La cadena de retail debería migrar a WPA3-Enterprise utilizando EAP-TLS en las 200 sucursales. La arquitectura recomendada es una solución Cloud RADIUS integrada directamente con su tenant de Entra ID, eliminando la necesidad de servidores NPS locales en cada sitio. Utilizando Intune, despliegan un perfil de certificado SCEP para emitir certificados de dispositivo únicos a las laptops de los gerentes de tienda. Primero se despliega un perfil de CA raíz de confianza para garantizar que los dispositivos confíen en el servidor RADIUS. Luego, se despliega un perfil de configuración de WiFi a través de Intune, conectando de forma silenciosa los dispositivos al nuevo SSID utilizando el certificado emitido. El antiguo SSID con PSK se retira una vez que todos los dispositivos hayan migrado. Para el WiFi de cara al cliente de la tienda, una solución de Captive Portal independiente gestiona el acceso de invitados sin afectar la infraestructura de autenticación corporativa.
Un gran centro de convenciones utiliza Windows NPS local para la autenticación del WiFi del personal. Experimentan fallas frecuentes de conectividad durante eventos grandes porque el servidor NPS se satura con solicitudes de autenticación concurrentes de más de 500 dispositivos del personal. También están migrando su infraestructura de identidad a Entra ID. ¿Cuál es la arquitectura recomendada de ahora en adelante?
El centro de convenciones debería migrar del servidor NPS local a un proveedor de Cloud RADIUS que se integre directamente con Entra ID. Los dispositivos del personal deben someterse a una transición hacia la autenticación basada en certificados (EAP-TLS) gestionada a través de Intune, resolviendo simultáneamente tanto el problema de escalabilidad como el requisito de migración a Entra ID. Para el alto volumen de asistentes al evento, una red segmentada e independiente que utiliza una solución de Captive Portal gestiona el registro de invitados sin afectar la infraestructura RADIUS corporativa. Ambas redes deben estar en VLANs separadas con las reglas de firewall adecuadas entre ellas. El servidor NPS local se puede retirar una vez que todos los dispositivos del personal hayan migrado con éxito.
Preguntas de práctica
Q1. Tu organización está completando una migración completa de Active Directory local a solo Entra ID; no quedará ningún controlador de dominio local. Actualmente utilizas Windows NPS para la autenticación de WiFi mediante PEAP-MSCHAPv2. ¿Cuál es el enfoque más seguro y operativamente eficiente para el nuevo entorno exclusivo de la nube, y qué pasos específicos se requieren?
Sugerencia: Considera lo que NPS requiere para funcionar y si esas dependencias existirán después de la migración. También considera las implicaciones de seguridad del método EAP actual.
Ver respuesta modelo
El enfoque más seguro y eficiente es implementar una solución Cloud RADIUS integrada directamente con Entra ID, y realizar la transición a la autenticación basada en certificados EAP-TLS gestionada a través de Microsoft Intune. NPS no puede autenticarse directamente contra Entra ID (requiere AD DS local), por lo que no puede sobrevivir a la migración sin que Azure AD Connect mantenga una identidad híbrida. Los pasos son: (1) Seleccionar un proveedor de Cloud RADIUS y otorgarle permisos de Microsoft Graph API en Entra ID. (2) Establecer una PKI nativa de la nube o utilizar Microsoft Cloud PKI. (3) Implementar perfiles de certificado de CA raíz de confianza y SCEP a través de Intune. (4) Implementar un perfil de configuración de WiFi a través de Intune configurado para EAP-TLS. (5) Configurar el SSID en la infraestructura inalámbrica para utilizar los servidores Cloud RADIUS. (6) Desmantelar NPS una vez que todos los dispositivos se hayan migrado.
Q2. El equipo de TI de un hospital desea implementar 802.1X para sus carros médicos (laptops con Windows) utilizando Entra ID. Quieren asegurarse de que si un carro es robado, no pueda conectarse a la red incluso si la cuenta de usuario asociada sigue activa. ¿Cómo se deben configurar el perfil de certificado y la política de RADIUS para lograr esto?
Sugerencia: Considera la diferencia entre los perfiles de certificado basados en usuario y basados en dispositivo en Intune, y cómo se pueden delimitar las políticas de RADIUS a la identidad del dispositivo.
Ver respuesta modelo
El equipo de TI debe configurar Intune para implementar certificados de dispositivo (no de usuario) en los carros médicos. En el perfil SCEP, el Subject Name debe hacer referencia a la identidad del dispositivo (por ejemplo, CN={{DeviceName}} o el número de serie del dispositivo) en lugar del UPN del usuario. La política de RADIUS debe configurarse para autenticar el certificado del dispositivo y validar el dispositivo contra los objetos de dispositivo de Entra ID. Si se roba un carro, el equipo de TI puede borrar de forma remota el dispositivo a través de Intune (lo que elimina el certificado del almacén de certificados del dispositivo) o revocar el certificado de dispositivo específico en la PKI. Cualquiera de las dos acciones bloquea inmediatamente el acceso a la red sin afectar ninguna cuenta de usuario. Este enfoque es superior a los certificados basados en usuario para dispositivos compartidos como los carros médicos.
Q3. Has implementado con éxito EAP-TLS a través de Intune para las 800 laptops corporativas en un campus universitario. Sin embargo, el departamento de TI suele traer contratistas externos que necesitan acceso a Internet para el trabajo de proyectos. Estos contratistas utilizan sus propias laptops personales o emitidas por sus empresas que no están inscritas en tu tenant de Intune. ¿Cómo deberías proporcionar acceso a estos contratistas sin comprometer la seguridad de la red corporativa 802.1X?
Sugerencia: Recuerda el principio arquitectónico que separa la autenticación de dispositivos gestionados del acceso de dispositivos no gestionados. Considera cómo se podría aprovechar Entra ID B2B.
Ver respuesta modelo
No intentes aprovisionar acceso 802.1X para dispositivos de contratistas no gestionados. En su lugar, implementa un SSID de invitados independiente respaldado por una solución de Captive Portal. Para los contratistas que tienen sus propios tenants corporativos de Entra ID, configura el Captive Portal para admitir la colaboración B2B de Entra ID, permitiéndoles autenticarse con sus propias credenciales corporativas a través del portal. Para los contratistas sin un proveedor de identidad compatible, utiliza un flujo de trabajo de acceso patrocinado donde un miembro del personal de la universidad apruebe la solicitud de acceso. La red de contratistas debe estar en una VLAN separada con acceso exclusivo a Internet y sin ruta hacia los recursos internos de la universidad. Esto mantiene la integridad de la red corporativa 802.1X al tiempo que proporciona una ruta de acceso segura y auditable para partes externas.
Q4. Durante una revisión posterior a la implementación, tu equipo de seguridad señala que varios dispositivos en la WiFi corporativa todavía utilizan PEAP-MSCHAPv2 a pesar del despliegue de EAP-TLS. La investigación revela que se trata de dispositivos IoT (pantallas inteligentes, sensores ambientales y una flota de impresoras de red) que no admiten la autenticación basada en certificados. ¿Cómo se deben manejar estos dispositivos?
Sugerencia: Considera las opciones disponibles para los dispositivos que no pueden admitir EAP-TLS y la importancia de la segmentación de red.
Ver respuesta modelo
Los dispositivos IoT y el hardware heredado que no pueden admitir EAP-TLS no deben colocarse en el SSID corporativo 802.1X. El enfoque recomendado es crear un SSID de IoT dedicado en una VLAN separada con reglas de firewall estrictas que limiten la comunicación únicamente a los servicios que esos dispositivos requieren (por ejemplo, servidores de impresión, plataformas de gestión). Para la autenticación, utiliza MAC Authentication Bypass (MAB) para dispositivos con direcciones MAC conocidas y fijas, o un SSID WPA2-Personal con una PSK compleja y rotada regularmente. La VLAN de IoT no debe tener acceso a los recursos compartidos de archivos corporativos, Active Directory ni a recursos internos confidenciales. La plataforma Sensors de Purple, por ejemplo, está diseñada para operar en un segmento de red de IoT dedicado, separado de la infraestructura corporativa.
Continúe leyendo esta serie
Integración de CommScope Ruckus con Purple WiFi: Guía de instalación y configuración
Esta guía de referencia técnica proporciona un manual de configuración definitivo para integrar arquitecturas de CommScope Ruckus con Purple WiFi. Detalla implementaciones paso a paso para Captive Portals de Guest WiFi, WiFi seguro para el personal a través de 802.1X y aislamiento de red multi-inquilino mediante Dynamic PSK de Ruckus.
Integración de Access Points Allied Telesis con Purple WiFi
Esta guía proporciona un manual de configuración completo para integrar los access points de la serie TQ de Allied Telesis con Purple WiFi. Cubre la redirección de Captive Portal externo, la autenticación RADIUS 802.1X y el direccionamiento dinámico de VLAN mediante claves privadas precompartidas (PPSK) para despliegues multi-inquilino seguros.
Grandstream GWN Access Points Integration with Purple WiFi
Esta guía de referencia técnica autorizada detalla cómo integrar los puntos de acceso Grandstream GWN con la plataforma de análisis y Guest WiFi de Purple. Cubre la configuración del Captive Portal de Grandstream, los ajustes de RADIUS AAA, la configuración del walled garden, la autenticación segura para el personal mediante 802.1X con direccionamiento dinámico de VLAN y la segmentación PPSK multi-tenant, proporcionando una guía paso a paso y práctica para MSPs y equipos de TI que despliegan WiFi para invitados y personal a gran escala.