Saltar para o conteúdo principal

Autenticação WiFi com Entra ID: Um Guia Prático de Configuração

29 August 2026
19 min de leitura
Entra ID WiFi Authentication: A Practical Setup Guide

Herdou um património no Reino Unido onde a palavra-passe do WiFi corporativo está impressa numa pasta de back-office, partilhada pela receção, limpeza, subempreiteiros e antigos funcionários. A rede de convidados é gerida separadamente, a integração de dispositivos depende de instruções manuais e um auditor quer saber que pessoa autorizou cada ligação. Entretanto, a organização migrou a sua identidade de aplicações para o Microsoft Entra ID e espera que o WiFi siga o mesmo caminho.

Essa expectativa é compreensível, mas a arquitetura é frequentemente descrita de forma incorreta. O Microsoft Entra ID não fornece um serviço RADIUS nativo. A posição documentada da Microsoft é que os dispositivos associados ao Entra não podem utilizar a autenticação RADIUS com base num objeto de computador e certificado locais, pelo que os designs modernos dependem de EAP-TLS, certificados emitidos pelo Intune e uma camada RADIUS separada (Orientação de RADIUS do Microsoft Entra ID). Assim que esta distinção for clara, a implementação torna-se muito mais fácil de desenhar, testar e suportar.

Por Que Razão a Autenticação WiFi do Microsoft Entra ID Vale o Esforço

Uma chave pré-partilhada partilhada pode funcionar no momento da abertura e depois permanecer ativa após a saída de um colaborador, a cópia da chave por um prestador de serviços para um dispositivo pessoal ou o acesso de um convidado a uma rede destinada à equipa. Alterar essa chave cria o seu próprio problema operacional. Cada portátil gerido, telemóvel, terminal de pagamento, tablet e outro dispositivo deve receber o novo segredo, frequentemente em hotéis, hospitais e pontos de venda.

A autenticação WiFi com Microsoft Entra ID altera a unidade de confiança da palavra-passe para a identidade e o dispositivo. O EAP-TLS utiliza uma ligação suportada por certificado para identificar um utilizador ou dispositivo autorizado. O Intune controla quais os endpoints geridos que recebem esse certificado e o perfil WiFi correspondente. O ponto de acesso continua a necessitar de RADIUS, pelo que o Microsoft Entra ID é o diretório e a origem da política, e não o endpoint de autenticação sem fios. Essa lacuna arquitetónica é o detalhe que muitos guias simplificados omitem.

Regra prática: Trate o WiFi como um serviço vinculado à identidade: exija um certificado e o âmbito do Intune, nunca uma colagem de nome de utilizador e palavra-passe do Entra.

A integração torna-se repetível. Um perfil do Intune corretamente configurado pode definir o SSID, a cadeia de certificados fidedigna e a seleção de certificados sem pedir à equipa para digitar ou partilhar uma chave. A desintegração também ganha um caminho de controlo definido. A desativação de um dispositivo pode desencadear ações no ciclo de vida do certificado, em vez de deixar os administradores à procura de todos os locais onde uma palavra-passe partilhada foi armazenada.

O caso de conformidade é igualmente prático. As organizações do Reino Unido devem separar funcionários, convidados, fornecedores e equipamentos não geridos em instalações partilhadas e ambientes regulados. Um enterprise WiFi security guide dedicado fornece um enquadramento útil, enquanto o design de produção necessita de decisões claras: manter o acesso de convidados separado do EAP-TLS dos funcionários, registar a identidade apresentada ao RADIUS e definir como o acesso é removido.

O centro de administração do Entra não fornece um interruptor único para esta conceção. A PKI, o Intune, a política RADIUS e as definições sem fios devem funcionar em conjunto, e os dispositivos legados Apple, Windows, Android e partilhados podem expor comportamentos de certificado ou perfil diferentes. Esse trabalho de integração é real, mas substitui um segredo partilhado frágil por um controlo repetível que pode ser aplicado em todo o património misto do Reino Unido.

Os Blocos de Construção Essenciais de Que Precisa

Uma rede de convidados de hotel, uma enfermaria de hospital ou uma filial de retalho podem falhar no primeiro controlo de certificado enquanto o ponto de acesso ainda reporta um SSID em bom estado. Evite essa confusão definindo a arquitetura antes de abrir o assistente do Intune. Quatro componentes devem concordar numa única cadeia de identidade:

  1. Uma autoridade de certificação. Comece com o Microsoft PKI, AD CS ou um fornecedor de certificados gerido. A CA deve emitir certificados com EKU de Client Authentication antes de a política RADIUS ser ajustada, e o serviço RADIUS deve confiar na cadeia de emissão.
  2. Uma camada RADIUS. O NPS, Aruba ClearPass, Cisco ISE ou uma plataforma RADIUS-as-a-Service termina a troca 802.1X a partir dos pontos de acesso. O Entra ID não possui uma funcionalidade RADIUS nativa. A extensão NPS adapta os pedidos RADIUS a verificações baseadas em Entra, em vez de transformar o Entra num servidor RADIUS, conforme explicado no Q&A da Microsoft sobre a limitação do RADIUS.
  3. Intune. O Intune fornece a raiz fidedigna, o perfil de certificado SCEP ou PKCS e a configuração de WiFi. As suas atribuições também controlam o âmbito do dispositivo, garantindo que um perfil inacabado não chegue a todo o parque de dispositivos.
  4. Política de rede. O RADIUS deve definir o que um certificado bem-sucedido permite. Isso pode ser uma VLAN de funcionários, um segmento clínico, uma rede de retalho restrita ou uma ACL específica do dispositivo.

Um diagrama que descreve seis blocos de construção de negócios essenciais, incluindo estratégia, equipa, processos, finanças, marca e dados.

Construir por ordem de dependência

Publique e valide o modelo de CA antes de ajustar o RADIUS. Verifique o emissor, assunto ou SAN, cadeia de certificados e o EKU de Autenticação de Cliente. Caso contrário, as falhas de handshake podem parecer uma falha de RF ou de SSID quando o dispositivo não tem um certificado utilizável.

A confiança deve funcionar em ambos os sentidos. Os dispositivos geridos confiam na CA que assinou o certificado do servidor RADIUS, enquanto o RADIUS confia na CA que emitiu o certificado do cliente. Os pontos de acesso precisam do endereço do servidor RADIUS e do segredo partilhado. Eles não se autenticam diretamente contra o Entra.

Decidir onde reside a política

O NPS, ClearPass e ISE podem impor políticas de rede sem fios, mas os seus modelos de regras e processamento de atributos diferem. Selecione uma única fonte de verdade para o mapeamento de SSID para VLAN, documente-a e evite que os painéis dos APs e as regras RADIUS produzam resultados conflituosos.

Uma listagem do setor público do Reino Unido descreve o suporte do Entra ID para autenticação por chave pública, incluindo certificados de cliente TLS, juntamente com federação e autenticação de dois fatores (listagem do Entra ID do setor público do Reino Unido). O modelo de certificado ainda depende dos componentes PKI e RADIUS separados.

Emitir Certificados e Enviar Perfis de WiFi Através do Intune

Para dispositivos geridos, o EAP-TLS tem sucesso ou falha na seleção do certificado. O Intune pode fornecer o perfil sem interação do utilizador, mas não consegue compensar um modelo de certificado que careça da utilização, do emissor ou do mapeamento de assunto corretos.

Estabelecer o caminho do certificado

Implemente primeiro o perfil da CA raiz fidedigna. Com o SCEP, crie um perfil de certificado que aponte para o serviço NDES e utilize o Intune Certificate Connector. O perfil deve referenciar o endpoint SCEP publicado, o modelo de certificado correto e um mecanismo de desafio que impeça pedidos não autorizados.

O próprio certificado necessita de Autenticação de Cliente na sua utilização expandida de chaves. Decida se o assunto e o SAN identificam o dispositivo, o utilizador ou ambos. Essa decisão afeta o mapeamento RADIUS, o comportamento em dispositivos partilhados e a forma como irá investigar um evento de autenticação mais tarde.

Um perfil PFX pode funcionar onde os certificados são gerados e empacotados através de um fluxo de trabalho aprovado, mas o SCEP é geralmente mais fácil de operar num parque gerido diversificado porque o dispositivo pode solicitar e renovar o seu próprio certificado. O ponto importante é a consistência. Cada plataforma deve receber uma cadeia e um certificado que a política RADIUS compreenda.

Screenshot from /screenshots/intune-scep-wifi-profile.png

Configurar o payload de WiFi

Crie o perfil de WiFi com o SSID, modo de segurança e método EAP exatos. Selecione EAP-TLS, associe o perfil ao certificado emitido pela configuração SCEP e ative a validação de certificado do servidor. Adicione os nomes exatos do servidor RADIUS para que um dispositivo não aceite um serviço semelhante durante a decisão de confiança. A orientação de implementação recomendada para o Reino Unido alinhada com a Microsoft sugere uma raiz fidedigna, um perfil de certificado de cliente SCEP e nomes RADIUS precisos no perfil de WiFi (Orientação de configuração de WiFi com Entra ID).

O campo que causa falhas repetidas é a correspondência de certificados. No Windows, macOS, iOS e Android, o perfil de WiFi deve selecionar o certificado emitido pela CA esperada e que contenha o EKU pretendido. Se o perfil for implementado mas o sistema operativo não conseguir selecionar esse certificado, o dispositivo pode reverter para um método inadequado ou rejeitar a ligação.

Defina o âmbito dos perfis SCEP e WiFi para o mesmo grupo de dispositivos piloto. Verifique os registos dos dispositivos para a instalação do certificado, confirme se a raiz é fidedigna e, em seguida, inspecione o certificado de cliente selecionado antes de alterar a política RADIUS. Uma verificação de integridade do certificado, como este SSL certificate checker, pode ajudar a validar o lado do certificado público, mas a resolução de problemas interna de EAP-TLS continua a depender dos registos do dispositivo e do RADIUS.

Ligar Tudo à Sua Rede e Camada RADIUS

O ponto de acesso deteta um suplicante 802.1X. Não deteta o Microsoft Entra ID. O dispositivo apresenta o seu certificado de cliente, o AP encaminha a troca EAP para o RADIUS, e o serviço RADIUS valida a cadeia de certificados e aplica a política de rede.

O fluxo habitual é:

  1. O dispositivo associa-se ao SSID corporativo.
  2. O AP encaminha o tráfego EAP-TLS para o NPS, ClearPass, ISE ou para um serviço RADIUS alojado.
  3. O RADIUS valida o certificado de cliente face à CA emissora fidedigna.
  4. O motor de políticas mapeia a identidade do certificado para uma conta, dispositivo ou grupo.
  5. A resposta RADIUS atribui a VLAN permitida ou a política de acesso.

Diferenças de configuração entre fabricantes

Os painéis Meraki exigem normalmente os detalhes do servidor RADIUS, o segredo partilhado e as definições de validação de certificados, com a sobreposição de AAA utilizada quando a resposta RADIUS controla a segmentação. As implementações Aruba dependem frequentemente de um grupo de servidores RADIUS e de regras de derivação de servidores. O Ruckus SmartZone necessita de configuração AAA com o EAP-TLS selecionado, enquanto os modelos WLAN do Juniper Mist apontam para o cluster RADIUS. O UniFi Network utiliza um perfil RADIUS e pode exigir um tratamento cuidadoso onde o EAP-TTLS legado coexiste com o EAP-TLS.

O RADIUS-as-a-Service da Purple é uma opção alojada para parques de dispositivos que pretendem uma camada RADIUS separada sem operar toda a plataforma de servidores. O NPS, ClearPass, ISE e serviços alojados podem todos adequar-se, mas não interpretarão cada atributo de certificado ou condição de política de forma idêntica.

Fabricante Servidor RADIUS auth Tipo de EAP Atributo do certificado Erro comum
Meraki NPS, ISE, ClearPass ou RADIUS alojado EAP-TLS Emissor e SAN A sobreposição AAA pode colocar um utilizador válido na VLAN errada
Aruba NPS, ClearPass, ISE ou RADIUS alojado EAP-TLS SAN ou UPN A ordem das regras de derivação do servidor pode enviar funcionários para a política de convidados
Ruckus RADIUS ligado ao SmartZone EAP-TLS Assunto e emissor A incompatibilidade do tipo de EAP é fácil de passar despercebida nas definições de AAA
Juniper Mist Cluster RADIUS EAP-TLS SAN ou identidade mapeada O modelo WLAN pode referenciar um grupo de servidores incompleto
UniFi Perfil RADIUS da aplicação de rede EAP-TLS ou método legado controlado Identidade do certificado Métodos EAP mistos podem ocultar a falha real

No NPS, inspecione as propriedades do certificado EAP-TLS e defina se o emissor, o assunto ou o SAN fornece o mapeamento da conta. Um erro frequente é assumir que o nome comum é o nome de utilizador quando o serviço RADIUS analisa o SAN como um UPN. Isso quebra o mapeamento de utilizadores e também pode interromper os fluxos de apenas dispositivo ou de dispositivos partilhados.

Utilize um cluster RADIUS com balanceamento de carga onde o parque exija resiliência e defina temporizadores de failover sensatos por SSID. Não assuma que um serviço RADIUS na nuvem impõe a revogação em tempo real. Alguns equipamentos alojados carecem de validação CRL ou OCSP acessível, pelo que o certificado pode continuar a ser aceite mesmo após a alteração de uma conta de diretório.

Revogação Instantânea e Acesso Condicional para WiFi de Funcionários

A questão difícil não é se um dispositivo se consegue registar. É o que acontece depois de os Recursos Humanos desativarem uma conta.

O Conditional Access avalia os inícios de sessão suportados do Entra. Não interfere numa sessão 802.1X já estabelecida para a terminar apenas porque o estado do diretório mudou. Um certificado já instalado num portátil pode permanecer criptograficamente válido até expirar ou até que o serviço RADIUS o rejeite através da verificação de revogação de certificados. Isso torna o design de revogação mais importante do que a demonstração de inscrição.

Reduzir a janela do certificado

A primeira mitigação é um tempo de vida curto do certificado. Os perfis Intune SCEP podem emitir certificados que se renovam regularmente, limitando o tempo que um dispositivo desativado pode continuar a apresentar uma credencial que, de outra forma, seria válida. A janela apropriada depende do modelo de ameaça, da disponibilidade do dispositivo e da tolerância operacional. Um tempo de vida mais curto aumenta a dependência de uma renovação fiável, por isso teste dispositivos que passam tempo offline ou que operam atrás de redes restritas.

A segunda mitigação é a verificação de revogação ativa. Publique uma CRL acessível ou opere OCSP, depois confirme se os servidores RADIUS a consultam. As configurações de NPS e ClearPass podem parecer funcionais enquanto ignoram a revogação porque a verificação está desativada ou o ponto de distribuição está inacessível a partir da rede RADIUS.

A métrica operacional que importa é o intervalo entre a desativação no diretório e o primeiro pacote de rede sem fios rejeitado.

Os fluxos de trabalho de desativação e eliminação do Intune continuam a ser valiosos, especialmente para dispositivos perdidos ou partilhados, mas não apagam magicamente um certificado de um endpoint desligado. O certificado torna-se inutilizável através de expiração, revogação ou remoção quando o dispositivo receber instruções de gestão pela próxima vez. As equipas devem documentar essa janela e testá-la durante os exercícios de desativação.

O Entra Continuous Access Evaluation suporta decisões rápidas de controlo para cenários selecionados de aplicações na nuvem. Atualmente, não transforma o EAP-TLS numa transação de Acesso Condicional ao estilo de browser, pelo que o WiFi ainda depende da validade do certificado e do comportamento de revogação do RADIUS. Para leitores que estejam a rever o modelo de autenticação mais amplo, este guia de MFA para utilizadores de Edmonton fornece um contexto útil sobre como uma garantia de início de sessão mais forte difere da autenticação por certificado de rede.

O acesso de convidados necessita do seu próprio plano de controlo. A prática do setor público do Reino Unido, incluindo o GovWifi, reforça que os visitantes e o acesso partilhado não devem ser forçados a entrar no mesmo fluxo de trabalho de certificados de funcionários (UK Entra WiFi integration guidance).

Testar e Resolver Problemas em Modos de Falha Comuns

Um teste em laboratório prova que um dispositivo se consegue ligar. Uma implementação em produção prova que o dispositivo errado não se consegue ligar, que um certificado revogado é rejeitado e que um convidado não consegue herdar a política da equipa.

Começar pelo certificado

Para uma falha de EAP-TLS, inspecione o certificado de cliente antes de alterar o AP. Confirme a cadeia, emissor, SAN, expiração e o EKU de Autenticação de Cliente. Em seguida, verifique se o perfil de WiFi seleciona esse certificado e se o dispositivo confia no certificado do servidor RADIUS.

Os loops SCEP indicam geralmente uma incompatibilidade entre o Intune, o NDES e o modelo de certificado. Verifique o URL de desafio, confirme se a conta do conector NDES tem as permissões de modelo necessárias e compare o URI do perfil SCEP com o URL NDES publicado, incluindo a barra final. Um certificado emitido a partir do modelo errado pode parecer uma inscrição bem-sucedida, mas permanecer inutilizável para o WiFi.

Testar fidedignidade e segmentação

Um Evil Twin pode transmitir o mesmo SSID antes de a validação do certificado ocorrer. Configure a validação do certificado do servidor, especifique os nomes RADIUS esperados no perfil WiFi do Intune e utilize definições de rede gerida para que o sistema operativo não se ligue livremente a um impostor. Ative os Protected Management Frames onde o cliente e o parque de APs os suportem, e utilize um SSID específico da organização em vez de um nome genérico.

Um certificado revogado que ainda se autentica normalmente aponta para o servidor RADIUS, não para o Entra. Verifique se a validação CRL está ativada e, em seguida, confirme se a sub-rede RADIUS consegue resolver e alcançar o ponto de distribuição. Se o OCSP for utilizado, inspecione o tempo limite e a acessibilidade do respondente em vez de assumir que o serviço está a verificar automaticamente.

A sobreposição entre convidados e funcionários decorre frequentemente da ordem das políticas. Coloque as regras de funcionários EAP-TLS à frente das regras de convidados baseadas em PSK ou MAC, e depois verifique os atributos de VLAN retornados no registo do RADIUS. Uma autenticação válida com a VLAN errada é uma falha de política, não uma falha de inscrição.

Uma lista de verificação de instruções de oito etapas para implementar a autenticação WiFi do Entra ID num ambiente corporativo no Reino Unido.

Utilizar uma ordem de triagem fixa

As primeiras ligações lentas podem resultar do tempo de renovação do certificado, de pontos de extremidade de revogação inacessíveis ou de o sistema operativo selecionar o SSID incorreto. Não comece por reconstruir o perfil.

  1. Inspecione o certificado do dispositivo: Verifique a cadeia, EKU, emissor, SAN e validade.
  2. Capte a troca sem fios: Confirme se o AP encaminha o tráfego EAP para o destino RADIUS pretendido.
  3. Leia o registo de eventos RADIUS: Utilize os registos NPS, registos de eventos ISE ou o acompanhamento de acessos ClearPass para identificar o atributo rejeitado.
  4. Verifique o estado do Intune: Confirme se o dispositivo está registado, recebe os perfis e permanece no grupo de atribuição pretendido.
  5. Verifique a política devolvida: Confirme se as sessões de funcionários e convidados recebem a VLAN e ACL corretas.

Essa ordem mantém a investigação baseada em evidências. Alterar três camadas ao mesmo tempo esconde frequentemente a falha original.

Uma Lista de Verificação de Implementação com Sabor do Reino Unido e O Que Fazer a Seguir

Execute a implementação como uma alteração de serviço controlada, não como uma experiência de certificados. Comece com um pequeno grupo de dispositivos que represente o parque informático: um portátil Windows moderno, terminais Apple, hardware Android, dispositivos partilhados e qualquer equipamento operacional que tenha de permanecer ligado. A receção de um hotel, a enfermaria de um hospital e uma loja de retalho podem utilizar a mesma plataforma de identidade, mas ter requisitos de recuperação muito diferentes.

A sequência de implementação

  • Escopo do projeto-piloto: Selecione utilizadores, localizações e tipos de dispositivos representativos, incluindo locais com fraca conectividade ou caminhos de gestão restritos.
  • Prontidão da CA: Confirme a cadeia de emissão, permissões de modelos, EKU e endpoints de revogação antes de criar o perfil de WiFi.
  • Construção do perfil Intune: Crie a raiz fidedigna, o perfil de certificado SCEP ou PFX e o perfil de WiFi EAP-TLS como um conjunto correspondente.
  • Integração RADIUS: Adicione os APs, segredos partilhados, fidedignidade de certificados e regras de mapeamento de identidade à plataforma RADIUS selecionada.
  • Isolamento de dispositivos: Atribua perfis ao grupo piloto e mantenha o SSID antigo disponível como uma alternativa documentada.
  • Implementação em massa: Expanda por local ou grupo de dispositivos apenas após a emissão de certificados, atribuição de VLAN e testes de desassociação serem bem-sucedidos.
  • Cadência de auditoria: Reveja autenticações falhadas, expiração de certificados, acessibilidade de revogação e resultados da política de funcionários vs. convidados.
  • Desativação de PSK: Remova os SSIDs de chave partilhada apenas após as equipas de suporte terem um processo de emergência testado e o parque de dispositivos ter migrado.

As verificações específicas do Reino Unido são fáceis de ignorar. Confirme que os dispositivos BYOD da Apple confiam na cadeia de emissão através do caminho de gestão pretendido. Defina como os segredos partilhados RADIUS são rodados, registe onde a telemetria dos certificados é armazenada para revisão de acordo com o GDPR, e alinhe os registos de autenticação com os requisitos de auditoria específicos do setor ou da PSN da organização. Os hospitais e os edifícios partilhados do setor público também necessitam de um SSID de interrupção documentado ou de um processo de acesso alternativo que não se torne numa rede permanente não gerida.

As passkeys deverão tornar-se o método de autenticação predefinido para o início de sessão no Entra em 2026, de acordo com a atualização do ecossistema da Microsoft (Microsoft Entra passkeys update). Isso não descarta o trabalho atual com o EAP-TLS. As passkeys respondem ao início de sessão de identidade interativo, enquanto o WiFi continua a necessitar de uma credencial de rede verificável por máquina, de uma decisão de política e de uma troca RADIUS. A AC, a gestão de dispositivos e a disciplina de políticas criadas para os certificados continuam a ser bases úteis para o próximo modelo de identidade.

Um infográfico de lista de verificação que descreve os passos para uma implementação empresarial adaptada ao Reino Unido e estratégias de crescimento futuro.

Se o seu parque de dispositivos ainda depende de uma chave partilhada ou assume que o Microsoft Entra ID pode responder diretamente a pedidos RADIUS, documente primeiro os SSIDs atuais, a autoridade de certificação, os grupos de dispositivos e a política RADIUS. Em seguida, realize um projeto-piloto de EAP-TLS com o Intune em dispositivos representativos do Reino Unido, teste a revogação antes de expandir e mantenha o acesso de convidados separado da identidade dos funcionários.


A Purple disponibiliza uma plataforma de RADIUS na nuvem e WiFi baseado em identidade que pode ligar o acesso de funcionários apoiado pelo Entra ID com políticas de rede em ambientes de múltiplos fornecedores. Visite a Purple para analisar como as suas capacidades de WiFi para funcionários de nível de certificado e acesso de convidados se podem enquadrar na sua implementação no Reino Unido.

Pronto para começar?

Agende uma demonstração com um dos nossos especialistas para ver como a Purple pode ajudá-lo a atingir os seus objetivos de negócio.

Fale com um especialista