Resolución de problemas de 802.1X y EAP-TLS en Android: lista de comprobación de despliegue para Intune y Microsoft Entra ID

Los teléfonos Android gestionados suelen fallar en EAP-TLS por una de cuatro razones. El perfil WiFi carece de un certificado CA o de un dominio, por lo que Android rechaza el servidor RADIUS. El certificado de cliente se encuentra en un perfil diferente. El campo de nombres de servidor RADIUS no coincide con el certificado del servidor. O bien, el perfil de raíz de confianza nunca llegó al dispositivo.

¿Cómo se muestra un fallo de EAP-TLS en Android?

EAP-TLS (Extensible Authentication Protocol con Transport Layer Security) autentica un dispositivo mediante un certificado en lugar de una contraseña. Se ejecuta dentro de IEEE 802.1X, el estándar de control de acceso basado en puertos. 802.1X entrega la autenticación a un servidor RADIUS (Remote Authentication Dial-In User Service).

Cuando esto falla en Android, normalmente verá uno de estos síntomas:

• La red aparece en la lista pero nunca pasa de "Conectando", para luego volver a quedar en "Guardada".
• El dispositivo muestra un error de autenticación genérico. La redacción varía según el fabricante.
• La red funciona en terminales Samsung pero no en Google Pixel, o viceversa.
• La red funciona en teléfonos de propiedad corporativa pero falla en dispositivos de propiedad personal registrados con un perfil de trabajo.
• No aparece absolutamente nada en sus registros de RADIUS.

Este último síntoma es el más importante. Un dispositivo que nunca llega a RADIUS tiene un problema de perfil, no de autenticación.

¿Qué suele causar los fallos de EAP-TLS en Android?

Validación de servidor más estricta en versiones recientes de Android

Las versiones recientes de Android eliminaron la opción "No validar" para las nuevas redes empresariales. Ahora Android necesita dos cosas antes de enviar su certificado: un certificado CA en el que confiar y un dominio con el que coincidir.

Sin ambos, el dispositivo se niega a completar el saludo de manos TLS. Los perfiles que funcionaron durante años en versiones anteriores pueden fallar una vez que un dispositivo recibe una actualización del sistema operativo.

Certificado en el perfil de trabajo, red unida desde el lado personal

Android Enterprise separa el perfil de trabajo del lado personal, y cada uno tiene su propio almacén de certificados. Intune instala el certificado de cliente y la raíz de confianza en el perfil de trabajo. Un miembro del personal que agregue el SSID manualmente desde la configuración personal no podrá acceder a esos certificados, por lo que la autenticación fallará.

El campo de nombres de servidor RADIUS

El perfil WiFi de Android Enterprise en Intune incluye un campo de nombres de servidor RADIUS. La documentación de Microsoft solicita el nombre DNS en el certificado que presenta su servidor RADIUS. Android coloca este valor en su campo de dominio y lo compara con el certificado del servidor. Si el campo está en blanco, mal escrito o contiene una dirección IP, la validación falla.

El perfil de raíz de confianza

El perfil WiFi apunta a un perfil de certificado de confianza de Intune independiente. Ese perfil debe contener la CA raíz que emitió el certificado del servidor RADIUS. Un error común es implementar la raíz detrás de sus certificados de cliente cuando una CA diferente firmó el certificado del servidor. Los dos perfiles también deben dirigirse a los mismos grupos y al mismo tipo de registro de Android Enterprise.### Diferencias entre fabricantes

Las versiones de Samsung, Google Pixel y otros fabricantes etiquetan y organizan los ajustes de WiFi corporativos de forma diferente. Algunos muestran opciones adicionales, como las comprobaciones del estado de los certificados en línea. Utilice los dispositivos de su propia flota como referencia, no capturas de pantalla de otra marca.

¿Cómo averiguar cuál es la causa?

Comience en el dispositivo y luego confírmelo en los registros de RADIUS. El patrón en los registros suele apuntar a la causa.

Síntoma	Qué muestra RADIUS	Causa probable	Primera solución
Ningún intento llega a RADIUS	Ninguna solicitud del dispositivo	El perfil de WiFi no se ha aplicado o el nombre del SSID no coincide	Compruebe el estado del perfil por dispositivo en Intune
El protocolo de enlace se detiene después de que el servidor envíe su certificado	Alerta TLS del cliente, como "CA desconocida"	Root de confianza incorrecto o ausente, o desajuste de dominio	Despliegue la CA root del servidor y los nombres correctos del servidor RADIUS
El protocolo de enlace se completa en el lado del servidor y luego falla	No se presenta certificado de cliente	Falta el certificado SCEP o PKCS o está en el perfil incorrecto	Confirme que el perfil de certificado se aplicó correctamente para ese dispositivo
Certificado aceptado y luego rechazado	Access-Reject después de la validación del certificado	Asignación de identidad, revocación o regla de política	Compruebe el asunto del certificado o el SAN con el proveedor de identidad
Falla solo en dispositivos de propiedad personal	Ninguna solicitud o ningún certificado de cliente	SSID conectado desde el lado personal	Despliegue el perfil en el perfil de trabajo y detenga las conexiones manuales

Leer el fallo en el dispositivo

En el centro de administración de Microsoft Intune, abra el dispositivo y compruebe el estado de cada perfil de configuración. Un perfil de WiFi que se muestra como pendiente o en error nunca llegó al dispositivo. Un perfil de certificado en error significa que la emisión de SCEP o PKCS falló. Solucione esto antes de tocar la red.

En los dispositivos de laboratorio, los registros de Android Debug Bridge del suplicante WiFi muestran la alerta TLS exacta. Utilice esto para un teléfono de prueba, no para una flota de producción.

Leer los registros de RADIUS

FreeRADIUS, Microsoft Network Policy Server y las plataformas RADIUS en la nube registran dónde se detuvo el intercambio EAP. Busque por la dirección MAC del dispositivo o la identidad del certificado. Una alerta TLS enviada por el cliente significa que el teléfono rechazó su servidor. Un Access-Reject después de un certificado válido significa que su servidor rechazó el teléfono.

Si los dispositivos se autentican y luego se desconectan cuando el personal camina entre plantas, la causa es diferente. Lea Resolving Roaming Issues in Corporate WLANs. Las desconexiones que coinciden con los cambios de canal apuntan en su lugar a eventos de radar. Consulte DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

¿Cómo solucionarlo en Intune y en cada versión de Android?

En Intune

1. Abra el perfil de Android Enterprise WiFi que coincida con el tipo de registro. Los dispositivos totalmente gestionados, dedicados y corporativos con perfil de trabajo utilizan un tipo de perfil. Los dispositivos personales con perfil de trabajo utilizan otro.
2. Establezca el tipo de EAP en EAP-TLS.
3. Introduzca el nombre DNS del certificado del servidor RADIUS en los nombres de servidor RADIUS. El nombre exacto del certificado es el valor más seguro. No introduzca nunca una dirección IP.
4. Seleccione el perfil de certificado de confianza que contiene la CA raíz del servidor.
5. Seleccione el perfil SCEP o PKCS para la autenticación del cliente.
6. Asigne los tres perfiles al mismo grupo.

En Samsung, Pixel y otras compilaciones

No pida al personal que edite la configuración empresarial manualmente en ninguna marca. Los cambios manuales omiten Intune y se aplican en el lado incorrecto del perfil de trabajo. Si un fabricante falla y otro funciona, compare primero el estado del perfil. A continuación, pruebe el valor del dominio con esa compilación en su laboratorio.

En el lado de RADIUS

Confirme que el certificado del servidor contiene el nombre DNS que introdujo en Intune. Confirme que su cadena conduce a la raíz que desplegó. Si utiliza Purple Staff WiFi, Purple proporciona el servicio de RADIUS en la nube y se conecta a sus puntos de acceso a través de RadSec (RADIUS transportado dentro de TLS). Los pasos de configuración del proveedor se encuentran en los artículos de soporte de Purple; por ejemplo, Staff WiFi - Ubiquiti UniFi. Compruebe los requisitos de los puntos de acceso en Security and Hardware Compatibility.

Escenarios prácticos

Un hotel de 200 habitaciones tras una actualización de Android

Imagine un hotel de 200 habitaciones con 60 terminales corporativos para el personal de limpieza y mantenimiento. Tras una actualización mensual, 40 terminales dejaron de conectarse al SSID del personal. Los registros de RADIUS mostraban alertas TLS enviadas por los clientes.

El perfil de WiFi no tenía ningún valor para los nombres de servidor RADIUS, algo que las compilaciones más antiguas habían tolerado. El equipo de TI añadió el nombre DNS del certificado del servidor y volvió a desplegar el perfil. Los 60 terminales se conectaron tras su siguiente sincronización con Intune, sin necesidad de restablecer los valores de fábrica. Los operadores hoteleros pueden encontrar más información sobre la conectividad del personal en nuestra página de Hoteles.

Una cadena de tiendas con 120 establecimientos y dispositivos personales

Imagine una cadena de tiendas (retail) con 120 establecimientos donde los gerentes utilizan teléfonos personales registrados con un perfil de trabajo. Los tickets de soporte mostraron que los teléfonos de muchas tiendas nunca llegaban a RADIUS.

Los gerentes habían añadido el SSID de la tienda desde la configuración personal, donde no existe ningún certificado. El equipo asignó el perfil de WiFi para perfiles de trabajo en dispositivos personales e indicó a los gerentes que eliminaran las entradas manuales. Los fallos de conexión cesaron una vez que cada teléfono recibió el perfil gestionado.

Un operador ferroviario que renueva el certificado de su servidor

Considere un operador de trenes que ofrece WiFi para el personal a bordo y en las cocheras (Trains). El operador renovó el certificado de su servidor RADIUS a través de una nueva CA emisora. Todos los dispositivos Android fallaron de la noche a la mañana con alertas de "CA desconocida". Subir la nueva raíz al perfil de certificado de confianza antes del cambio habría evitado la interrupción. El operador ahora programa los cambios de raíz con dos semanas de antelación.

¿Cómo evitar que vuelva a suceder?

Lista de verificación de despliegue para flotas Android en Intune y Entra ID

• Asociar identidades. Decida si los certificados llevan el ID del dispositivo o el UPN del miembro del personal, que es su nombre de inicio de sesión de Microsoft Entra ID. Configure RADIUS para que coincida con ese campo.
• Separar por tipo de inscripción. Cree un conjunto de perfiles para dispositivos propiedad de la empresa y otro para dispositivos con perfil de trabajo de propiedad personal.
• Emparejar los perfiles. La raíz de confianza, el certificado de cliente y los perfiles de WiFi deben compartir un grupo de asignación.
• Usar la raíz correcta. Despliegue la CA que firmó el certificado del servidor RADIUS.
• Completar los nombres de servidor RADIUS. Utilice el nombre DNS del certificado del servidor, nunca una dirección IP.
• Realizar pruebas piloto con varios fabricantes. Pruebe al menos un terminal Samsung y un Pixel, además de cualquier otra marca de su flota.
• Prohibir conexiones manuales. Indique al personal que nunca añada el SSID de forma manual.
• Programar las renovaciones de certificados. Distribuya las nuevas raíces antes de que cambie el certificado del servidor.
• Vigilar ambos lados. Revise semanalmente el estado del perfil de Intune y los rechazos de RADIUS durante el despliegue.

Para la integración del proveedor de identidad, consulte How to Enable Single Sign On.

Preguntas frecuentes

¿Funciona Purple Staff WiFi con dispositivos Android gestionados en Intune?

Sí. Purple Staff WiFi autentica los dispositivos Android gestionados con 802.1X basado en certificados contra el RADIUS en la nube de Purple. Usted sigue utilizando Intune para la entrega de perfiles de WiFi y certificados. Purple se conecta a Microsoft Entra ID, Okta y Google Workspace para la identidad. Sus perfiles de Intune apuntan al certificado del servidor RADIUS de Purple en lugar de a un servidor local. Las reglas del lado de Android de esta guía se siguen aplicando: se requiere una raíz de confianza y un dominio coincidente.

¿Necesito nuevos puntos de acceso para ejecutar EAP-TLS con Purple?

No. Purple es independiente del hardware y funciona como una capa de software en la nube sobre los puntos de acceso que ya tiene. Entre los fabricantes compatibles se encuentran Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Cada fabricante necesita una configuración de RADIUS que apunte a Purple. Los pasos de configuración se encuentran en los artículos de soporte de Purple. Compruebe los requisitos a nivel de modelo en el artículo de compatibilidad de hardware y seguridad antes de comenzar.

¿Puedo migrar de un NPS local a un RADIUS en la nube sin volver a inscribir los dispositivos Android?

Sí, en la mayoría de los casos es posible. Los dispositivos conservan sus certificados de cliente existentes si el nuevo servicio RADIUS confía en su CA emisora. Solo debe actualizar el perfil de raíz de confianza y los nombres de servidor RADIUS en Intune para que coincidan con el nuevo certificado de servidor. Prepare estos cambios de perfil antes de cambiar el destino RADIUS del SSID. Esto evita los fallos nocturnos por "CA desconocida" descritos en esta guía.

¿Es EAP-TLS mejor que PEAP o iPSK para los dispositivos del personal?

Sí, para flotas gestionadas. EAP-TLS utiliza un certificado por dispositivo o identidad, por lo que no hay contraseñas compartidas que puedan filtrarse. PEAP (EAP protegido) depende de un nombre de usuario y contraseña dentro de un túnel TLS. iPSK (clave precompartida de identidad) otorga a cada dispositivo o grupo su propia clave. iPSK es adecuado para dispositivos no gestionados que no pueden albergar certificados. EAP-TLS es ideal para teléfonos que gestiona a través de Intune.

¿Qué normativas de cumplimiento cumple Purple para los datos de autenticación del personal?

Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y cumple con el GDPR y la CCPA. El estándar 802.1X basado en certificados admite el control de acceso estricto que requiere el estándar PCI-DSS en redes cercanas a datos de titulares de tarjetas. Purple también cuenta con la certificación B Corp. Solicite a su equipo de cuenta los certificados vigentes si su proceso de compras requiere copias.

¿Cuánto tiempo lleva un despliegue de EAP-TLS en Android?

La mayor parte del esfuerzo se centrará en la PKI y en Intune, no en los puntos de acceso. Dirigir un SSID al RADIUS de Purple requiere seguir una breve lista de comprobación del proveedor en el centro de soporte. La creación de perfiles SCEP o PKCS, perfiles de raíz de confianza y perfiles de WiFi para cada tipo de registro lleva más tiempo. Prevea tiempo para una prueba piloto que cubra a todos los fabricantes de su flota antes del despliegue generalizado.