Resolución de problemas de Android 802.1X y EAP-TLS: una lista de verificación de implementación para Intune y Microsoft Entra ID

Los teléfonos Android administrados suelen fallar en EAP-TLS por una de cuatro razones. El perfil de WiFi carece de un certificado CA o 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 el perfil de raíz de confianza nunca llegó al dispositivo.

¿Cómo se ve una falla de EAP-TLS en Android?

EAP-TLS (Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte) autentica un dispositivo con 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 (Servicio de Autenticación de Marcación de Usuario de Entrada Remota).

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

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

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

¿Qué causa normalmente las fallas 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 nuevas redes empresariales. Android ahora necesita dos cosas antes de enviar su certificado: un certificado CA en el cual confiar y un dominio para coincidir.

Sin ambos, el dispositivo se niega a completar el saludo 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 conectada 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 agrega el SSID manualmente desde la configuración personal no puede acceder a esos certificados, por lo que la autenticación falla.

El campo de nombres de servidor RADIUS

El perfil de 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 de 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. Ambos perfiles también deben dirigirse a los mismos grupos y al mismo tipo de registro de Android Enterprise.

Diferencias entre fabricantes

Las compilaciones de Samsung, Google Pixel y otros fabricantes etiquetan y organizan la configuración de WiFi empresarial de manera diferente. Algunos muestran opciones adicionales, como la verificación del estado del certificado en línea. Utilice los dispositivos de su propia flota como referencia, no capturas de pantalla de otra marca.

¿Cómo identificar cuál es la causa que tiene?

Comience en el dispositivo y luego confirme en los registros de RADIUS. El patrón en los registros generalmente señala la causa.

Síntoma	Lo que muestra RADIUS	Causa probable	Primera solución
Ningún intento llega a RADIUS	Sin solicitud del dispositivo	El perfil de WiFi no se aplicó o hay una discrepancia en el nombre del SSID	Verifique el estado del perfil por dispositivo en Intune
El handshake se detiene después de que el servidor envía su certificado	Alerta TLS del cliente, como "CA desconocida"	CA raíz de confianza incorrecta o faltante, o discrepancia de dominio	Implemente la CA raíz del servidor y corrija los nombres de los servidores RADIUS
El handshake se completa del lado del servidor, luego falla	No se presentó 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, luego rechazado	Access-Reject después de la validación del certificado	Mapeo de identidad, revocación o regla de política	Verifique el asunto del certificado o el SAN contra el proveedor de identidad
Falla solo en dispositivos de propiedad personal	Sin solicitud o sin certificado de cliente	Conexión al SSID realizada desde el perfil personal	Implemente el perfil en el perfil de trabajo y detenga las conexiones manuales

Lea el fallo en el dispositivo

En el centro de administración de Microsoft Intune, abra el dispositivo y verifique el estado de cada perfil de configuración. Un perfil de WiFi que se muestra como pendiente o con error nunca llegó al dispositivo. Un perfil de certificado con error significa que falló la emisión de SCEP (Simple Certificate Enrollment Protocol) o PKCS (Public Key Cryptography Standards). Corrija eso antes de tocar la red.

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

Lea 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 por 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 mientras el personal camina entre pisos, la causa es diferente. Lea Resolving Roaming Issues in Corporate WLANs. Las desconexiones que coinciden con 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 compilación de Android?

En Intune

1. Abra el perfil de WiFi para Android Enterprise que coincida con el tipo de registro. Los dispositivos con perfil de trabajo totalmente administrados, dedicados y de propiedad corporativa utilizan un tipo de perfil. Los dispositivos con perfil de trabajo de propiedad personal utilizan otro.
2. Establezca el tipo de EAP en EAP-TLS.
3. Ingrese el nombre DNS del certificado del servidor RADIUS en nombres de servidores RADIUS. El nombre exacto del certificado es el valor más seguro. Nunca ingrese 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 solicite al personal que edite la configuración empresarial de forma manual en ninguna marca. Los cambios manuales omiten Intune y quedan en el lado incorrecto del perfil de trabajo. Si un fabricante falla y otro funciona, compare primero el estado del perfil. Luego, pruebe el valor del dominio con esa compilación en su laboratorio.

En el lado de RADIUS

Confirme que el certificado del servidor contenga el nombre DNS que ingresó en Intune. Confirme que su cadena conduzca a la raíz que implementó. Si utiliza Purple Staff WiFi, Purple proporciona el servicio 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. Verifique los requisitos de los puntos de acceso en Security and Hardware Compatibility.

Escenarios de ejemplo

Un hotel de 200 habitaciones después de una actualización de Android

Considere un hotel de 200 habitaciones con 60 dispositivos móviles de propiedad corporativa para el personal de limpieza y mantenimiento. Después de una actualización mensual, 40 dispositivos dejaron de unirse al SSID del personal. Los registros de RADIUS mostraron alertas de TLS enviadas por el cliente.

El perfil de WiFi no tenía ningún valor de nombres de servidor RADIUS, algo que las compilaciones más antiguas habían tolerado. El equipo de TI agregó el nombre DNS del certificado del servidor y volvió a implementar el perfil. Los 60 dispositivos se conectaron después de su siguiente registro en 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 minorista de 120 tiendas con dispositivos personales

Considere una cadena de retail de 120 tiendas con gerentes de tienda que utilizan teléfonos personales registrados con un perfil de trabajo. Los tickets de soporte técnico mostraron que los teléfonos en muchas tiendas nunca llegaron a RADIUS.

Los gerentes habían agregado 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 de propiedad personal e indicó a los gerentes que eliminaran las entradas manuales. Los intentos fallidos de conexión se detuvieron una vez que cada teléfono recibió el perfil administrado.

Un operador ferroviario que renueva su certificado de servidor

Considere un operador de trenes que ofrece WiFi para el personal a bordo y en las estaciones (Trains). El operador renovó el certificado de su servidor RADIUS desde 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 de la transición habría evitado la interrupción. El operador ahora programa los cambios de raíz con dos semanas de anticipación.

¿Cómo evitar que vuelva a suceder?

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

• Mapear 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 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. Implemente la CA que firmó el certificado del servidor RADIUS.
• Llenar los nombres de los servidores RADIUS. Utilice el nombre DNS del certificado del servidor, nunca una dirección IP.
• Piloto entre fabricantes. Pruebe al menos un dispositivo Samsung y un Pixel, además de cualquier otra marca en su flota.
• Prohibir uniones manuales. Indique al personal que nunca agregue el SSID de forma manual.
• Programar renovaciones de certificados. Envíe las nuevas raíces antes de que cambie el certificado del servidor.
• Vigilar ambos lados. Revise el estado del perfil de Intune y los rechazos de RADIUS semanalmente durante la implementación.

Para la integración con proveedores de identidad, consulte Cómo habilitar el inicio de sesión único.

Preguntas frecuentes

¿Funciona el WiFi para el personal de Purple con dispositivos Android administrados en Intune?

Sí. El WiFi para el personal de Purple autentica los dispositivos Android administrados con 802.1X basado en certificados contra el RADIUS en la nube de Purple. Usted mantiene Intune para la entrega de certificados y perfiles de WiFi. 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 en esta guía aún se aplican: 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 superposición en la nube en los puntos de acceso que ya utiliza. Los proveedores compatibles incluyen Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Cada proveedor 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. Verifique los requisitos a nivel de modelo en el artículo sobre compatibilidad de hardware y seguridad antes de comenzar.

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

Sí, en la mayoría de los casos se puede. Los dispositivos conservan sus certificados de cliente existentes si el nuevo servicio RADIUS confía en su CA emisora. Usted actualiza el perfil de raíz de confianza y los nombres del servidor RADIUS en Intune para que coincidan con el nuevo certificado de servidor. Realice esos cambios de perfil en una fase de pruebas antes de cambiar el destino RADIUS del SSID. Esto evita las fallas nocturnas de "CA desconocida" descritas en esta guía.

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

Sí, para flotas administradas. EAP-TLS utiliza un certificado por dispositivo o identidad, por lo que no hay contraseñas compartidas que puedan filtrarse. PEAP (EAP protegido) se basa en un nombre de usuario y una contraseña dentro de un túnel TLS. iPSK (clave precompartida de identidad) le otorga a cada dispositivo o grupo su propia clave. iPSK es ideal para dispositivos no administrados que no pueden almacenar certificados. EAP-TLS es ideal para teléfonos que usted administra a través de Intune.

¿Qué estándares 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 GDPR y CCPA. El protocolo 802.1X basado en certificados admite el control de acceso estricto que PCI DSS espera en las redes cercanas a los datos de los titulares de tarjetas. Purple también cuenta con la certificación B Corp. Solicite a su equipo de cuentas los certificados vigentes si su proceso de compras requiere copias.

¿Cuánto tiempo toma una implementación de EAP-TLS en Android?

Espere que la mayor parte del esfuerzo se destine a la PKI y a Intune, no a los puntos de acceso. Dirigir un SSID al RADIUS de Purple requiere seguir una breve lista de verificación del proveedor en el centro de soporte. Crear perfiles SCEP o PKCS, perfiles de raíz de confianza y perfiles de WiFi para cada tipo de inscripción toma más tiempo. Reserve tiempo para una prueba piloto que cubra a todos los fabricantes de su flota antes de la implementación general.