Resolução de problemas de Android 802.1X e EAP-TLS: uma lista de verificação de implementação para o Intune e Microsoft Entra ID

Os telemóveis Android geridos costumam falhar o EAP-TLS por um de quatro motivos. O perfil WiFi não tem um certificado CA ou domínio, pelo que o Android rejeita o servidor RADIUS. O certificado de cliente encontra-se num perfil diferente. O campo de nomes do servidor RADIUS não corresponde ao certificado do servidor. Ou o perfil de raiz fidedigna nunca chegou ao dispositivo.

Como se manifesta 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 palavra-passe. É executado dentro do IEEE 802.1X, o padrão de controlo de acesso baseado em porta. O 802.1X entrega a autenticação a um servidor RADIUS (Remote Authentication Dial-In User Service).

Quando isto falha no Android, verá normalmente um destes sintomas:

• A rede aparece na lista, mas nunca passa de "A ligar", voltando depois para "Guardada".
• O dispositivo mostra um erro genérico de autenticação. A formulação varia consoante o fabricante.
• A rede funciona em telemóveis Samsung, mas não em Google Pixel, ou vice-versa.
• A rede funciona em telemóveis propriedade da empresa, mas falha em dispositivos pessoais inscritos com um perfil de trabalho.
• Não aparece absolutamente nada nos seus registos RADIUS.

Este último sintoma é o mais importante. Um dispositivo que nunca chega ao RADIUS tem um problema de perfil, não um problema de autenticação.

O que costuma causar 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 empresariais. O Android precisa agora de duas coisas antes de enviar o seu certificado: um certificado CA em que confiar e um domínio correspondente.

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

Certificado no perfil de trabalho, ligação à rede a partir do lado pessoal

O Android Enterprise separa o perfil de trabalho do lado pessoal, e cada um tem o seu próprio armazenamento de certificados. O Intune instala o certificado de cliente e a raiz fidedigna no perfil de trabalho. Um colaborador que adicione o SSID manualmente a partir das definições pessoais não consegue aceder a esses certificados, pelo que a autenticação falha.

O campo de nomes do servidor RADIUS

O perfil 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 apresentado pelo seu servidor RADIUS. O Android coloca este valor no seu campo de domínio e compara-o com o certificado do servidor. Se o campo estiver em branco, com erros ortográficos ou contiver um endereço IP, a validação falha.

O perfil de raiz fidedigna

O perfil WiFi aponta para um perfil de certificado fidedigno separado do Intune. Esse perfil deve conter a CA raiz que emitiu o certificado do servidor RADIUS. Um erro comum é implementar a raiz associada aos seus certificados de cliente quando uma CA diferente assinou o certificado do servidor. Os dois perfis também devem visar os mesmos grupos e o mesmo tipo de inscrição do Android Enterprise.### Diferenças entre fabricantes

As compilações da Samsung, Google Pixel e de outros fabricantes etiquetam e organizam as definições de WiFi empresarial de forma diferente. Algumas mostram opções extra, tais como verificações do estado do certificado online. Utilize os dispositivos da sua própria frota como referência, e não capturas de ecrã de outra marca.

Como identificar qual é a causa que tem?

Comece no dispositivo e depois confirme nos registos RADIUS. O padrão nos registos geralmente aponta para a causa.

Sintoma	O que o RADIUS mostra	Causa provável	Primeira correção
Nenhuma tentativa chega ao RADIUS	Nenhum pedido do dispositivo	Perfil de WiFi não aplicado ou erro de correspondência no nome do SSID	Verifique o estado do perfil por dispositivo no Intune
O handshake para após o servidor enviar o seu certificado	Alerta TLS do cliente, como "unknown CA"	Raiz fidedigna incorreta ou em falta, ou erro de correspondência de domínio	Implemente a CA raiz do servidor e os nomes corretos do servidor RADIUS
O handshake é concluído do lado do servidor e depois falha	Nenhum certificado de cliente apresentado	Certificado SCEP ou PKCS em falta ou no perfil incorreto	Confirme se o perfil do certificado foi bem-sucedido para esse dispositivo
Certificado aceite e depois rejeitado	Access-Reject após 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 fornecedor de identidade
Falha apenas em dispositivos de propriedade pessoal	Nenhum pedido ou nenhum certificado de cliente	Associação ao SSID efetuada a partir do lado pessoal	Implemente o perfil no perfil de trabalho e impeça associações manuais

Ler a falha no dispositivo

No centro de administração do Microsoft Intune, abra o dispositivo e verifique o estado de cada perfil de configuração. Um perfil de WiFi apresentado como pendente ou em erro nunca chegou ao dispositivo. Um perfil de certificado em erro significa que a emissão de 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 registos do Android Debug Bridge a partir do supplicant de WiFi mostram o alerta TLS exato. Utilize isto para um telemóvel de teste, não para uma frota de produção.

Ler os registos RADIUS

As plataformas FreeRADIUS, Microsoft Network Policy Server e RADIUS na nuvem registam 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 telemóvel rejeitou o seu servidor. Um Access-Reject após um certificado válido significa que o seu servidor rejeitou o telemóvel.

Se os dispositivos se autenticarem e depois perderem a ligação à medida que os funcionários andam entre pisos, a causa é diferente. Leia Resolving Roaming Issues in Corporate WLANs. As desconexões que coincidem com alterações de canal apontam, em vez disso, para eventos de radar. Consulte DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Como corrigir no Intune e em cada compilação de Android?

No Intune

1. Abra o perfil de WiFi do Android Enterprise que corresponde ao tipo de inscrição. Os dispositivos de perfil de trabalho totalmente geridos, dedicados e propriedade da empresa utilizam um tipo de perfil. Os dispositivos de perfil de trabalho de propriedade pessoal utilizam outro.
2. Defina o tipo de EAP para EAP-TLS.
3. Introduza o nome DNS do certificado do servidor RADIUS em nomes de servidores RADIUS. O nome exato do certificado é o valor mais seguro. Nunca introduza 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 os três perfis ao mesmo grupo.

Em Samsung, Pixel e outras compilações

Não peça aos colaboradores para editarem as definições empresariais manualmente em nenhuma marca. As alterações manuais contornam o Intune e ficam no lado errado do perfil de trabalho. Se um fabricante falhar e outro funcionar, compare primeiro o estado do perfil. Em seguida, teste o valor do domínio com essa compilação no seu laboratório.

Do lado do RADIUS

Confirme que o certificado do servidor contém o nome DNS que introduziu no Intune. Confirme se a sua cadeia leva à raiz que implementou. Se utiliza o Purple Staff WiFi, a Purple fornece o serviço de RADIUS na nuvem e liga-se aos seus pontos de acesso através de RadSec - RADIUS transportado dentro de TLS. Os passos de configuração do fornecedor encontram-se 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 telemóveis propriedade da empresa para o pessoal de limpeza e manutenção. Após uma atualização mensal, 40 telemóveis deixaram de se ligar ao SSID dos colaboradores. Os registos do RADIUS mostraram alertas de TLS enviados pelos clientes.

O perfil de WiFi não tinha qualquer valor de nomes de servidores RADIUS, o que as compilações mais antigas tinham tolerado. A equipa de TI adicionou o nome DNS do certificado do servidor e reinstalou o perfil. Todos os 60 telemóveis ligaram-se após a verificação seguinte do Intune, sem necessidade de reposições de fábrica. Os operadores hoteleiros podem encontrar mais informações sobre a conectividade dos colaboradores na nossa página de Hotéis.

Uma cadeia de retalho com 120 lojas com dispositivos pessoais

Considere uma cadeia de retalho com 120 lojas com gestores de loja em telemóveis pessoais inscritos com um perfil de trabalho. Os pedidos de suporte mostraram que os telemóveis em muitas lojas nunca chegavam ao RADIUS.

Os gestores tinham adicionado o SSID da loja a partir das definições pessoais, onde não existe nenhum certificado. A equipa atribuiu o perfil de WiFi do perfil de trabalho de propriedade pessoal e instruiu os gestores a removerem as entradas manuais. As falhas de ligação pararam assim que cada telemóvel recebeu o perfil gerido.

Um operador ferroviário a renovar o seu certificado de servidor

Considere um operador ferroviário que disponibiliza WiFi para funcionários a bordo e nos depósitos (Trains). O operador renovou o certificado do seu servidor RADIUS a partir de uma nova AC emissora. Todos os dispositivos Android falharam durante a noite com alertas de "AC desconhecida". O carregamento da nova raiz para o perfil de certificado confiável antes da transição teria evitado a interrupção. O operador agora agenda as alterações de raiz com duas semanas de antecedência.

Como evitar que isso aconteça novamente?

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

• Mapear identidades. Decida se os certificados devem conter o ID do dispositivo ou o UPN do funcionário, o seu nome de início de sessão no Microsoft Entra ID. Configure o RADIUS para corresponder a esse campo.
• Separar por tipo de inscrição. Crie um conjunto de perfis para dispositivos de propriedade corporativa e outro para dispositivos com perfil de trabalho de propriedade pessoal.
• Emparelhar os perfis. A raiz confiável, o certificado de cliente e os perfis WiFi devem partilhar um grupo de atribuição.
• Utilizar a raiz correta. Implemente a AC que assinou o certificado do servidor RADIUS.
• Preencher nomes de servidores RADIUS. Utilize o nome DNS do certificado do servidor, nunca um endereço IP.
• Realizar testes piloto em vários fabricantes. Teste pelo menos um telemóvel Samsung e um Pixel, além de qualquer outra marca na sua frota.
• Proibir ligações manuais. Instrua os funcionários a nunca adicionarem o SSID manualmente.
• Planear as renovações de certificados por etapas. Envie as novas raízes antes que o certificado do servidor seja alterado.
• Monitorizar ambos os lados. Reveja o estado do perfil do Intune e as rejeições do RADIUS semanalmente durante a implementação.

Para integração com fornecedores de identidade, consulte How to Enable Single Sign On.

Perguntas frequentes

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

Sim. O Purple Staff WiFi autentica dispositivos Android geridos utilizando 802.1X baseado em certificados contra o cloud RADIUS da Purple. Mantém o Intune para a entrega de certificados e perfis WiFi. A Purple liga-se ao Microsoft Entra ID, Okta e Google Workspace para gestão de identidade. Os 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 continuam a aplicar-se: são necessários uma raiz confiável e um domínio correspondente.

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

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

Posso migrar de um NPS local para o cloud RADIUS sem reinscrever os dispositivos Android?

Sim, na maioria dos casos é possível. Os dispositivos mantêm os seus certificados de cliente existentes se o novo serviço RADIUS confiar na sua CA emissora. Atualize o perfil de raiz fidedigna e os nomes dos servidores RADIUS no Intune para corresponderem ao novo certificado de servidor. Agende essas alterações de perfil antes de mudar o destino RADIUS do SSID. Isso evita as falhas de "CA desconhecida" descritas neste guia que ocorrem durante a noite.

O EAP-TLS é melhor do que o PEAP ou o iPSK para dispositivos da equipa?

Sim, para frotas geridas. O EAP-TLS utiliza um certificado por dispositivo ou identidade, pelo que não existem palavras-passe partilhadas que possam ser divulgadas. O PEAP (Protected EAP) depende de um nome de utilizador e palavra-passe dentro de um túnel TLS. O iPSK (identity pre-shared key) atribui a cada dispositivo ou grupo a sua própria chave. O iPSK é adequado para dispositivos não geridos que não conseguem reter certificados. O EAP-TLS é adequado para telemóveis que gere através do Intune.

Quais são as normas de conformidade que a Purple cumpre para os dados de autenticação da equipa?

A Purple é certificada pela ISO 27001 e Cyber Essentials, e está em conformidade com o GDPR e o CCPA. O 802.1X baseado em certificados suporta o controlo de acesso rigoroso que a norma PCI-DSS exige em redes próximas de dados de titulares de cartões. A Purple também detém a certificação B Corp. Peça à sua equipa de conta os certificados atuais se o seu processo de aquisição exigir cópias.

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

Preveja que a maior parte do esforço seja dedicada à PKI e ao Intune, e não aos pontos de acesso. Apontar um SSID para o RADIUS da Purple segue uma lista de verificação curta do fornecedor no centro de suporte. A criação de perfis SCEP ou PKCS, perfis de raiz fidedigna e perfis de WiFi para cada tipo de inscrição demora mais tempo. Reserve tempo para um projeto-piloto que inclua todos os fabricantes da sua frota antes da implementação mais alargada.