Resolución de problemas de 802.1X en iOS y macOS: una lista de verificación de despliegue para Intune, Jamf y Microsoft Entra ID

Los dispositivos Apple fallan en 802.1X por cuatro razones principales. Los nombres de servidor de confianza o los certificados ancla de la carga útil de WiFi no coinciden con el certificado RADIUS. El certificado de identidad no existe o se encuentra en el llavero incorrecto. Un perfil de macOS se ejecuta en el modo incorrecto, o el perfil se dirige al grupo incorrecto de Microsoft Entra ID. Los registros de eapolclient y RADIUS muestran cuál de ellos es el motivo.

¿Cómo se muestra un fallo de 802.1X en un iPhone o Mac?

Los dispositivos Apple rara vez muestran un error preciso. El síntoma en sí es su primera pista, por lo que debe registrarlo con precisión antes de cambiar cualquier perfil.

• El iPhone se niega a unirse a una red EAP-TLS y solicita un nombre de usuario y una contraseña que nunca deberían ser necesarios. El dispositivo no tiene un certificado de identidad utilizable, por lo que recurre a una solicitud de credenciales.
• El Mac muestra un diálogo de confianza de certificado que nombra a su servidor RADIUS. El perfil no tiene fijada la confianza del servidor o permite que la persona anule una discrepancia.
• El Mac se conecta después de iniciar sesión, pero no en la ventana de inicio de sesión. Por lo tanto, las cuentas de red y los desbloqueos de FileVault fallan en los equipos compartidos.
• Algunos dispositivos funcionan y otros nunca ven la red. Esto suele deberse al alcance del grupo, no a la criptografía.
• Todo funcionó durante meses y luego falló una mañana. Ese patrón casi siempre se produce tras la renovación de un certificado RADIUS.

¿Qué suele provocar que los iPhones y Macs fallen en EAP-TLS o PEAP?

La confianza del servidor no coincide con el certificado RADIUS

La carga útil de WiFi de Apple fija la confianza del servidor en dos lugares. Los nombres de los certificados de servidor de confianza deben coincidir con el nombre del certificado de su servidor RADIUS. Los certificados de confianza deben incluir la raíz que los emitió. Si alguno de los dos es incorrecto, el dispositivo detiene el protocolo de enlace TLS.

Por este motivo, macOS le pide que confíe en el certificado RADIUS. Sin un certificado ancla en el perfil, Apple deja la decisión en manos de la persona que está ante el teclado. Con la confianza fijada y una discrepancia, la conexión falla de forma silenciosa. La guía de confianza del servidor de perfiles WiFi de Intune detalla las reglas de nomenclatura en profundidad.

El certificado de identidad no existe o se encuentra en el llavero incorrecto

EAP-TLS necesita un certificado de cliente y su clave privada en el dispositivo. La carga útil de WiFi debe hacer referencia a ese certificado, entregado por una carga útil de SCEP o PKCS. En macOS, un perfil a nivel de dispositivo instala los certificados en el llavero del sistema (System keychain). Un perfil a nivel de usuario los instala en el llavero de inicio de sesión (login keychain). Una red configurada a nivel de dispositivo no puede acceder a un certificado en el llavero de inicio de sesión.

Los modos de sistema, ventana de inicio de sesión y usuario de macOS están mezclados

macOS admite tres contextos 802.1X. El modo de sistema se conecta antes de que nadie inicie sesión, utilizando un certificado de equipo. El modo de ventana de inicio de sesión utiliza las credenciales introducidas en la ventana de inicio de sesión. El modo de usuario se conecta solo después de iniciar sesión, con credenciales o un certificado vinculado a esa cuenta. Elija el modo que coincida con el momento en que el Mac necesita la red.

Los perfiles están asignados al grupo incorrecto de Microsoft Entra ID

La documentación de Intune de Microsoft indica que se deben asignar el certificado de confianza, SCEP o PKCS, y los perfiles de WiFi a los mismos grupos. Si asigna uno a un grupo de dispositivos y otro a un grupo de cuentas de personal, algunos dispositivos solo recibirán la mitad de la cadena. Los iPads compartidos y los Macs sin cuenta principal nunca reciben perfiles dirigidos a personas.

PEAP frente a cuentas de Entra ID exclusivas en la nube

PEAP-MSCHAPv2 necesita un servidor RADIUS que pueda validar la contraseña. Entra ID no tiene un servicio RADIUS nativo, por lo que las cuentas exclusivas en la nube normalmente no pueden autenticarse de esta manera. La mayoría de los entornos de Entra ID migran los dispositivos Apple a EAP-TLS por este motivo.

Síntoma	Causa más probable	Evidencia a buscar	Solución
Diálogo de confianza en Mac	No hay un ancla de certificado de confianza en el perfil	eapolclient muestra un fallo de evaluación de confianza	Añada la raíz de RADIUS como un payload de certificado de confianza
Fallo silencioso tras la renovación del certificado	Los nombres de servidor de confianza ya no coinciden	RADIUS muestra el inicio de la sesión EAP y luego el cliente la abandona	Añada el nuevo nombre de servidor y la raíz antes de la rotación
Solicitud de contraseña en red EAP-TLS	Certificado de identidad no entregado	No hay certificado de cliente en el llavero	Asigne el perfil SCEP o PKCS al mismo grupo que el perfil de WiFi
Funciona tras iniciar sesión, falla en la ventana de inicio de sesión	Perfil de modo de usuario en un Mac compartido	El certificado se encuentra en el llavero de inicio de sesión	Vuelva a implementar a nivel de dispositivo en modo de sistema
Algunos dispositivos nunca ven la red	Perfiles divididos entre grupos de dispositivos y de cuentas	El perfil falta en la lista de instalados del dispositivo	Alinee los tres payloads en un solo grupo
Rechazo de RADIUS indicando el certificado de cliente	RADIUS no confía en su CA emisora	El motivo del rechazo cita la cadena del cliente	Añada la CA emisora a la lista de confianza de RADIUS

¿Cómo averiguar qué causa tiene?

Trabaje desde el dispositivo hacia fuera, en este orden.

1. Confirme que llegaron los perfiles. Compruebe la lista de perfiles instalados en el dispositivo. En un Mac, sudo profiles show los enumera desde la Terminal.
2. Confirme el certificado y la clave privada. Abra Acceso a Llaveros en un Mac y compruebe el llavero de Sistema o de inicio de sesión frente al nivel de perfil.
3. Lea el registro de eapolclient. Esto le indicará si el dispositivo rechazó al servidor.
4. Lea el registro de RADIUS. Esto le indicará si el servidor rechazó al dispositivo.

¿Dónde están los registros de 802.1X en macOS?

macOS delega 802.1X en un proceso llamado eapolclient. Abra la Consola, seleccione el Mac, inicie la transmisión de datos y filtre por el nombre de proceso eapolclient. A continuación, reproduzca el fallo. Desde la Terminal, log show --predicate 'process == "eapolclient"' --last 1h extrae las mismas entradas.

Busque tres cosas: la identidad externa enviada, el certificado de servidor presentado y el resultado de la evaluación de confianza. Un fallo de confianza aquí significa que el problema está en su payload de WiFi. En el caso de un iPhone o iPad, conéctelo a un Mac y transmita su registro a través de la Consola.

Lo que le indica el registro de RADIUS

El registro de RADIUS es la otra mitad de la conversación.

• No se realiza ninguna solicitud. Falta el perfil, el nombre del SSID es incorrecto o el dispositivo nunca llegó al punto de acceso.
• La sesión EAP se inicia pero nunca se completa. El dispositivo rechazó el certificado del servidor. Vuelva a la configuración de confianza.
• Un rechazo explícito. El servidor rechazó el dispositivo. El motivo suele indicar una cadena de clientes no confiable, una cuenta desconocida o una discrepancia en las políticas.

¿Cómo se soluciona en Intune y en Jamf?

Ambas plataformas entregan las mismas tres cargas de Apple. Difieren en la forma en que definen su alcance y su nivel.

Tarea	Microsoft Intune	Jamf Pro
Anclaje de confianza del servidor	Perfil de certificado de confianza	Carga de certificado en el perfil de configuración
Certificado de identidad	Perfil de certificado SCEP o PKCS	Carga de certificado o SCEP
Configuración de red	Perfil de WiFi (empresa)	Carga de WiFi (móvil) o Carga de red (ordenadores)
Selección de llavero en Mac	Canal de implementación: llavero de usuario o de dispositivo	Nivel de perfil: ordenador o usuario
Conexión en la ventana de inicio de sesión	Canal de dispositivo con un certificado de máquina	Perfil a nivel de ordenador configurado para su uso en la ventana de inicio de sesión
Segmentación	Grupos de Entra ID	Grupos inteligentes y grupos estáticos

Intune

Compruebe que el certificado de confianza, el certificado y los perfiles de WiFi apunten al mismo grupo de Entra ID. En macOS, configure cada perfil en el mismo canal de implementación. Mezclar llaveros de usuario y de dispositivo rompe la referencia del certificado. En el perfil de WiFi, enumere cada nombre de servidor RADIUS en los nombres de servidor de certificados y elija la raíz correspondiente. La propia guía de implementación de Microsoft documenta cada campo.

Jamf Pro

Integre las cargas de certificado y de red en un único perfil a nivel de ordenador para los Mac compartidos. Utilice perfiles a nivel de usuario solo cuando cada persona sea propietaria del Mac. Apunte la configuración del certificado de identidad a la carga de certificado o SCEP en el mismo perfil. Para dispositivos móviles, la carga de WiFi ofrece los mismos campos de nombres de servidores de confianza y certificados de confianza.

Particularidades de iPhone y iPad

iOS e iPadOS no disponen de modo de ventana de inicio de sesión. Los fallos más comunes son las discrepancias de confianza y la falta de certificados de identidad. Los iPad compartidos y sin usuario necesitan una segmentación por grupos de dispositivos, o de lo contrario nunca recibirán el certificado.

Casos prácticos

Un hotel de 200 habitaciones tras la renovación de un certificado RADIUS

Situación. Un hotel de 200 habitaciones distribuyó iPhones gestionados por Intune a los equipos de recepción y limpieza. El certificado RADIUS se renovó con un nuevo nombre de host. A la mañana siguiente, todos los iPhone del personal perdieron la conexión a la red.

Qué se hizo. Los registros equivalentes a eapolclient de un iPhone conectado por cable mostraron que el dispositivo abandonaba el protocolo de enlace. El registro de RADIUS confirmó sesiones que se iniciaron pero nunca se completaron. El equipo añadió el nuevo nombre de host a los nombres de servidor de certificados y asignó la nueva raíz al mismo grupo. Resultado. Los dispositivos se volvieron a conectar a medida que cada uno sincronizaba el perfil actualizado, y las autenticaciones fallidas en el SSID del personal disminuyeron a cero ese mismo día. Ahora el equipo publica los cambios de confianza una semana antes de cualquier renovación. Descubra cómo los hoteles gestionan las redes de personal y de invitados en nuestra página de Hoteles.

Un servicio de biblioteca municipal con Macs compartidos

Situación. Un servicio de biblioteca del sector público gestionaba 60 Macs compartidos a través de Jamf Pro. El perfil de WiFi estaba a nivel de usuario, por lo que el certificado se guardaba en el llavero de inicio de sesión. El nuevo personal no podía iniciar sesión en absoluto, porque sus cuentas de red necesitaban primero la red.

Qué se hizo. El equipo reconstruyó el perfil a nivel de ordenador en modo de sistema, con un certificado de máquina en el llavero del sistema.

Resultado. Los Macs se conectaban a la red en la ventana de inicio de sesión, y los fallos en el primer inicio de sesión dejaron de producirse en las 60 máquinas. El mismo cambio desbloqueó los parches nocturnos, que también dependían de una sesión iniciada.

¿Cómo se puede evitar que vuelva a suceder?

La mayoría de las caídas de Apple 802.1X se producen por errores propios durante los cambios. Una disciplina sencilla previene casi todas ellas.

• Defina la confianza de forma deliberada. Especifique siempre los nombres de los servidores de confianza y una raíz de confianza, para que cualquier desajuste falle claramente en las pruebas en lugar de solicitar confirmación al personal.
• Planifique las rotaciones de certificados por fases. Añada el nuevo nombre del servidor y la raíz al perfil antes de renovar el certificado RADIUS. Elimine los antiguos después.
• Mantenga la cadena en un solo grupo. El certificado de confianza, el certificado de identidad y el perfil de WiFi deben compartir siempre el mismo destino.
• Adapte el modo al dispositivo. Los Macs compartidos utilizan el modo de sistema. Los Macs asignados de forma personal pueden utilizar el modo de usuario.
• Realice una prueba piloto primero. Envíe los cambios de perfil a un grupo reducido de iPhones y Macs, y revise los registros de eapolclient y RADIUS antes de un lanzamiento más amplio.
• Automatice las incorporaciones, cambios y bajas. La revocación de certificados debe seguir al directorio, no a una cola de tickets.

Purple Staff WiFi ofrece esto a través de Redes Basadas en la Identidad. Nuestro RADIUS en la nube vincula el acceso a la red con Microsoft Entra ID, Okta o Google Workspace, de modo que el acceso sigue a la pertenencia al grupo. Purple es independiente del hardware. Funciona en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Purple cuenta con la certificación ISO 27001 y presta servicio a más de 80.000 recintos activos (datos propios de Purple). El mismo enfoque de identidad se aplica en Comercio minorista, Sanidad y Trenes.

Para flotas de Android, la lista de verificación para la resolución de problemas de Android 802.1X y EAP-TLS cubre las comprobaciones equivalentes. Para el inicio de sesión con directorio, lea Cómo habilitar el inicio de sesión único.

Preguntas frecuentes

¿Funciona Purple Staff WiFi con dispositivos gestionados por Intune y Jamf?

Sí, Purple Staff WiFi autentica los dispositivos Apple que reciben sus perfiles de WiFi y certificados desde Intune o Jamf Pro. Su plataforma de gestión de dispositivos entrega las cargas útiles y el RADIUS en la nube de Purple valida la conexión contra Microsoft Entra ID, Okta o Google Workspace. Usted conserva sus herramientas de gestión de dispositivos existentes. Purple se encarga de la autenticación y vincula el acceso a la pertenencia a grupos, por lo que las personas que dejan la empresa pierden el acceso cuando se deshabilita su cuenta de directorio.

¿Necesitamos nuevos puntos de acceso para ejecutar un WiFi para el personal basado en certificados?

No, Purple es independiente del hardware y se superpone a su red existente. Purple es compatible con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Sus puntos de acceso deben ser compatibles con WPA2-Enterprise o WPA3-Enterprise y apuntar a un servidor RADIUS externo. Para SecurePass, consulte los requisitos de Passpoint en nuestro artículo sobre Compatibilidad de Seguridad y Hardware.

¿Deberíamos usar EAP-TLS o PEAP para iPhones y Macs en Entra ID?

Utilice EAP-TLS. PEAP-MSCHAPv2 necesita un servidor RADIUS que pueda validar la contraseña, y Entra ID no tiene un servicio RADIUS nativo para cuentas exclusivas de la nube. EAP-TLS se autentica con un certificado que Intune o Jamf entregan automáticamente, por lo que nadie tiene que escribir una contraseña. También elimina las solicitudes de credenciales, que son una de las fuentes más comunes de tickets de soporte técnico de Apple 802.1X.

¿Podemos migrar desde una clave precompartida sin interrumpir al personal?

Sí, puede ejecutar el nuevo SSID 802.1X junto con su red de clave precompartida existente durante la migración. Envíe primero el certificado de confianza, el certificado de identidad y los perfiles de WiFi a un grupo piloto. Revise los registros de eapolclient y RADIUS, y luego amplíe el alcance por etapas. Retire la red de clave precompartida solo cuando RADIUS muestre que todos los grupos de dispositivos se autentican correctamente.

¿Cómo afecta el WiFi basado en certificados al GDPR y al tratamiento de datos?

El WiFi basado en certificados reduce los datos personales que viajan por la red, ya que no se transmite ninguna contraseña. La autenticación se basa en un certificado de dispositivo y en la pertenencia a un grupo de directorio. Purple cumple con el GDPR y cuenta con las certificaciones ISO 27001, Cyber Essentials y B Corp. No obstante, debe registrar los registros de RADIUS que conserva y su período de retención en su documentación de protección de datos.

¿Reemplaza SecurePass a 802.1X para los dispositivos del personal?

No, SecurePass está diseñado para visitantes, no para dispositivos gestionados del personal. Reemplaza los inicios de sesión repetidos en el Captive Portal por un perfil de WiFi firmado digitalmente que se instala una sola vez en unos 30 segundos, utilizando WPA2 o WPA3-Enterprise. Funciona junto a su portal existente. Los dispositivos del personal deben utilizar Staff WiFi con certificados entregados por Intune o Jamf. Consulte las Preguntas Frecuentes de SecurePass para más detalles.