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

Los dispositivos Apple presentan fallas en 802.1X por cuatro razones principales. Los nombres de servidores de confianza de la carga útil de WiFi o los anclajes de certificados no coinciden con el certificado RADIUS. El certificado de identidad falta 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 estas es la causa.

¿Cómo se ve una falla 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, así que regístrelo 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 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.
• La Mac muestra un cuadro de diálogo de confianza de certificado que menciona su servidor RADIUS. El perfil no define la confianza del servidor o permite que el usuario omita una discrepancia.
• La 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 detectan la red. Esto generalmente se debe al alcance del grupo, no a la criptografía.
• Todo funcionó durante meses y luego falló una mañana. Ese patrón casi siempre ocurre después de una renovación de certificado RADIUS.

¿Qué causa normalmente 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 define 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 lo emitió. Si alguno de los dos es incorrecto, el dispositivo detiene el protocolo de enlace TLS.

Es por esto que macOS le solicita que confíe en el certificado RADIUS. Sin un anclaje en el perfil, Apple deja la decisión en manos del usuario. Con la confianza definida y una discrepancia, la conexión falla de forma silenciosa en su lugar. La guía de confianza del servidor de perfil de WiFi de Intune cubre las reglas de nomenclatura a detalle.

El certificado de identidad falta o está en el llavero incorrecto

EAP-TLS requiere 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 SCEP o PKCS. En macOS, un perfil a nivel de dispositivo instala certificados en el llavero del Sistema. Un perfil a nivel de usuario los instala en el llavero de inicio de sesión. 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 de usuario de macOS están mezclados

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

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

La documentación de Intune de Microsoft indica 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 recibirán solo la mitad de la cadena. Los iPads y Macs compartidos sin una cuenta principal nunca reciben perfiles dirigidos a personas.

PEAP contra 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 esta razón.

Síntoma	Causa más probable	Evidencia a buscar	Solución
Diálogo de confianza en Mac	No hay un anclaje de certificado de confianza en el perfil	eapolclient muestra una falla de evaluación de confianza	Agregue la raíz RADIUS como una carga útil de certificado de confianza
Falla silenciosa tras la renovación del certificado	Los nombres de servidores de confianza ya no coinciden	RADIUS muestra el inicio de la sesión EAP, luego el cliente la abandona	Agregue 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 WiFi
Funciona tras iniciar sesión, falla en la ventana de inicio de sesión	Perfil en modo de usuario en una Mac compartida	El certificado reside 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 cuentas	El perfil no aparece en la lista de instalados del dispositivo	Alinee las tres cargas útiles a un solo grupo
Rechazo de RADIUS nombrando el certificado de cliente	RADIUS no confía en su CA emisora	La razón de rechazo cita la cadena del cliente	Agregue la CA emisora a la lista de confianza de RADIUS

¿Cómo determinar cuál es la causa en su caso?

Trabaje desde el dispositivo hacia afuera, en este orden.

1. Confirme que llegaron los perfiles. Revise la lista de perfiles instalados en el dispositivo. En una Mac, sudo profiles show los enumera desde la Terminal.
2. Confirme el certificado y la clave privada. Abra Acceso a Llaveros en una Mac y revise el llavero del Sistema o de inicio de sesión contra el nivel del 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 entrega 802.1X a un proceso llamado eapolclient. Abra la Consola, seleccione la Mac, comience a transmitir y filtre por el nombre del proceso eapolclient. Luego reproduzca la falla. 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. Una falla de confianza aquí significa que el problema está en su carga útil de WiFi. Para un iPhone o iPad, conéctelo a una 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.

• Sin solicitud alguna. 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. Regrese 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 de políticas.

¿Cómo solucionarlo en Intune y en Jamf?

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

Tarea	Microsoft Intune	Jamf Pro
Ancla de confianza del servidor	Perfil de certificado de confianza	Carga de datos del certificado en el perfil de configuración
Certificado de identidad	Perfil de certificado SCEP o PKCS	SCEP o carga de datos de certificado
Configuración de red	Perfil de WiFi (empresarial)	Carga de datos de WiFi (móvil) o carga de datos de red (computadoras)
Selección de llavero en Mac	Canal de implementación: llavero de usuario o de dispositivo	Nivel de perfil: computadora 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 computadora 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

Verifique que el certificado de confianza, el certificado y los perfiles de WiFi apunten al mismo grupo de Entra ID. En macOS, configure todos los perfiles 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 guía de implementación propia de Microsoft documenta cada campo.

Jamf Pro

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

Particularidades de iPhone y iPad

iOS y iPadOS no tienen modo de ventana de inicio de sesión. Las fallas comunes son discrepancias de confianza y la falta de certificados de identidad. Los iPads compartidos y sin usuario necesitan una segmentación por grupo de dispositivos, o de lo contrario nunca recibirán el certificado.

Escenarios de ejemplo

Un hotel de 200 habitaciones después de la renovación de un certificado RADIUS

Situación. Un hotel de 200 habitaciones distribuyó iPhones administrados 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 iPhones del personal se desconectaron de la red.

Qué se hizo. Los registros equivalentes a eapolclient de un iPhone conectado por cable mostraron que el dispositivo abandonaba el saludo de conexión. El registro de RADIUS confirmó sesiones que se iniciaron y nunca se completaron. El equipo agregó 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 reconectaron a medida que cada uno sincronizaba el perfil actualizado, y las autenticaciones fallidas en la SSID del personal cayeron 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 huéspedes en nuestra página de Hoteles.

Un servicio de biblioteca municipal con Macs compartidas

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

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

Resultado. Las Macs se conectaron a la red en la ventana de inicio de sesión, y los fallos en el primer inicio de sesión se detuvieron en las 60 máquinas. El mismo cambio desbloqueó la aplicación de parches nocturnos, que también dependía de una sesión con inicio de sesión activo.

¿Cómo evitar que vuelva a suceder?

La mayoría de las interrupciones de Apple 802.1X son autoinfligidas durante los cambios. Una disciplina sencilla previene casi todas.

• Defina la confianza de forma deliberada. Especifique siempre los nombres de servidores confiables y una raíz confiable, de modo que cualquier discrepancia falle de manera evidente en las pruebas en lugar de solicitar confirmación al personal.
• Organice las rotaciones de certificados por etapas. Agregue el nuevo nombre de servidor y la raíz al perfil antes de renovar el certificado RADIUS. Elimine los anteriores después.
• Mantenga la cadena en un solo grupo. El certificado de confianza, el certificado de identidad y el perfil de WiFi siempre deben compartir el mismo objetivo.
• Adapte el modo al dispositivo. Las Macs compartidas utilizan el modo de sistema. Las Macs asignadas personalmente pueden utilizar el modo de usuario.
• Realice una prueba piloto primero. Aplique los cambios de perfil a un grupo pequeño de iPhones y Macs, y revise los registros de eapolclient y RADIUS antes de un lanzamiento más amplio.
• Automatice las altas, traslados y bajas. La revocación de certificados debe seguir al directorio, no a una cola de tickets de soporte.

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 de 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 brinda servicio a más de 80,000 establecimientos activos (datos propios de Purple). El mismo enfoque de identidad se aplica en los sectores de Retail, Salud 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 verificaciones equivalentes. Para el inicio de sesión mediante 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 con Microsoft Entra ID, Okta o Google Workspace. Usted conserva sus herramientas existentes de gestión de dispositivos. Purple se encarga de la autenticación y vincula el acceso a la membresía del grupo, de modo que quienes dejen la empresa pierdan el acceso cuando se deshabilite su cuenta de directorio.

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

No, Purple es independiente del hardware y se integra sobre 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 admitir 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 exclusivamente en la nube. EAP-TLS se autentica con un certificado que Intune o Jamf entregan de forma automática, por lo que nadie escribe 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. Verifique los registros de eapolclient y RADIUS, y luego amplíe el alcance por etapas. Retire la red de clave precompartida únicamente cuando RADIUS muestre que todos los grupos de dispositivos se están autenticando correctamente.

¿Cómo afecta el WiFi basado en certificados a GDPR y al manejo 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 membresía de un grupo de directorio. Purple cumple con GDPR y cuenta con las certificaciones ISO 27001, Cyber Essentials y B Corp. Aun así, debe registrar los registros de RADIUS que conserva y su periodo de retención en su documentación de protección de datos.

¿SecurePass reemplaza 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 con un perfil de WiFi firmado digitalmente que se instala una sola vez en unos 30 segundos, utilizando WPA2 o WPA3-Enterprise. Funciona junto con su portal existente. Los dispositivos del personal deben usar Staff WiFi con certificados entregados por Intune o Jamf. Consulte las Preguntas frecuentes de SecurePass para obtener más detalles.