Solução de problemas de Android 802.1X e EAP-TLS: uma checklist de implantação para Intune e Microsoft Entra ID

Celulares Android gerenciados geralmente falham no EAP-TLS por um de quatro motivos. O perfil de WiFi não possui um certificado CA ou domínio, então o Android rejeita o servidor RADIUS. O certificado do cliente está em um perfil diferente. O campo de nomes do servidor RADIUS não coincide com o certificado do servidor. Ou o perfil de raiz confiável nunca chegou ao dispositivo.

Como é uma falha de EAP-TLS no Android?

O EAP-TLS (Extensible Authentication Protocol com Transport Layer Security) autentica um dispositivo com um certificado em vez de uma senha. Ele roda dentro do IEEE 802.1X, o padrão de controle de acesso baseado em porta. O 802.1X entrega a autenticação para um servidor RADIUS (Remote Authentication Dial-In User Service).

Quando isso falha no Android, você normalmente verá um destes sintomas:

• A rede aparece na lista, mas nunca passa de "Conectando", depois volta para "Salva".
• O dispositivo mostra um erro de autenticação genérico. A redação varia de acordo com o fabricante.
• A rede funciona em aparelhos Samsung, mas não no Google Pixel, ou vice-versa.
• A rede funciona em celulares corporativos, mas falha em dispositivos pessoais inscritos com um perfil de trabalho.
• Nada aparece nos seus logs do RADIUS.

Esse último sintoma é o mais importante. Um dispositivo que nunca alcança o RADIUS tem um problema de perfil, não um problema de autenticação.

O que geralmente causa falhas de EAP-TLS no Android?

Validação de servidor mais rigorosa em versões recentes do Android

As versões recentes do Android removeram a opção "Não validar" para novas redes corporativas. O Android agora precisa de duas coisas antes de enviar seu certificado: um certificado CA para confiar e um domínio para corresponder.

Sem ambos, o dispositivo se recusa a concluir o handshake TLS. Perfis que funcionaram por anos em versões mais antigas podem falhar assim que um dispositivo recebe uma atualização do sistema operacional.

Certificado no perfil de trabalho, rede conectada pelo lado pessoal

O Android Enterprise separa o perfil de trabalho do lado pessoal, e cada um tem seu próprio repositório de certificados. O Intune instala o certificado do cliente e a raiz confiável no perfil de trabalho. Um funcionário que adiciona o SSID manualmente a partir das configurações pessoais não consegue acessar esses certificados, fazendo com que a autenticação falhe.

O campo de nomes do servidor RADIUS

O perfil de WiFi do Android Enterprise no Intune inclui um campo de nomes de servidor RADIUS. A documentação da Microsoft solicita o nome DNS no certificado que seu servidor RADIUS apresenta. O Android coloca esse valor em seu campo de domínio e o compara com o certificado do servidor. Se o campo estiver em branco, incorreto ou contiver um endereço IP, a validação falhará.

O perfil de raiz confiável

O perfil de WiFi aponta para um perfil de certificado confiável separado do Intune. Esse perfil deve conter a CA raiz que emitiu o certificado do servidor RADIUS. Um erro comum é implantar a raiz atrás dos seus certificados de cliente quando uma CA diferente assinou o certificado do servidor. Os dois perfis também devem ter como alvo os mesmos grupos e o mesmo tipo de inscrição do Android Enterprise.

Diferenças entre fabricantes

As versões da Samsung, Google Pixel e de outros fabricantes rotulam e organizam as configurações de WiFi corporativo de forma diferente. Algumas mostram opções extras, como verificações de status de certificados online. Use os dispositivos da sua própria frota como referência, não capturas de tela de outra marca.

Como identificar a causa do problema?

Comece pelo dispositivo e depois confirme nos logs do RADIUS. O padrão nos logs geralmente aponta para a causa.

Sintoma	O que o RADIUS mostra	Causa provável	Primeira solução
Nenhuma tentativa chega ao RADIUS	Nenhuma solicitação do dispositivo	Perfil de WiFi não aplicado ou divergência no nome do SSID	Verifique o status do perfil por dispositivo no Intune
O handshake para após o servidor enviar seu certificado	Alerta TLS do cliente, como "CA desconhecida" (unknown CA)	Raiz confiável incorreta ou ausente, ou divergência de domínio	Implante a CA raiz do servidor e os nomes de servidor RADIUS corretos
O handshake é concluído no lado do servidor e depois falha	Nenhum certificado de cliente apresentado	Certificado SCEP ou PKCS ausente ou no perfil errado	Confirme se o perfil de certificado foi bem-sucedido para esse dispositivo
Certificado aceito e depois rejeitado	Access-Reject após a validação do certificado	Mapeamento de identidade, revogação ou regra de política	Verifique o assunto do certificado ou SAN em relação ao provedor de identidade
Falha apenas em dispositivos pessoais	Nenhuma solicitação ou nenhum certificado de cliente	SSID conectado a partir do perfil pessoal	Implante o perfil no perfil de trabalho e impeça conexões manuais

Leia a falha no dispositivo

No centro de administração do Microsoft Intune, abra o dispositivo e verifique o status de cada perfil de configuração. Um perfil de WiFi mostrado como pendente ou com erro nunca chegou ao dispositivo. Um perfil de certificado com erro significa que a emissão do SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards) falhou. Corrija isso antes de mexer na rede.

Em dispositivos de laboratório, os logs do Android Debug Bridge do suplicante WiFi mostram o alerta TLS exato. Use isso para um aparelho de teste, não para uma frota de produção.

Leia os logs do RADIUS

As plataformas FreeRADIUS, Microsoft Network Policy Server e RADIUS na nuvem registram onde a troca EAP parou. Pesquise pelo endereço MAC do dispositivo ou pela identidade do certificado. Um alerta TLS enviado pelo cliente significa que o telefone rejeitou seu servidor. Um Access-Reject após um certificado válido significa que seu servidor rejeitou o telefone.

Se os dispositivos se autenticam e depois caem conforme os funcionários andam entre os andares, a causa é diferente. Leia Resolving Roaming Issues in Corporate WLANs. As desconexões que coincidem com mudanças de canal apontam para eventos de radar. Consulte DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Como corrigir isso no Intune e em cada versão do Android?

No Intune

1. Abra o perfil de WiFi do Android Enterprise que corresponda ao tipo de registro. Dispositivos totalmente gerenciados, dedicados e de perfil de trabalho de propriedade corporativa usam um tipo de perfil. Dispositivos de perfil de trabalho de propriedade pessoal usam outro.
2. Defina o tipo de EAP como EAP-TLS.
3. Insira o nome DNS do certificado do servidor RADIUS em nomes de servidores RADIUS. O nome exato do certificado é o valor mais seguro. Nunca insira um endereço IP.
4. Selecione o perfil de certificado confiável que contém a CA raiz do servidor.
5. Selecione o perfil SCEP ou PKCS para autenticação de cliente.
6. Atribua todos os três perfis ao mesmo grupo.

Em builds Samsung, Pixel e outros

Não solicite que a equipe edite as configurações corporativas manualmente em nenhuma marca. As alterações manuais ignoram o Intune e acabam no lado errado do perfil de trabalho. Se um fabricante falhar e outro funcionar, compare primeiro o status do perfil. Em seguida, teste o valor do domínio em relação a essa build em seu laboratório.

No lado do RADIUS

Confirme se o certificado do servidor possui o nome DNS que você inseriu no Intune. Confirme se sua cadeia leva à raiz que você implantou. Se você usa o Purple Staff WiFi, a Purple fornece o serviço RADIUS em nuvem e se conecta aos seus pontos de acesso por RadSec, RADIUS transportado dentro de TLS. As etapas de configuração do fornecedor estão nos artigos de suporte da Purple, por exemplo, Staff WiFi - Ubiquiti UniFi. Verifique os requisitos dos pontos de acesso em Security and Hardware Compatibility.

Cenários práticos

Um hotel de 200 quartos após uma atualização do Android

Considere um hotel de 200 quartos com 60 dispositivos móveis corporativos para os setores de governança e manutenção. Após uma atualização mensal, 40 dispositivos móveis pararam de se conectar ao SSID da equipe. Os logs do RADIUS mostraram alertas TLS enviados pelos clientes.

O perfil de WiFi não tinha o valor de nomes de servidores RADIUS, o que as builds mais antigas toleravam. A equipe de TI adicionou o nome DNS do certificado do servidor e implantou o perfil novamente. Todos os 60 dispositivos móveis se conectaram após a próxima sincronização com o Intune, sem necessidade de redefinições de fábrica. Os operadores hoteleiros podem encontrar mais informações sobre a conectividade da equipe em nossa página de Hotéis.

Uma rede varejista de 120 lojas com dispositivos pessoais

Considere uma rede de varejo de 120 lojas com gerentes de loja usando telefones pessoais registrados com um perfil de trabalho. Os chamados do suporte técnico mostraram que os telefones em muitas lojas nunca alcançavam o RADIUS.

Os gerentes adicionaram o SSID da loja a partir das configurações pessoais, onde não existe certificado. A equipe atribuiu o perfil de WiFi do perfil de trabalho de propriedade pessoal e orientou os gerentes a remover as entradas manuais. As falhas de conexão cessaram assim que cada telefone recebeu o perfil gerenciado.

Uma operadora ferroviária renovando seu certificado de servidor

Considere uma operadora de trens executando WiFi para funcionários a bordo e nos depósitos (Trens). A operadora renovou o certificado do seu servidor RADIUS a partir de uma nova CA emissora. Todos os dispositivos Android falharam da noite para o dia com alertas de "CA desconhecida". O upload da nova raiz para o perfil de certificado confiável antes da transição teria evitado a interrupção. A operadora agora programa as alterações de raiz com duas semanas de antecedência.

Como evitar que isso aconteça novamente?

Lista de verificação de implantação para frotas Android no Intune e Entra ID

• Mapeie identidades. Decida se os certificados carregam o ID do dispositivo ou o UPN do funcionário, o nome de login do Entra ID. Configure o RADIUS para corresponder a esse campo.
• Separe por tipo de inscrição. Crie um conjunto de perfis para dispositivos de propriedade da empresa e outro para dispositivos com perfil de trabalho de propriedade pessoal.
• Emparelhe os perfis. A raiz confiável, o certificado do cliente e os perfis de WiFi devem compartilhar um grupo de atribuição.
• Use a raiz correta. Implante a CA que assinou o certificado do servidor RADIUS.
• Preencha os nomes dos servidores RADIUS. Use o nome DNS do certificado do servidor, nunca um endereço IP.
• Pilote entre fabricantes. Teste pelo menos um aparelho Samsung e um Pixel, além de qualquer outra marca em sua frota.
• Proíba conexões manuais. Diga aos funcionários para nunca adicionarem o SSID manualmente.
• Planeje as renovações de certificados em etapas. Envie as novas raízes antes que o certificado do servidor mude.
• Monitore ambos os lados. Revise o status do perfil do Intune e as rejeições do RADIUS semanalmente durante a implantação.

Para integração com provedores de identidade, consulte Como habilitar o Single Sign-On.

Perguntas frequentes

O Purple Staff WiFi funciona com dispositivos Android gerenciados no Intune?

Sim. O Purple Staff WiFi autentica dispositivos Android gerenciados com 802.1X baseado em certificado contra o RADIUS na nuvem da Purple. Você mantém o Intune para a entrega de perfis de certificado e WiFi. A Purple se conecta ao Microsoft Entra ID, Okta e Google Workspace para identidade. Seus perfis do Intune apontam para o certificado do servidor RADIUS da Purple em vez de um servidor local. As regras do lado do Android neste guia ainda se aplicam: uma raiz confiável e um domínio correspondente são necessários.

Preciso de novos pontos de acesso para executar EAP-TLS com a Purple?

Não. A Purple é agnóstica em relação ao hardware e funciona como uma sobreposição em nuvem nos pontos de acesso que você já possui. Os fabricantes suportados incluem Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Cada fabricante precisa de uma configuração RADIUS que aponte para a Purple. As etapas de configuração estão nos artigos de suporte da Purple. Verifique os requisitos específicos do modelo no artigo sobre Compatibilidade de Hardware e Segurança antes de começar.

Posso migrar de um NPS local para o RADIUS na nuvem sem precisar inscrever novamente os dispositivos Android?

Sim, na maioria dos casos você pode. Os dispositivos mantêm seus certificados de cliente existentes se o novo serviço RADIUS confiar em sua CA emissora. Você atualiza o perfil de raiz confiável e os nomes de servidor RADIUS no Intune para corresponder ao novo certificado de servidor. Agende essas alterações de perfil antes de alternar o destino do RADIUS do SSID. Isso evita as falhas de "CA desconhecida" que ocorrem da noite para o dia descritas neste guia.

O EAP-TLS é melhor do que PEAP ou iPSK para dispositivos de funcionários?

Sim, para frotas gerenciadas. O EAP-TLS usa um certificado por dispositivo ou identidade, portanto não há senhas compartilhadas que possam vazar. O PEAP (Protected EAP) depende de um nome de usuário e senha dentro de um túnel TLS. O iPSK (identity pre-shared key) fornece a cada dispositivo ou grupo sua própria chave. O iPSK é adequado para dispositivos não gerenciados que não podem conter certificados. O EAP-TLS é adequado para telefones que você gerencia por meio do Intune.

Quais padrões de conformidade a Purple atende para dados de autenticação de funcionários?

A Purple é certificada pelo ISO 27001 e Cyber Essentials, e está em conformidade com o GDPR e CCPA. O 802.1X baseado em certificado suporta o controle de acesso robusto que o PCI-DSS espera em redes próximas a dados de titulares de cartão. A Purple também possui a certificação B Corp. Peça à sua equipe de contas os certificados atuais se o seu processo de compras exigir cópias.

Quanto tempo leva uma implementação de EAP-TLS para Android?

Espere que a maior parte do esforço seja direcionada para PKI e Intune, e não para os pontos de acesso. Apontar um SSID para o RADIUS da Purple segue uma pequena lista de verificação do fornecedor na central de suporte. A criação de perfis SCEP ou PKCS, perfis de raiz confiável e perfis de WiFi para cada tipo de registro leva mais tempo. Reserve um tempo para um piloto que cubra todos os fabricantes de sua frota antes da implantação mais ampla.