Solução de problemas de 802.1X no iOS e macOS: um checklist de implantação para Intune, Jamf e Microsoft Entra ID

Dispositivos Apple falham no 802.1X por quatro motivos principais. Os nomes de servidores confiáveis ou as âncoras de certificado do payload de WiFi não correspondem ao certificado RADIUS. O certificado de identidade está ausente ou reside na keychain errada. Um perfil do macOS é executado no modo errado, ou o perfil tem como alvo o grupo incorreto do Entra ID. Os logs do eapolclient e do RADIUS mostram qual é o caso.

Como se parece uma falha de 802.1X em um iPhone ou Mac?

Dispositivos Apple raramente fornecem um erro preciso. O sintoma em si é a sua primeira pista, por isso registre-o com precisão antes de alterar qualquer perfil.

• O iPhone se recusa a conectar a uma rede EAP-TLS e solicita um nome de usuário e senha que nunca deveriam ser necessários. O dispositivo não possui um certificado de identidade utilizável, então ele recorre a uma solicitação de credenciais.
• O Mac exibe uma caixa de diálogo de confiança de certificado nomeando o seu servidor RADIUS. O perfil não fixa a confiança do servidor ou permite que a pessoa ignore uma incompatibilidade.
• O Mac conecta após o login, mas não na tela de login. Contas de rede e desbloqueios do FileVault falham em máquinas compartilhadas.
• Alguns dispositivos funcionam e outros nunca detectam a rede. Isso geralmente aponta para o escopo do grupo, não para a criptografia.
• Tudo funcionou por meses e falhou em uma manhã. Esse padrão quase sempre ocorre após uma renovação de certificado RADIUS.

O que geralmente faz com que iPhones e Macs falhem no EAP-TLS ou PEAP?

A confiança do servidor não corresponde ao certificado RADIUS

O payload de WiFi da Apple fixa a confiança do servidor em dois locais. Os nomes de certificados de servidores confiáveis devem corresponder ao nome no certificado do seu servidor RADIUS. Os certificados confiáveis devem incluir a raiz que o emitiu. Se algum deles estiver incorreto, o dispositivo interrompe o handshake TLS.

É por isso que o macOS solicita que você confie no certificado RADIUS. Sem uma âncora no perfil, a Apple transfere a decisão para a pessoa no teclado. Com a confiança fixada e ocorrendo uma incompatibilidade, a conexão falha silenciosamente. O guia de confiança de servidor de perfil de WiFi do Intune aborda as regras de nomenclatura detalhadamente.

O certificado de identidade está ausente ou na keychain errada

O EAP-TLS precisa de um certificado de cliente e de sua chave privada no dispositivo. O payload de WiFi deve referenciar esse certificado, fornecido por um payload SCEP ou PKCS. No macOS, um perfil em nível de dispositivo instala certificados na keychain do Sistema. Um perfil em nível de usuário os instala na keychain de login. Uma rede configurada em nível de dispositivo não consegue acessar um certificado na keychain de login.

Os modos de sistema, tela de login e usuário do macOS estão misturados

O macOS suporta três contextos 802.1X. O Modo de sistema conecta antes de qualquer pessoa fazer login, usando um certificado de máquina. O Modo de tela de login usa as credenciais digitadas na janela de login. O Modo de usuário conecta apenas após o login, com credenciais ou um certificado associado a essa conta. Escolha o modo que corresponda ao momento em que o Mac precisa da rede.

Os perfis estão no escopo do grupo incorreto do Entra ID

A documentação do Intune da Microsoft orienta atribuir os perfis de certificado confiável, SCEP ou PKCS, e WiFi aos mesmos grupos. Atribua um a um grupo de dispositivos e outro a um grupo de contas de funcionários, e alguns dispositivos receberão apenas metade da cadeia. iPads compartilhados e Macs sem conta primária nunca recebem perfis direcionados a pessoas.

PEAP contra contas apenas em nuvem do Entra ID

O PEAP-MSCHAPv2 precisa de um servidor RADIUS que possa validar a senha. O Entra ID não possui serviço RADIUS nativo, portanto, contas apenas em nuvem geralmente não conseguem se autenticar dessa forma. A maioria dos ambientes do Entra ID migra dispositivos Apple para EAP-TLS por esse motivo.

Sintoma	Causa mais provável	Evidência a procurar	Correção
Diálogo de confiança no Mac	Nenhuma âncora de certificado confiável no perfil	eapolclient mostra uma falha de avaliação de confiança	Adicione a raiz RADIUS como um payload de certificado confiável
Falha silenciosa após renovação do certificado	Nomes de servidores confiáveis não coincidem mais	O RADIUS mostra o início da sessão EAP e, em seguida, o cliente a abandona	Adicione o novo nome do servidor e a raiz antes de alternar
Solicitação de senha na rede EAP-TLS	Certificado de identidade não entregue	Nenhum certificado de cliente no chaveiro	Atribua o perfil SCEP ou PKCS ao mesmo grupo do perfil WiFi
Funciona após o login, falha na janela de login	Perfil em modo de usuário em um Mac compartilhado	O certificado reside no chaveiro de login	Implante novamente no nível do dispositivo em modo de sistema
Alguns dispositivos nunca veem a rede	Perfis divididos entre grupos de dispositivos e contas	Perfil ausente da lista de instalados do dispositivo	Alinhe todos os três payloads a um único grupo
Rejeição do RADIUS citando o certificado do cliente	O RADIUS não confia na sua CA emissora	O motivo da rejeição cita a cadeia do cliente	Adicione a CA emissora à lista de confiança do RADIUS

Como você descobre qual é a causa?

Trabalhe a partir do dispositivo para fora, nesta ordem.

1. Confirme se os perfis chegaram. Verifique a lista de perfis instalados no dispositivo. Em um Mac, o comando sudo profiles show lista-os a partir do Terminal.
2. Confirme o certificado e a chave privada. Abra o Acesso às Chaves em um Mac e verifique as Chaves do Sistema ou de login em relação ao nível do perfil.
3. Leia o log do eapolclient. Isso informa se o dispositivo rejeitou o servidor.
4. Leia o log do RADIUS. Isso informa se o servidor rejeitou o dispositivo.

Onde estão os logs do 802.1X no macOS?

O macOS entrega o 802.1X para um processo chamado eapolclient. Abra o Console, selecione o Mac, inicie a transmissão e filtre pelo nome do processo eapolclient. Em seguida, reproduza a falha. A partir do Terminal, o comando log show --predicate 'process == "eapolclient"' --last 1h extrai as mesmas entradas.

Procure por três coisas: a identidade externa enviada, o certificado do servidor apresentado e o resultado da avaliação de confiança. Uma falha de confiança aqui significa que o problema está no seu payload de WiFi. Para um iPhone ou iPad, conecte-o a um Mac e transmita seu log através do Console.

O que o log do RADIUS diz a você

O log do RADIUS é a outra metade da conversa.

• Nenhuma solicitação é feita. O perfil está ausente, o nome do SSID está incorreto ou o dispositivo nunca alcançou o ponto de acesso.
• A sessão EAP é iniciada, mas nunca é concluída. O dispositivo rejeitou o certificado do servidor. Volte para as configurações de confiança.
• Uma rejeição explícita. O servidor rejeitou o dispositivo. O motivo geralmente aponta para uma cadeia de cliente não confiável, uma conta desconhecida ou uma incompatibilidade de política.

Como corrigir isso no Intune e no Jamf?

Ambas as plataformas entregam as mesmas três payloads da Apple. Elas diferem na forma como definem o escopo e o nível de cada uma.

Tarefa	Microsoft Intune	Jamf Pro
Âncora de confiança do servidor	Perfil de certificado confiável	Payload de certificado no perfil de configuração
Certificado de identidade	Perfil de certificado SCEP ou PKCS	SCEP ou Payload de certificado
Configurações de rede	Perfil WiFi (corporativo)	Payload WiFi (dispositivos móveis) ou Payload de rede (computadores)
Escolha de keychain do Mac	Canal de implantação: keychain do usuário ou do dispositivo	Nível do perfil: computador ou usuário
Conexão na tela de login	Canal do dispositivo com um certificado de máquina	Perfil em nível de computador configurado para uso na tela de login
Direcionamento	Grupos do Microsoft Entra ID	Grupos inteligentes e grupos estáticos

Intune

Verifique se os perfis de certificado confiável, de certificado e de WiFi estão todos direcionados ao mesmo grupo do Microsoft Entra ID. No macOS, configure cada perfil para o mesmo canal de implantação. Misturar keychains de usuário e de dispositivo quebra a referência do certificado. No perfil WiFi, liste o nome de cada servidor RADIUS nos nomes de servidores de certificados e escolha a raiz correspondente. A própria documentação de orientação de implantação da Microsoft detalha cada campo.

Jamf Pro

Incorpore as payloads de certificado e de rede em um único perfil em nível de computador para Macs compartilhados. Use perfis em nível de usuário apenas quando cada pessoa for proprietária do Mac. Aponte a configuração do certificado de identidade para o SCEP ou para o Payload de certificado no mesmo perfil. Para dispositivos móveis, o payload WiFi oferece os mesmos campos de nomes de servidores confiáveis e certificados confiáveis.

Especificidades de iPhone e iPad

O iOS e o iPadOS não possuem modo de tela de login. As falhas mais comuns são incompatibilidades de confiança e ausência de certificados de identidade. iPads compartilhados e sem usuário associado precisam de direcionamento por grupo de dispositivos, caso contrário, nunca receberão o certificado.

Cenários práticos

Um hotel de 200 quartos após a renovação de um certificado RADIUS

Situação. Um hotel de 200 quartos distribuiu iPhones gerenciados pelo Intune para as equipes da recepção e da governança. O certificado RADIUS foi renovado com um novo hostname. Na manhã seguinte, todos os iPhones dos funcionários se desconectaram da rede.

O que foi feito. Os logs equivalentes ao eapolclient de um iPhone conectado via cabo mostraram o dispositivo abandonando o handshake. O log do RADIUS confirmou sessões que eram iniciadas, mas nunca concluídas. A equipe adicionou o novo hostname aos nomes de servidores de certificados e atribuiu a nova raiz ao mesmo grupo.

Resultado. Os dispositivos se reconectaram à medida que cada um sincronizava o perfil atualizado, e as falhas de autenticação no SSID da equipe caíram para zero naquele dia. A equipe agora publica as alterações de confiança uma semana antes de qualquer renovação. Veja como os hotéis gerenciam redes de funcionários e convidados em nossa página de Hotéis.

Um serviço de biblioteca municipal com Macs compartilhados

Situação. Um serviço de biblioteca do setor público gerenciava 60 Macs compartilhados por meio do Jamf Pro. O perfil de WiFi era de nível de usuário, portanto, o certificado ficava nas chaves de login. Os novos funcionários não conseguiam iniciar sessão de forma alguma, pois suas contas de rede precisavam da rede primeiro.

O que foi feito. A equipe recriou o perfil no nível do computador no modo de sistema, com um certificado de máquina nas chaves do Sistema.

Resultado. Os Macs alcançaram a rede na janela de login, e as falhas de primeiro login cessaram em todas as 60 máquinas. A mesma alteração desbloqueou as atualizações noturnas, que também dependiam de uma sessão com login iniciado.

Como evitar que isso aconteça novamente?

A maioria das interrupções de 802.1X da Apple é causada por falhas internas durante as alterações. Uma disciplina simples evita quase todas elas.

• Defina a confiança deliberadamente. Sempre especifique nomes de servidores confiáveis e uma raiz confiável, para que uma incompatibilidade falhe visivelmente nos testes em vez de solicitar ação dos funcionários.
• Planeje as rotações de certificados por etapas. Adicione o novo nome do servidor e a raiz ao perfil antes de renovar o certificado RADIUS. Remova os antigos posteriormente.
• Mantenha a cadeia em um único grupo. O certificado confiável, o certificado de identidade e o perfil de WiFi devem sempre compartilhar o mesmo destino.
• Combine o modo com o dispositivo. Macs compartilhados usam o modo de sistema. Macs atribuídos pessoalmente podem usar o modo de usuário.
• Faça um piloto primeiro. Envie as alterações de perfil para um grupo pequeno de iPhones e Macs e verifique os logs do eapolclient e do RADIUS antes de uma distribuição mais ampla.
• Automatize novos funcionários, transferências e desligamentos. A revogação de certificados deve seguir o diretório, não uma fila de chamados.

O Purple Staff WiFi oferece isso por meio de Redes Baseadas em Identidade. Nosso RADIUS em nuvem vincula o acesso à rede ao Microsoft Entra ID, Okta ou Google Workspace, de modo que o acesso segue a associação ao grupo. A Purple é agnóstica em relação ao hardware. Ela roda em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A Purple possui certificação ISO 27001 e atende a mais de 80.000 locais ativos (dados próprios da Purple). A mesma abordagem de identidade se aplica aos setores de Varejo, Saúde e Trens.

Para frotas Android, a lista de verificação de solução de problemas do Android 802.1X e EAP-TLS aborda as verificações equivalentes. Para login via diretório, leia Como habilitar o Logon Único.

Perguntas frequentes

O Purple Staff WiFi funciona com dispositivos gerenciados pelo Intune e Jamf?

Sim, o Purple Staff WiFi autentica dispositivos Apple que recebem seus perfis de WiFi e certificados do Intune ou Jamf Pro. Sua plataforma de gerenciamento de dispositivos entrega as cargas de dados e o RADIUS em nuvem do Purple valida a conexão em relação ao Microsoft Entra ID, Okta ou Google Workspace. Você mantém suas ferramentas existentes de gerenciamento de dispositivos. O Purple lida com a autenticação e vincula o acesso à associação ao grupo, para que os desligados percam o acesso quando sua conta de diretório for desativada.

Precisamos de novos pontos de acesso para executar o WiFi corporativo baseado em certificado?

Não, o Purple é agnóstico em relação ao hardware e funciona em cima de sua rede existente. O Purple oferece suporte para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Seus pontos de acesso precisam suportar WPA2-Enterprise ou WPA3-Enterprise e apontar para um servidor RADIUS externo. Para o SecurePass, verifique os requisitos do Passpoint em nosso artigo de Compatibilidade de Hardware e Segurança.

Devemos usar EAP-TLS ou PEAP para iPhones e Macs no Entra ID?

Use EAP-TLS. O PEAP-MSCHAPv2 precisa de um servidor RADIUS que possa validar a senha, e o Entra ID não possui serviço RADIUS nativo para contas exclusivas em nuvem. O EAP-TLS autentica com um certificado que o Intune ou o Jamf entrega automaticamente, para que ninguém precise digitar uma senha. Ele também elimina solicitações de credenciais, que são uma das fontes mais comuns de chamados de suporte Apple 802.1X.

Podemos migrar de uma chave pré-compartilhada sem interromper a equipe?

Sim, você pode executar o novo SSID 802.1X junto com sua rede de chave pré-compartilhada existente durante a migração. Envie o certificado confiável, o certificado de identidade e os perfis de WiFi para um grupo de pilotos primeiro. Verifique os logs do eapolclient e do RADIUS e, em seguida, amplie o escopo em etapas. Desative a rede de chave pré-compartilhada somente quando o RADIUS mostrar que cada grupo de dispositivos está se autenticando com sucesso.

Como o WiFi baseado em certificado afeta a GDPR e o tratamento de dados?

O WiFi baseado em certificado reduz os dados pessoais que trafegam pela rede, porque nenhuma senha é transmitida. A autenticação depende de um certificado de dispositivo e da associação ao grupo de diretórios. O Purple está em conformidade com a GDPR e possui as certificações ISO 27001, Cyber Essentials e B Corp. Você ainda deve registrar os logs do RADIUS que retém e seu período de retenção na documentação de proteção de dados.

O SecurePass substitui o 802.1X para dispositivos de funcionários?

Não, o SecurePass foi projetado para visitantes, não para dispositivos gerenciados de funcionários. Ele substitui os logins repetidos no Captive Portal por um perfil de WiFi assinado digitalmente, instalado uma única vez em cerca de 30 segundos, usando WPA2 ou WPA3-Enterprise. Ele roda ao lado do seu portal existente. Os dispositivos dos funcionários devem usar o Staff WiFi com certificados entregues pelo Intune ou Jamf. Consulte as Perguntas Frequentes do SecurePass para obter detalhes.