Ha heredado unas instalaciones en el Reino Unido donde la contraseña de la red WiFi corporativa está impresa en una carpeta de la oficina de administración, compartida por recepción, limpieza, contratistas y antiguos 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 la arquitectura a menudo 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 utilizar la autenticación RADIUS basada en un objeto de equipo y un certificado locales, por lo que los diseños modernos dependen de EAP-TLS, certificados emitidos por Intune y una capa RADIUS independiente en su lugar (guía de RADIUS para Entra de Microsoft). Una vez que se aclara esta distinción, el despliegue es mucho más fácil de diseñar, probar y mantener.
Por qué la autenticación de WiFi con Microsoft Entra ID vale la pena
Una clave precompartida compartida puede funcionar en el momento de la apertura, y luego permanecer activa después de que un empleado se marche, un contratista la copie en un dispositivo personal o un invitado acceda a una red destinada al personal. Cambiar esa clave crea su propio problema operativo. Cada portátil gestionado, teléfono, caja registradora, tableta y cualquier otro dispositivo debe recibir el nuevo secreto, a menudo en hoteles, hospitales y tiendas minoristas.
La autenticación WiFi de 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 un certificado para identificar a un usuario o dispositivo autorizado. Intune controla qué endpoints gestionados reciben ese certificado y el perfil de WiFi correspondiente. El punto de acceso sigue requiriendo RADIUS, por lo que 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 omiten muchas guías simplificadas.
Regla práctica: Trate el WiFi como un servicio vinculado a la identidad: exija un certificado y el alcance de Intune, nunca pegar un 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 pedir al personal que escriba o comparta una clave. La baja también obtiene 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 lugar donde se almacenó una contraseña compartida.
El caso de cumplimiento es igualmente práctico. Las organizaciones del Reino Unido deben separar al personal, los invitados, los proveedores y los equipos no gestionados en todas las instalaciones compartidas y los entornos regulados. Una guía de seguridad WiFi para empresas 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 PKI, Intune, la política de RADIUS y la configuración inalámbrica deben funcionar juntas, y los dispositivos heredados de Apple, Windows, Android y compartidos pueden mostrar un comportamiento de certificado o perfil diferente. 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 parque mixto en el Reino Unido.
Los componentes principales que necesita tener listos
La red de invitados de un hotel, una sala de hospital o una sucursal minorista pueden fallar en la primera comprobación del certificado mientras el punto de acceso sigue mostrando un SSID correcto. 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 entidad de certificación. Comience con Microsoft PKI, AD CS o un proveedor de certificados gestionados. La CA debe emitir certificados con EKU de Client Authentication 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 finalizan el intercambio 802.1X desde los puntos de acceso. Entra ID no tiene ninguna función nativa de RADIUS. La extensión NPS adapta las solicitudes RADIUS a las comprobaciones respaldadas por Entra, en lugar de convertir Entra en un servidor RADIUS, tal como se explica en las preguntas y respuestas de Microsoft sobre la limitación de RADIUS.
- Intune. Intune proporciona 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, por lo que un perfil inacabado no llegará a todo el parque de dispositivos.
- Política de red. RADIUS debe definir qué permite un certificado correcto. Eso podría ser una VLAN de empleados, un segmento clínico, una red comercial restringida o una ACL específica para un dispositivo.
Construir en orden de dependencia
Publique y valide la plantilla de CA antes de ajustar RADIUS. Compruebe el emisor, el asunto o SAN, la cadena de certificados y el EKU de Client Authentication. De lo contrario, los fallos de saludo pueden parecer un fallo 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 inalámbricas, pero sus modelos de reglas y gestión de atributos difieren. Seleccione una única fuente de verdad para el mapeo de SSID a VLAN, documéntela y evite que los paneles de mandos de los AP y las reglas de RADIUS produzcan resultados contradictorios.
Una lista 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 doble factor (lista de Entra ID del sector público del Reino Unido). El modelo de certificado sigue dependiendo de los componentes independientes de PKI y RADIUS.
Emisión de certificados y distribución de perfiles de WiFi a través de Intune
Para los dispositivos gestionados, 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 del certificado
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 extremo SCEP publicado, a la plantilla de certificado correcta y a un mecanismo de desafío que evite solicitudes no autorizadas.
El propio certificado necesita Autenticación de cliente 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 al mapeo de RADIUS, al comportamiento de los dispositivos compartidos y a cómo investigará un evento de autenticación más adelante.
Un perfil PFX puede funcionar cuando los certificados se generan y empaquetan a través de un flujo de trabajo aprobado, pero SCEP suele ser más fácil de operar en un parque gestionado variado porque el dispositivo puede solicitar y renovar su propio certificado. El punto importante es la coherencia. 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, el modo de seguridad y el método EAP exactos. Seleccione EAP-TLS, asocie el perfil al certificado emitido por la configuración SCEP y habilite la validación del certificado del servidor. Añada los nombres exactos de los servidores RADIUS para que un dispositivo no acepte un servicio falsificado durante la decisión de confianza. Las directrices de despliegue en el Reino Unido alineadas con Microsoft recomiendan una raíz de confianza, un perfil de certificado de cliente SCEP y nombres RADIUS precisos en el perfil de WiFi (guía de configuración de WiFi para Entra ID en el Reino Unido).
El campo que causa fallos repetidos 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 adecuado o rechazar la conexión.
Asigne los perfiles SCEP y WiFi al mismo grupo de dispositivos de prueba. Compruebe los registros del dispositivo para verificar la instalación del certificado, confirme que la raíz es de confianza y luego inspeccione el certificado de cliente seleccionado antes de cambiar la política RADIUS. Una comprobación de estado de certificados, como este comprobador de certificados SSL, puede ayudar a validar la parte del certificado orientada al público, pero la resolución de problemas internos de EAP-TLS sigue dependiendo de los registros del dispositivo y de RADIUS.
Conexión a su red y a la capa RADIUS
El punto de acceso ve un suplicante 802.1X. No ve 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 de la empresa.
- 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 con la CA emisora de confianza.
- El motor de políticas mapea la identidad del certificado a una cuenta, dispositivo o grupo.
- La respuesta de RADIUS asigna la VLAN permitida o la política de acceso.
Diferencias de configuración entre proveedores
Los paneles de Meraki suelen requerir los detalles del servidor RADIUS, el secreto compartido y la configuración de validación de certificados, utilizando la invalidación de AAA allí donde la respuesta RADIUS controla la segmentación. Las implementaciones de Aruba a menudo dependen de un grupo de servidores RADIUS y de reglas de derivación de servidores. Ruckus SmartZone necesita la configuración de 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 cuando el legado EAP-TTLS coexiste 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 encajar, pero no interpretarán cada atributo de certificado o condición de política de forma 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 | El desajuste 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 WLAN puede hacer referencia a un grupo de servidores incompleto |
| UniFi | Perfil RADIUS de la aplicación de red | EAP-TLS o método heredado controlado | Identidad del certificado | Los métodos EAP mixtos pueden enmascarar el fallo real |
En NPS, inspeccione las propiedades del certificado EAP-TLS y defina si el emisor, el asunto o el SAN proporcionan el mapeo de la cuenta. Un error frecuente es asumir que el nombre común es el nombre de usuario cuando el servicio RADIUS analiza el SAN como un UPN. Eso 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 equilibrio de carga cuando el parque tecnológico requiera resiliencia y configure temporizadores de conmutación por error razonables por SSID. No asuma que un servicio RADIUS en la nube aplica la revocación en tiempo real. Algunos dispositivos alojados carecen de validación de CRL o 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 difícil no es si un dispositivo puede registrarse. Es qué sucede después de que el departamento de recursos humanos deshabilite una cuenta.
El Acceso Condicional evalúa los inicios de sesión de Entra compatibles. No accede a una sesión 802.1X ya establecida para finalizarla simplemente porque haya cambiado el estado de un directorio. Un certificado ya instalado en un ordenador portátil puede seguir siendo criptográficamente válido hasta que caduque o el servicio RADIUS lo rechace mediante la comprobació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 del certificado
La primera mitigación es una vida útil corta del certificado. Los perfiles SCEP de Intune pueden emitir certificados que se renuevan regularmente, limitando 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 del dispositivo y la tolerancia operativa. Una vida útil más corta aumenta la dependencia de una renovación fiable, 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 activa de la revocación. Publique una CRL accesible o utilice OCSP y, a continuación, confirme que los servidores RADIUS la consulten. Las configuraciones de NPS y ClearPass pueden parecer correctas 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 medida operativa que importa es el intervalo entre la inhabilitación en el directorio y el primer paquete inalámbrico rechazado.
Los flujos de trabajo de retirada y borrado de Intune siguen siendo valiosos, especialmente para dispositivos perdidos o compartidos, pero no borran mágicamente un certificado de un terminal apagado. El certificado se vuelve inutilizable por caducidad, revocación o eliminación la próxima vez que el dispositivo reciba instrucciones de gestión. Los equipos deben documentar esa ventana de tiempo y probarla durante los ejercicios de baja de usuarios.
La evaluación de acceso continuo de Entra admite decisiones de control rápidas para escenarios de aplicaciones en la nube seleccionados. Actualmente no convierte a EAP-TLS en una transacción de acceso condicional de tipo navegador, por lo que el WiFi sigue dependiendo de la validez del certificado y del comportamiento de revocación de RADIUS. Para los lectores que deseen revisar el modelo de autenticación general, 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, incluido GovWifi, refuerzan que los visitantes y el acceso compartido no deben verse obligados a seguir el mismo flujo de trabajo de certificados del personal (guía de integración de WiFi de Entra en el Reino Unido).
Pruebas y resolución de problemas en modos de fallo comunes
Una prueba de laboratorio demuestra que un dispositivo puede conectarse. Una implementación de producción demuestra que el dispositivo incorrecto no puede conectarse, que se rechaza un certificado revocado y que un invitado no puede heredar la política del personal.
Comenzar por el certificado
Para un fallo de EAP-TLS, inspeccione el certificado del cliente antes de cambiar el AP. Confirme la cadena, el emisor, el SAN, la caducidad y el EKU de Client Authentication. Luego compruebe si el perfil de WiFi selecciona ese certificado y si el dispositivo confía en el certificado del servidor RADIUS.
Los bucles SCEP suelen indicar una discrepancia entre Intune, NDES y la plantilla de certificado. Verifique la URL de desafío, confirme que la cuenta del conector NDES tiene los permisos de plantilla requeridos y compare el URI del perfil SCEP con la URL de NDES publicada, incluida 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 difundir el mismo SSID antes de que se realice la validación del certificado. Configure la validación de certificados de servidor, especifique los nombres de RADIUS esperados en el perfil de WiFi de Intune y utilice ajustes de red gestionados para que el sistema operativo no se conecte libremente a un impostor. Active las Tramas de Gestión Protegidas (PMF) siempre que el cliente y el parque de puntos de acceso lo admitan, 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. Compruebe que la validación CRL esté habilitada y, a continuación, confirme que la subred RADIUS puede resolver y alcanzar el punto de distribución. Si se utiliza OCSP, inspeccione el tiempo de espera y la accesibilidad del respondedor en lugar de asumir que el servicio está realizando la comprobación automáticamente.
La superposición de invitados y personal suele deberse al orden de las políticas. Coloque las reglas de personal de EAP-TLS por delante de las reglas de invitados basadas en MAC o PSK, y luego verifique los atributos de VLAN devueltos en el registro de RADIUS. Una autenticación válida con la VLAN incorrecta es un fallo de política, no un fallo de inscripción.
Utilizar un orden de triaje fijo
Las conexiones iniciales lentas pueden deberse a la sincronización de la renovación de certificados, a puntos finales de revocación inaccesibles o a que el sistema operativo seleccione el SSID incorrecto. No empiece por reconstruir el perfil.
- Inspeccionar el certificado del dispositivo: Comprobar la cadena, el EKU, el emisor, el SAN y la validez.
- Capturar el intercambio inalámbrico: Confirmar que el punto de acceso reenvía el tráfico EAP al destino RADIUS previsto.
- Leer el registro de eventos RADIUS: Utilizar los registros de NPS, los registros de eventos de ISE o el seguimiento de accesos de ClearPass para identificar el atributo rechazado.
- Comprobar el estado de Intune: Confirmar que el dispositivo está registrado, recibe los perfiles y permanece dentro del grupo de asignación previsto.
- Verificar la política devuelta: Confirmar que las sesiones de personal y de invitados reciben la VLAN y la ACL correctas.
Ese orden mantiene la investigación guiada por evidencias. Cambiar tres capas a la vez a menudo oculta el fallo original.
Una lista de verificación para el despliegue y próximos pasos
Ejecute el despliegue como un cambio de servicio controlado, no como un experimento de certificados. Comience con un grupo reducido de dispositivos que represente a todo el parque informático: un portátil Windows moderno, terminales Apple, hardware Android, dispositivos compartidos y cualquier equipo operativo que deba permanecer conectado. La recepción de un hotel, una planta de hospital y una tienda minorista pueden utilizar la misma plataforma de identidad pero tener requisitos de recuperación muy diferentes.
La secuencia de despliegue
- Definición del alcance de la prueba piloto: seleccione usuarios, ubicaciones y tipos de dispositivos representativos, incluidos aquellos 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 entidad de certificación raíz de confianza, el perfil de certificado SCEP o PFX y el perfil de WiFi EAP-TLS como un conjunto emparejado.
- Integración de RADIUS: añada los puntos de acceso, los secretos compartidos, la confianza del certificado y las reglas de asignación de identidad a la plataforma RADIUS seleccionada.
- Delimitación de dispositivos: asigne perfiles al grupo piloto y mantenga el SSID heredado disponible como alternativa documentada.
- Despliegue masivo: realice la expansión por sitio o grupo de dispositivos solo después de que se superen las pruebas de emisión de certificados, asignación de VLAN y baja de servicios.
- Cadencia de auditoría: revise las autenticaciones fallidas, la caducidad de certificados, la accesibilidad de la revocación y los resultados de las políticas de empleados frente a invitados.
- Retirada de PSK: elimine los SSIDs de clave compartida solo después de que los equipos de soporte cuenten con un proceso de emergencia probado y el parque de dispositivos se haya migrado.
Las comprobaciones específicas del Reino Unido son fáciles de pasar por alto. Confirme que los dispositivos BYOD de Apple confían 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 la GDPR y alinee los registros de autenticación con los requisitos de auditoría de la PSN o del sector de la organización. Los hospitales y los entornos 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 prevé que las llaves de acceso (passkeys) se conviertan en el método de autenticación por defecto para el inicio de sesión en Entra en 2026, según la actualización del ecosistema de Microsoft (actualización de llaves de acceso de Microsoft Entra). Eso no hace que el trabajo actual con EAP-TLS sea desechable. Las llaves de acceso abordan el inicio de sesión de identidad interactivo, mientras que la 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 parque tecnológico aún depende de una clave compartida o asume que Microsoft Entra ID puede responder directamente a las solicitudes RADIUS, documente primero los SSIDs actuales, la entidad de certificación, los grupos de dispositivos y la política de RADIUS. A continuación, realice un piloto de EAP-TLS con Intune en dispositivos representativos del Reino Unido, pruebe la revocación antes de expandirse 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 la política de red en entornos de múltiples proveedores. Visite Purple para evaluar cómo sus capacidades de acceso para invitados y WiFi para el personal con nivel de certificado podrían encajar en su despliegue en el Reino Unido.
