Resolução de problemas de 802.1X em iOS e macOS: uma lista de verificação de implementação para Intune, Jamf e Microsoft Entra ID

Os dispositivos Apple falham no 802.1X por quatro razões principais. Os nomes de servidor confiáveis ou as âncoras de certificado do payload de WiFi não correspondem ao certificado RADIUS. O certificado de identidade está em falta ou encontra-se no porta-chaves errado. Um perfil macOS é executado no modo errado ou o perfil visa o grupo do Microsoft Entra ID errado. Os registos do eapolclient e do RADIUS mostram qual.

Como se caracteriza uma falha de 802.1X num iPhone ou Mac?

Os dispositivos Apple raramente apresentam um erro preciso. O próprio sintoma é a sua primeira pista, por isso registe-o exatamente antes de alterar qualquer perfil.

• O iPhone recusa-se a aderir a uma rede EAP-TLS e solicita um nome de utilizador e palavra-passe que nunca deveriam ser necessários. O dispositivo não tem nenhum certificado de identidade utilizável, pelo que recorre a um pedido de credenciais.
• O Mac apresenta 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 liga-se após o início de sessão, mas não na janela de início de sessão. As contas de rede e os desbloqueios do FileVault falham em máquinas partilhadas.
• Alguns dispositivos funcionam e outros nunca detetam a rede. Isto normalmente aponta para o âmbito do grupo, não para a criptografia.
• Tudo funcionou durante meses e depois falhou numa manhã. Esse padrão segue quase sempre a renovação de um certificado RADIUS.

O que costuma causar a falha do EAP-TLS ou PEAP em iPhones e Macs?

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 dos certificados de servidor confiáveis devem corresponder ao nome no seu certificado de servidor RADIUS. Os certificados confiáveis devem incluir a raiz que o emitiu. Se algum estiver incorreto, o dispositivo interrompe o handshake TLS.

É por isso que o macOS lhe pede para confiar no certificado RADIUS. Sem nenhuma âncora no perfil, a Apple entrega a decisão à pessoa no teclado. Com a confiança fixada e havendo uma incompatibilidade, a ligação falha silenciosamente. O guia de confiança do servidor de perfil de WiFi do Intune aborda as regras de nomenclatura em detalhe.

O certificado de identidade está em falta ou no porta-chaves errado

O EAP-TLS necessita de um certificado de cliente e da sua chave privada no dispositivo. O payload de WiFi deve referenciar esse certificado, fornecido por um payload SCEP ou PKCS. No macOS, um perfil ao nível do dispositivo instala certificados no porta-chaves do Sistema. Um perfil ao nível do utilizador instala-os no porta-chaves de início de sessão. Uma rede configurada ao nível do dispositivo não consegue aceder a um certificado no porta-chaves de início de sessão.

Os modos de sistema, janela de início de sessão e utilizador do macOS estão misturados

O macOS suporta três contextos 802.1X. O modo de sistema liga-se antes de qualquer utilizador iniciar sessão, utilizando um certificado de máquina. O modo de janela de início de sessão utiliza as credenciais introduzidas na janela de início de sessão. O modo de utilizador liga-se apenas após o início de sessão, com credenciais ou um certificado associado a essa conta. Escolha o modo que corresponde ao momento em que o Mac necessita da rede.

Os perfis estão no âmbito do grupo errado do Microsoft Entra ID

A documentação do Intune da Microsoft indica que deve atribuir o certificado fidedigno, SCEP ou PKCS, e os perfis de 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 e Macs partilhados sem conta primária nunca recebem perfis direcionados a pessoas.

PEAP contra contas Entra ID apenas na nuvem

O PEAP-MSCHAPv2 necessita de um servidor RADIUS que possa validar a palavra-passe. O Entra ID não tem serviço RADIUS nativo, pelo que as contas apenas na nuvem normalmente não se conseguem autenticar desta forma. A maioria dos ambientes Entra ID move os dispositivos Apple para EAP-TLS por este motivo.

Sintoma	Causa mais provável	Evidência a procurar	Resolução
Diálogo de fidedignidade no Mac	Sem âncora de certificado fidedigno no perfil	o eapolclient mostra uma falha de avaliação de fidedignidade	Adicione a raiz do RADIUS como um payload de certificado fidedigno
Falha silenciosa após renovação do certificado	Os nomes dos servidores fidedignos já não coincidem	O RADIUS mostra o início da sessão EAP e, em seguida, o cliente abandona-a	Adicione o novo nome do servidor e a raiz antes de rodar
Pedido de palavra-passe na rede EAP-TLS	Certificado de identidade não entregue	Nenhum certificado de cliente no chaveiro (keychain)	Atribua o perfil SCEP ou PKCS ao mesmo grupo que o perfil de WiFi
Funciona após iniciar sessão, falha no ecrã de início de sessão	Perfil em modo de utilizador num Mac partilhado	O certificado encontra-se no chaveiro de início de sessão	Volte a implementar ao nível do dispositivo em modo de sistema
Alguns dispositivos nunca veem a rede	Perfis divididos entre grupos de dispositivos e de contas	Perfil em falta na lista de instalados do dispositivo	Alinhe os três payloads num único grupo
O RADIUS rejeita indicando o certificado do cliente	O RADIUS não confia na sua AC emissora	O motivo de rejeição cita a cadeia do cliente	Adicione a AC emissora à lista de fidedignidade do RADIUS

Como descobrir qual é a causa que tem?

Trabalhe a partir do dispositivo para fora, nesta ordem.

1. Confirme que os perfis chegaram. Verifique a lista de perfis instalados no dispositivo. Num Mac, sudo profiles show lista-os a partir do Terminal.
2. Confirme o certificado e a chave privada. Abra o Acesso a Chaveiros (Keychain Access) num Mac e verifique o chaveiro do Sistema ou de início de sessão em relação ao nível do perfil.
3. Leia o registo do eapolclient. Isto indica-lhe se o dispositivo rejeitou o servidor.
4. Leia o registo do RADIUS. Isto indica-lhe se o servidor rejeitou o dispositivo.

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

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

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

O que o registo do RADIUS lhe diz

O registo do RADIUS é a outra metade da conversa.

• Nenhum pedido. O perfil está em falta, o nome do SSID está incorreto ou o dispositivo nunca chegou ao ponto de acesso.
• A sessão EAP inicia, mas nunca é concluída. O dispositivo rejeitou o certificado do servidor. Volte às definições de fidedignidade.
• Uma rejeição explícita. O servidor rejeitou o dispositivo. O motivo geralmente aponta para uma cadeia de clientes não confiável, uma conta desconhecida ou uma incompatibilidade de políticas.

Como resolver no Intune e no Jamf?

Ambas as plataformas fornecem os mesmos três payloads Apple. Diferem na forma como os definem em termos de âmbito e de nível.

Tarefa	Microsoft Intune	Jamf Pro
Âncora de fidedignidade do servidor	Perfil de certificado fidedigno	Payload de certificado no perfil de configuração
Certificado de identidade	Perfil de certificado SCEP ou PKCS	Payload SCEP ou de Certificado
Definições de rede	Perfil de WiFi (empresarial)	Payload de WiFi (dispositivos móveis) ou Payload de Rede (computadores)
Escolha do porta-chaves Mac	Canal de implementação: porta-chaves de utilizador ou de dispositivo	Nível do perfil: computador ou utilizador
Ligação no ecrã de início de sessão	Canal de dispositivo com um certificado de máquina	Perfil ao nível do computador configurado para utilização no ecrã de início de sessão
Segmentação	Grupos do Microsoft Entra ID	Grupos inteligentes e grupos estáticos

Intune

Verifique se os perfis de certificado fidedigno, de certificado e de WiFi visam todos o mesmo grupo do Microsoft Entra ID. No macOS, configure cada perfil para o mesmo canal de implementação. Misturar porta-chaves de utilizador e de dispositivo quebra a referência do certificado. No perfil de WiFi, liste todos os nomes de servidores RADIUS nos nomes de servidores de certificados e escolha a raiz correspondente. O guia de implementação da própria Microsoft documenta cada campo.

Jamf Pro

Incorpore os payloads de certificado e de rede num único perfil ao nível do computador para Macs partilhados. Utilize perfis ao nível do utilizador apenas quando cada pessoa for proprietária do Mac. Aponte a definição do certificado de identidade para o payload SCEP ou de Certificado no mesmo perfil. Para dispositivos móveis, o payload de WiFi oferece os mesmos campos de nomes de servidores fidedignos e de certificados fidedignos.

Especificidades de iPhone e iPad

O iOS e o iPadOS não têm modo de ecrã de início de sessão. As falhas comuns são incompatibilidades de fidedignidade e certificados de identidade em falta. Os iPads partilhados e sem utilizador associado necessitam de segmentação por grupo de dispositivos, caso contrário, nunca recebem o certificado.

Cenários práticos

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

Situação. Um hotel de 200 quartos distribuiu iPhones geridos pelo Intune às equipas da receção e do serviço de quartos. O certificado RADIUS foi renovado com um novo nome de anfitrião (hostname). Na manhã seguinte, todos os iPhones dos funcionários perderam a ligação à rede.

O que foi feito. Os registos equivalentes ao eapolclient de um iPhone ligado por cabo (tethered) mostraram que o dispositivo abandonava o handshake. O registo do RADIUS confirmou sessões que eram iniciadas mas nunca concluídas. A equipa adicionou o novo nome de anfitrião aos nomes de servidores de certificados e atribuiu a nova raiz ao mesmo grupo. Resultado. Os dispositivos voltaram a ligar-se à medida que cada um sincronizava o perfil atualizado, e as falhas de autenticação no SSID da equipa caíram para zero nesse dia. A equipa agora publica as alterações de fidedignidade uma semana antes de qualquer renovação. Veja como os hotéis gerem redes de equipa e de convidados na nossa página de Hotéis.

Um serviço de biblioteca municipal com Macs partilhados

Situação. Um serviço de biblioteca do setor público geria 60 Macs partilhados através do Jamf Pro. O perfil de WiFi era ao nível do utilizador, pelo que o certificado ficava guardado no porta-chaves de início de sessão. Os novos funcionários não conseguiam iniciar sessão de todo, porque as suas contas de rede precisavam primeiro de aceder à rede.

O que foi feito. A equipa reconstruiu o perfil ao nível do computador em modo de sistema, com um certificado de máquina no porta-chaves do Sistema.

Resultado. Os Macs acederam à rede logo na janela de início de sessão, e as falhas no primeiro início de sessão cessaram em todas as 60 máquinas. A mesma alteração desbloqueou a aplicação de correções durante a noite, que também dependia de uma sessão com início efetuado.

Como evitar que isto volte a acontecer?

A maioria das falhas de Apple 802.1X é auto-infligida durante as alterações. Uma disciplina simples previne quase todas.

• Defina a fidedignidade deliberadamente. Especifique sempre os nomes de servidores fidedignos e uma raiz fidedigna, para que uma incompatibilidade falhe visivelmente nos testes em vez de solicitar uma ação à equipa.
• Planeie as rotações de certificados por fases. Adicione o novo nome de servidor e a raiz ao perfil antes de renovar o certificado RADIUS. Remova os antigos posteriormente.
• Mantenha a cadeia num único grupo. O certificado fidedigno, o certificado de identidade e o perfil de WiFi devem partilhar sempre o mesmo destino.
• Adapte o modo ao dispositivo. Os Macs partilhados utilizam o modo de sistema. Os Macs atribuídos pessoalmente podem utilizar o modo de utilizador.
• Faça um projeto-piloto primeiro. Envie as alterações de perfil para um pequeno grupo de iPhones e Macs, e verifique os registos do eapolclient e do RADIUS antes de um lançamento mais alargado.
• Automatize entradas, transferências e saídas. A revogação de certificados deve seguir o diretório, e não uma fila de suporte técnico.

O Purple Staff WiFi oferece isto através de Redes Baseadas em Identidade. O nosso RADIUS na nuvem associa o acesso à rede ao Microsoft Entra ID, Okta ou Google Workspace, para que o acesso siga a pertença a grupos. O Purple é agnóstico em relação ao hardware. Funciona em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O Purple possui a certificação ISO 27001 e serve mais de 80.000 locais ativos (dados do próprio Purple). A mesma abordagem de identidade aplica-se aos setores de Retalho, Saúde e Comboios.

Para frotas Android, o guia de resolução de problemas de Android 802.1X e EAP-TLS abrange as verificações equivalentes. Para início de sessão por diretório, leia Como Ativar o Single Sign On.

Perguntas frequentes

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

Sim, o Purple Staff WiFi autentica dispositivos Apple que recebem os seus perfis de WiFi e certificado a partir do Intune ou Jamf Pro. A sua plataforma de gestão de dispositivos fornece os payloads, e o cloud RADIUS da Purple valida a ligação face ao Microsoft Entra ID, Okta ou Google Workspace. Mantém as suas ferramentas de gestão de dispositivos existentes. A Purple trata da autenticação e associa o acesso à pertença a grupos, para que os colaboradores que saem percam o acesso quando a sua conta de diretório for desativada.

Precisamos de novos pontos de acesso para executar o WiFi de colaboradores baseado em certificados?

Não, a Purple é agnóstica em termos de hardware e funciona sobre a sua rede existente. A Purple suporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Os seus pontos de acesso precisam de suportar WPA2-Enterprise ou WPA3-Enterprise e apontar para um servidor RADIUS externo. Para o SecurePass, verifique os requisitos Passpoint no nosso artigo sobre Compatibilidade de Segurança e Hardware.

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

Utilize EAP-TLS. O PEAP-MSCHAPv2 necessita de um servidor RADIUS que possa validar a palavra-passe, e o Entra ID não tem um serviço RADIUS nativo para contas exclusivamente na cloud. O EAP-TLS autentica-se com um certificado que o Intune ou Jamf fornece automaticamente, para que ninguém tenha de digitar uma palavra-passe. Também elimina as solicitações de credenciais, que são uma das fontes mais comuns de pedidos de suporte de 802.1X da Apple.

Podemos migrar de uma chave pré-partilhada sem perturbar os colaboradores?

Sim, pode executar o novo SSID 802.1X em paralelo com a sua rede de chave pré-partilhada existente durante a migração. Implemente primeiro o certificado fidedigno, o certificado de identidade e os perfis de WiFi num grupo-piloto. Verifique os registos do eapolclient e do RADIUS e, em seguida, alargue o âmbito por fases. Desative a rede de chave pré-partilhada apenas quando o RADIUS mostrar que todos os grupos de dispositivos se estão a autenticar com sucesso.

Como é que o WiFi baseado em certificados afeta o GDPR e o tratamento de dados?

O WiFi baseado em certificados reduz os dados pessoais que cruzam a rede, porque não é transmitida nenhuma palavra-passe. A autenticação baseia-se num certificado de dispositivo e na pertença a um grupo de diretório. A Purple está em conformidade com o GDPR e possui as certificações ISO 27001, Cyber Essentials e B Corp. Deve, ainda assim, registar os relatórios do RADIUS que retém e o respetivo período de retenção na sua documentação de proteção de dados.

O SecurePass substitui o 802.1X para dispositivos de colaboradores?

Não, o SecurePass foi concebido para visitantes, não para dispositivos geridos de colaboradores. Substitui os inícios de sessão repetidos no Captive Portal por um perfil de WiFi assinado digitalmente, instalado uma única vez em cerca de 30 segundos, utilizando WPA2 ou WPA3-Enterprise. Funciona em paralelo com o seu portal existente. Os dispositivos dos colaboradores devem utilizar o Staff WiFi com certificados fornecidos pelo Intune ou Jamf. Consulte as Perguntas Frequentes sobre o SecurePass para obter mais detalhes.