Usted ha heredado una propiedad en el Reino Unido donde la contraseña de la red WiFi corporativa está impresa en una carpeta de la oficina administrativa, compartida por recepción, limpieza, contratistas y ex empleados. La red de invitados se gestiona por separado, la incorporación de dispositivos depende de instrucciones manuales y un auditor quiere saber qué persona autorizó cada conexión. Mientras tanto, la organización ha migrado la identidad de sus aplicaciones a Microsoft Entra ID y espera que la red WiFi haga lo mismo.
Esa expectativa es comprensible, pero a menudo la arquitectura se describe de forma incorrecta. Microsoft Entra ID no proporciona un servicio RADIUS nativo. La postura documentada de Microsoft es que los dispositivos unidos a Entra no pueden usar la autenticación RADIUS basada en un objeto de computadora y certificado local, por lo que los diseños modernos dependen en su lugar de EAP-TLS, certificados emitidos por Intune y una capa RADIUS independiente (guía de Microsoft Entra RADIUS). Una vez que queda clara esa distinción, la implementación se vuelve mucho más fácil de diseñar, probar y mantener.
Por qué vale la pena implementar la autenticación de WiFi con Microsoft Entra ID
Una clave precompartida compartida puede funcionar al momento de la apertura, y luego permanecer activa después de que un empleado se va, un contratista la copia en un dispositivo personal o un invitado accede a una red destinada al personal. Cambiar esa clave crea su propio problema operativo. Cada laptop administrada, teléfono, caja registradora, tableta y cualquier otro dispositivo debe recibir el nuevo secreto, a menudo en hoteles, hospitales y tiendas de retail.
La autenticación WiFi de Microsoft Entra ID cambia la unidad de confianza de la contraseña a la identidad y el dispositivo. EAP-TLS utiliza una conexión respaldada por certificados para identificar a un usuario o dispositivo autorizado. Intune controla qué endpoints gestionados reciben ese certificado y el perfil WiFi correspondiente. El punto de acceso aún requiere RADIUS, por lo que Microsoft Entra ID es el directorio y la fuente de políticas, no el endpoint de autenticación inalámbrica. Esa brecha arquitectónica es el detalle que muchas guías simplificadas omiten.
Regla práctica: Trate al WiFi como un servicio vinculado a la identidad: requiera un certificado y un alcance de Intune, nunca un copiado y pegado de nombre de usuario y contraseña de Entra.
La incorporación se vuelve repetible. Un perfil de Intune correctamente configurado puede configurar el SSID, la cadena de certificados de confianza y la selección de certificados sin pedirle al personal que escriba o comparta una clave. La desincorporación también gana una ruta de control definida. Retirar un dispositivo puede desencadenar acciones en el ciclo de vida del certificado, en lugar de dejar que los administradores busquen cada ubicación donde se almacenó una contraseña compartida.
El caso de cumplimiento es igualmente práctico. Las organizaciones del Reino Unido deben separar al personal, invitados, proveedores y equipos no gestionados en entornos compartidos y regulados. Una guía de seguridad WiFi empresarial dedicada proporciona información útil, mientras que el diseño de producción requiere decisiones claras: mantener el acceso de invitados separado del EAP-TLS del personal, registrar la identidad presentada a RADIUS y definir cómo se elimina el acceso.
El centro de administración de Entra no proporciona un interruptor único para este diseño. La configuración de PKI, Intune, la política de RADIUS y la red inalámbrica deben funcionar en conjunto, y los dispositivos heredados de Apple, Windows, Android y compartidos pueden exponer comportamientos de certificados o perfiles diferentes. Ese trabajo de integración es real, pero reemplaza un secreto compartido frágil con un control repetible que se puede aplicar en todo un patrimonio mixto en el Reino Unido.
Los componentes principales que necesita configurar
La red de WiFi para invitados de un hotel, una sala de hospital o una sucursal minorista pueden fallar en la primera comprobación de certificado mientras el punto de acceso sigue reportando un SSID saludable. Evite esa confusión definiendo la arquitectura antes de abrir el asistente de Intune. Cuatro componentes deben coincidir en una misma cadena de identidad:
- Una autoridad de certificación. Comience con Microsoft PKI, AD CS o un proveedor de certificados gestionados. La CA debe emitir certificados con EKU de Autenticación de cliente antes de ajustar la política de RADIUS, y el servicio RADIUS debe confiar en la cadena de emisión.
- Una capa RADIUS. NPS, Aruba ClearPass, Cisco ISE o una plataforma RADIUS-as-a-Service termina el intercambio 802.1X de los puntos de acceso. Entra ID no tiene una función nativa de RADIUS. La extensión NPS adapta las solicitudes RADIUS a verificaciones respaldadas por Entra, en lugar de convertir a Entra en un servidor RADIUS, como se explica en la Q&A de Microsoft sobre la limitación de RADIUS.
- Intune. Intune entrega la raíz de confianza, el perfil de certificado SCEP o PKCS y la configuración de WiFi. Sus asignaciones también controlan el alcance de los dispositivos, evitando que un perfil sin terminar llegue a todo el parque de equipos.
- Política de red. RADIUS debe definir lo que permite un certificado exitoso. Eso podría ser una VLAN de personal, un segmento clínico, una red minorista restringida o una ACL específica del dispositivo.
Construir en orden de dependencia
Publique y valide la plantilla de CA antes de ajustar RADIUS. Verifique el emisor, el asunto o SAN, la cadena de certificados y el EKU de Client Authentication. De lo contrario, los intercambios de señales fallidos pueden parecer una falla de RF o de SSID cuando el dispositivo no tiene un certificado utilizable.
La confianza debe funcionar en ambas direcciones. Los dispositivos gestionados confían en la CA que firmó el certificado del servidor RADIUS, mientras que RADIUS confía en la CA que emitió el certificado del cliente. Los puntos de acceso necesitan la dirección del servidor RADIUS y el secreto compartido. No se autentican directamente contra Entra.
Decidir dónde reside la política
NPS, ClearPass e ISE pueden aplicar políticas de red inalámbrica, pero sus modelos de reglas y el manejo de atributos difieren. Seleccione una única fuente de verdad para el mapeo de SSID a VLAN, documéntela y evite que los tableros de los AP y las reglas de RADIUS generen resultados en conflicto.
Un listado del sector público del Reino Unido describe el soporte de Entra ID para la autenticación de clave pública, incluidos los certificados de cliente TLS, junto con la federación y la autenticación de dos factores (listado de Entra ID del sector público del Reino Unido). El modelo de certificado todavía depende de los componentes PKI y RADIUS independientes.
Emisión de certificados y distribución de perfiles de WiFi mediante Intune
Para dispositivos administrados, EAP-TLS tiene éxito o falla según la selección del certificado. Intune puede entregar el perfil sin interacción del usuario, pero no puede compensar una plantilla de certificado que carezca del uso, emisor o mapeo de sujeto correctos.
Establecer la ruta de certificación
Despliegue primero el perfil de CA raíz de confianza. Con SCEP, cree un perfil de certificado que apunte al servicio NDES y utilice el Intune Certificate Connector. El perfil debe hacer referencia al endpoint SCEP publicado, a la plantilla de certificado correcta y a un mecanismo de desafío que evite solicitudes no autorizadas.
El certificado en sí necesita Client Authentication en su uso extendido de clave. Decida si el asunto y el SAN identifican al dispositivo, al usuario o a ambos. Esa decisión afecta el mapeo de RADIUS, el comportamiento de los dispositivos compartidos y la forma en que investigará un evento de autenticación más adelante.
Un perfil PFX puede funcionar donde los certificados se generan y empaquetan a través de un flujo de trabajo aprobado, pero SCEP es generalmente más fácil de operar en un parque gestionado diverso porque el dispositivo puede solicitar y renovar su propio certificado. El punto importante es la consistencia. Cada plataforma debe recibir una cadena y un certificado que la política de RADIUS entienda.
Configurar la carga útil de WiFi
Cree el perfil de WiFi con el SSID, modo de seguridad y método EAP exactos. Seleccione EAP-TLS, vincule el perfil al certificado emitido por la configuración SCEP y habilite la validación de certificados de servidor. Agregue los nombres exactos de los servidores RADIUS para que el dispositivo no acepte un servicio similar durante la decisión de confianza. La guía de implementación del Reino Unido alineada con Microsoft recomienda una raíz de confianza, un perfil de certificado de cliente SCEP y nombres de RADIUS precisos en el perfil de WiFi (guía de configuración de WiFi de UK Entra ID).
El campo que causa fallas repetidas es la coincidencia de certificados. En Windows, macOS, iOS y Android, el perfil de WiFi debe seleccionar el certificado emitido por la CA esperada y que contenga el EKU previsto. Si el perfil se despliega pero el sistema operativo no puede seleccionar ese certificado, el dispositivo puede recurrir a un método no apto o rechazar la conexión.
Limite el alcance de los perfiles SCEP y WiFi al mismo grupo de dispositivos piloto. Verifique los registros de los dispositivos para la instalación de certificados, confirme que la raíz es confiable y luego inspeccione el certificado de cliente seleccionado antes de cambiar la política RADIUS. Una verificación de estado del certificado, como este SSL certificate checker, puede ayudar a validar el lado del certificado de cara al público, pero la resolución de problemas interna de EAP-TLS sigue dependiendo de los registros del dispositivo y de RADIUS.
Conexión con su infraestructura de red y capa RADIUS
El punto de acceso detecta un suplicante 802.1X. No detecta Microsoft Entra ID. El dispositivo presenta su certificado de cliente, el AP reenvía el intercambio EAP a RADIUS y el servicio RADIUS valida la cadena de certificados y aplica la política de red.
El flujo habitual es:
- El dispositivo se asocia con el SSID empresarial.
- El AP reenvía el tráfico EAP-TLS a NPS, ClearPass, ISE o a un servicio RADIUS alojado.
- RADIUS valida el certificado de cliente contra la CA emisora de confianza.
- El motor de políticas asigna la identidad del certificado a una cuenta, dispositivo o grupo.
- La respuesta de RADIUS asigna la VLAN o política de acceso permitida.
Diferencias de configuración entre proveedores
Los tableros de Meraki suelen requerir los detalles del servidor RADIUS, el secreto compartido y la configuración de validación de certificados, utilizando la anulación de AAA donde la respuesta de RADIUS controla la segmentación. Las implementaciones de Aruba a menudo dependen de un grupo de servidores RADIUS y reglas de derivación de servidores. Ruckus SmartZone necesita una configuración AAA con EAP-TLS seleccionado, mientras que las plantillas WLAN de Juniper Mist apuntan al clúster RADIUS. UniFi Network utiliza un perfil RADIUS y puede requerir un manejo cuidadoso donde el legado EAP-TTLS permanece junto con EAP-TLS.
El servicio RADIUS-as-a-Service de Purple es una opción alojada para entornos que desean una capa RADIUS independiente sin operar la plataforma de servidor completa. NPS, ClearPass, ISE y los servicios alojados pueden adaptarse, pero no interpretarán cada atributo de certificado o condición de política de manera idéntica.
| Proveedor | Servidor de autenticación RADIUS | Tipo de EAP | Atributo de certificado | Error común |
|---|---|---|---|---|
| Meraki | NPS, ISE, ClearPass o RADIUS alojado | EAP-TLS | Emisor y SAN | La anulación de AAA puede colocar a un usuario válido en la VLAN incorrecta |
| Aruba | NPS, ClearPass, ISE o RADIUS alojado | EAP-TLS | SAN o UPN | El orden de las reglas de derivación del servidor puede enviar al personal a la política de invitados |
| Ruckus | RADIUS conectado a SmartZone | EAP-TLS | Asunto y emisor | La incompatibilidad del tipo de EAP es fácil de pasar por alto en la configuración de AAA |
| Juniper Mist | Clúster RADIUS | EAP-TLS | SAN o identidad mapeada | La plantilla de WLAN puede hacer referencia a un grupo de servidores incompleto |
| UniFi | Perfil de RADIUS de la aplicación de red | EAP-TLS o método heredado controlado | Identidad del certificado | Los métodos EAP mixtos pueden ocultar la falla real |
En NPS, inspeccione las propiedades del certificado EAP-TLS y defina si el emisor, el asunto o el SAN suministran el mapeo de la cuenta. Un error común es asumir que el nombre común es el nombre de usuario cuando el servicio RADIUS analiza el SAN como un UPN. Esto rompe el mapeo de usuarios y también puede interrumpir los flujos de solo dispositivo o de dispositivos compartidos.
Utilice un clúster RADIUS con balanceo de carga cuando el entorno requiera resiliencia, y configure temporizadores de failover lógicos por cada SSID. No asuma que un servicio RADIUS en la nube aplica la revocación en tiempo real. Algunos dispositivos alojados carecen de validación CRL u OCSP accesible, por lo que el certificado puede seguir siendo aceptado incluso después de que cambie una cuenta de directorio.
Revocación instantánea y acceso condicional para WiFi de personal
La pregunta compleja no es si un dispositivo puede inscribirse, sino qué sucede después de que el departamento de recursos humanos deshabilita una cuenta.
El Acceso Condicional evalúa los inicios de sesión compatibles de Entra. No interviene en una sesión 802.1X ya establecida para terminarla simplemente porque cambió el estado de un directorio. Un certificado que ya está instalado en una laptop puede seguir siendo criptográficamente válido hasta que expire o el servicio RADIUS lo rechace mediante la verificación de revocación de certificados. Esto hace que el diseño de la revocación sea más importante que la demostración de la inscripción.
Reducir la ventana de validez del certificado
La primera mitigación es una vida útil corta del certificado. Los perfiles Intune SCEP pueden emitir certificados que se renuevan periódicamente, lo que limita el tiempo que un dispositivo retirado puede seguir presentando una credencial que de otro modo sería válida. El intervalo adecuado depende del modelo de amenazas, la disponibilidad de los dispositivos y la tolerancia operativa. Una vida útil más corta aumenta la dependencia de una renovación confiable, por lo que se deben probar los dispositivos que pasan tiempo sin conexión o que funcionan detrás de redes restringidas.
La segunda mitigación es la comprobación de revocación activa. Publique una CRL accesible u opere OCSP, luego confirme que los servidores RADIUS la consulten. Las configuraciones de NPS y ClearPass pueden parecer saludables mientras ignoran la revocación porque la comprobación está deshabilitada o el punto de distribución no es accesible desde la red RADIUS.
La métrica operativa que realmente importa es el intervalo de tiempo entre la inhabilitación en el directorio y el primer paquete de red inalámbrica rechazado.
Los flujos de trabajo de retiro y borrado de Intune siguen siendo valiosos, particularmente para dispositivos perdidos o compartidos, pero no borran mágicamente un certificado de un endpoint apagado. El certificado se vuelve inutilizable por expiración, revocación o eliminación cuando el dispositivo reciba instrucciones de administración por siguiente vez. Los equipos deben documentar esa ventana de tiempo y probarla durante los ejercicios de desincorporación.
La evaluación de acceso continuo de Entra admite decisiones de control rápidas para escenarios seleccionados de aplicaciones en la nube. Actualmente no convierte a EAP-TLS en una transacción de acceso condicional de tipo navegador, por lo que WiFi sigue dependiendo de la validez del certificado y del comportamiento de revocación de RADIUS. Para los lectores que revisan el modelo de autenticación más amplio, esta guía de MFA para usuarios de Edmonton proporciona un contexto útil sobre cómo difiere la garantía de inicio de sesión más sólida de la autenticación de certificados de red.
El acceso de invitados necesita su propio plano de control. Las prácticas del sector público del Reino Unido, incluyendo GovWifi, refuerzan que los visitantes y el acceso compartido no deben ser forzados a seguir el mismo flujo de trabajo de certificados del personal (guía de integración de WiFi con Entra del Reino Unido).
Pruebas y resolución de problemas de fallas comunes
Una prueba de laboratorio demuestra que un dispositivo puede conectarse. Un despliegue en producción demuestra que el dispositivo incorrecto no puede conectarse, que un certificado revocado es rechazado y que un invitado no puede heredar la política del personal.
Comenzar con el certificado
Para una falla de EAP-TLS, inspeccione el certificado del cliente antes de cambiar el AP. Confirme la cadena, el emisor, el SAN, la expiración y el EKU de Client Authentication. Luego verifique si el perfil de WiFi selecciona ese certificado y si el dispositivo confía en el certificado del servidor RADIUS.
Los bucles de SCEP suelen indicar una discrepancia entre Intune, NDES y la plantilla de certificado. Verifique la URL del desafío, confirme que la cuenta del conector NDES tenga los permisos de plantilla requeridos y compare el URI del perfil SCEP con la URL NDES publicada, incluyendo su barra diagonal final. Un certificado emitido desde la plantilla incorrecta puede parecer un registro exitoso pero seguir siendo inutilizable para WiFi.
Probar la confianza y la segmentación
Un ataque de tipo Evil Twin puede transmitir el mismo SSID antes de que ocurra la validación del certificado. Configure la validación del certificado del servidor, especifique los nombres de RADIUS esperados en el perfil WiFi de Intune y utilice la configuración de red gestionada para que el sistema operativo no se conecte libremente a un impostor. Habilite las tramas de gestión protegidas (Protected Management Frames) cuando la flota de clientes y AP las admita, y utilice un SSID específico de la organización en lugar de un nombre genérico.
Un certificado revocado que aún se autentica suele apuntar al servidor RADIUS, no a Entra. Verifique que la validación CRL esté habilitada, luego confirme que la subred RADIUS pueda resolver y alcanzar el punto de distribución. Si se utiliza OCSP, inspeccione el tiempo de espera y la accesibilidad del responsable de la respuesta en lugar de asumir que el servicio está realizando la comprobación de forma automática.
El cruce entre invitados y personal a menudo proviene del orden de las políticas. Coloque las reglas de personal de EAP-TLS antes de las reglas de invitados basadas en MAC o PSK, luego verifique los atributos de VLAN devueltos en el registro de RADIUS. Una autenticación válida con la VLAN incorrecta es una falla de política, no una falla de inscripción.
Utilizar un orden de diagnóstico fijo
Las primeras conexiones lentas pueden deberse a la sincronización de la renovación de certificados, a puntos de conexión de revocación inalcanzables o a que el sistema operativo seleccione el SSID incorrecto. No comience reconstruyendo el perfil.
- Inspeccionar el certificado del dispositivo: Verifique la cadena, EKU, emisor, SAN y validez.
- Capturar el intercambio inalámbrico: Confirme que el AP reenvíe el tráfico EAP al destino RADIUS previsto.
- Leer el registro de eventos de RADIUS: Use los registros de NPS, los registros de eventos de ISE o el seguimiento de acceso de ClearPass para identificar el atributo rechazado.
- Verificar el estado de Intune: Confirme que el dispositivo esté inscrito, reciba los perfiles y permanezca dentro del grupo de asignación previsto.
- Verificar la política devuelta: Confirme que las sesiones de personal y de invitados reciban la VLAN y la ACL correctas.
Ese orden mantiene la investigación guiada por evidencias. Modificar tres capas a la vez a menudo oculta la falla original.
Lista de verificación de implementación y próximos pasos
Ejecute el despliegue como un cambio de servicio controlado, no como un experimento de certificados. Comience con un grupo pequeño de dispositivos que represente a la flota: una laptop Windows moderna, terminales Apple, hardware Android, dispositivos compartidos y cualquier equipo operativo que deba permanecer conectado. La recepción de un hotel, la sala de un hospital y una tienda minorista pueden utilizar la misma plataforma de identidad pero tener requisitos de recuperación muy diferentes.
La secuencia de implementación
- Definición del alcance del piloto: Seleccione usuarios, ubicaciones y tipos de dispositivos representativos, incluidos los sitios con conectividad débil o rutas de gestión restringidas.
- Preparación de la CA: Confirme la cadena de emisión, los permisos de plantilla, el EKU y los puntos de conexión de revocación antes de crear el perfil de WiFi.
- Creación del perfil de Intune: Cree la raíz de confianza, el perfil de certificado SCEP o PFX y el perfil de WiFi EAP-TLS como un conjunto emparejado.
- Integración con RADIUS: Agregue los puntos de acceso, secretos compartidos, confianza de certificados y reglas de mapeo de identidad a la plataforma RADIUS seleccionada.
- Delimitación de dispositivos: Asigne perfiles al grupo piloto y mantenga el SSID heredado disponible como un respaldo documentado.
- Implementación masiva: Expanda por sitio o grupo de dispositivos únicamente después de que se aprueben las pruebas de emisión de certificados, asignación de VLAN y baja de usuarios.
- Cadencia de auditoría: Revise las autenticaciones fallidas, la expiración de certificados, la accesibilidad de revocación y los resultados de las políticas de personal frente a invitados.
- Retiro de PSK: Elimine los SSIDs de clave compartida únicamente después de que los equipos de soporte cuenten con un proceso probado de recuperación de emergencia y el parque de dispositivos se haya migrado.
Las verificaciones específicas del Reino Unido son fáciles de pasar por alto. Confirme que los dispositivos BYOD de Apple confíen en la cadena de emisión a través de la ruta de gestión prevista. Defina cómo se rotan los secretos compartidos de RADIUS, registre dónde se almacena la telemetría de certificados para la revisión de GDPR y alinee los registros de autenticación con los requisitos de auditoría de la PSN o del sector específico de la organización. Los hospitales y los complejos compartidos del sector público también necesitan un SSID de contingencia documentado o un proceso de acceso alternativo que no se convierta en una red no gestionada permanente.
Se proyecta que las passkeys se convertirán en el método de autenticación predeterminado para el inicio de sesión de Entra en 2026, según la actualización del ecosistema de Microsoft (Microsoft Entra passkeys update). Eso no hace que el trabajo de EAP-TLS de hoy sea desechable. Las passkeys abordan el inicio de sesión de identidad interactivo, mientras que WiFi todavía necesita una credencial de red verificable por la máquina, una decisión de política y un intercambio RADIUS. La CA, la gestión de dispositivos y la disciplina de políticas creadas para los certificados siguen siendo bases útiles para el próximo modelo de identidad.
Si su infraestructura aún depende de una clave compartida o asume que Microsoft Entra ID puede responder solicitudes de RADIUS directamente, documente primero los SSIDs actuales, la autoridad de certificación, los grupos de dispositivos y la política de RADIUS. Luego, realice un piloto de EAP-TLS con Intune en dispositivos representativos del Reino Unido, pruebe la revocación antes de expandir y mantenga el acceso de invitados separado de la identidad del personal.
Purple proporciona una plataforma de WiFi basada en identidad y RADIUS en la nube que puede conectar el acceso del personal respaldado por Microsoft Entra ID con las políticas de red en entornos de múltiples proveedores. Visite Purple para revisar cómo sus capacidades de acceso para invitados y WiFi para el personal con calidad de certificado podrían adaptarse a su despliegue en el Reino Unido.
