Você herdou uma propriedade no Reino Unido onde a senha do WiFi corporativo está impressa em uma pasta no back-office, compartilhada pela recepção, equipe de limpeza, prestadores de serviços e ex-funcionários. A rede de convidados é gerenciada separadamente, a integração de dispositivos depende de instruções manuais e um auditor deseja saber qual pessoa autorizou cada conexão. Enquanto isso, a organização transferiu sua identidade de aplicativo 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 dispositivos ingressados no Entra não podem usar a autenticação RADIUS com base em um objeto de computador local e certificado, de modo que os projetos modernos dependem de EAP-TLS, certificados emitidos pelo Intune e uma camada RADIUS separada (orientações de RADIUS do Microsoft Entra). Uma vez que essa distinção esteja clara, a implantação se torna muito mais fácil de projetar, testar e dar suporte.
Por que a autenticação de WiFi do Entra ID vale o esforço
Uma chave pré-compartilhada compartilhada pode funcionar no momento da abertura e, em seguida, permanecer ativa após a saída de um funcionário, a cópia por um prestador de serviços para um dispositivo pessoal ou o acesso de um convidado a uma rede destinada à equipe. Alterar essa chave cria seu próprio problema operacional. Cada notebook gerenciado, celular, caixa registradora, tablet e outro dispositivo deve receber o novo segredo, frequentemente em hotéis, hospitais e pontos de venda.
A autenticação de WiFi do Microsoft Entra ID altera a unidade de confiança da senha para a identidade e o dispositivo. O EAP-TLS usa uma conexão baseada em certificado para identificar um usuário ou dispositivo autorizado. O Intune controla quais endpoints gerenciados recebem esse certificado e o perfil de WiFi correspondente. O ponto de acesso ainda exige RADIUS, de modo que o Microsoft Entra ID é o diretório e a origem da política, não o endpoint de autenticação sem fio. Essa lacuna de arquitetura é o detalhe que muitos guias simplificados omitem.
Regra prática: Trate o WiFi como um serviço vinculado à identidade: exija um certificado e o escopo do Intune, nunca uma colagem de nome de usuário e senha do Entra.
O onboarding torna-se repetível. Um perfil do Intune configurado corretamente pode definir o SSID, a cadeia de certificados confiáveis e a seleção de certificados sem solicitar que a equipe digite ou compartilhe uma chave. O offboarding também ganha um caminho de controle definido. A desativação de um dispositivo pode acionar ações no ciclo de vida do certificado, em vez de deixar os administradores procurando por cada local onde uma senha compartilhada foi armazenada.
A questão de conformidade é igualmente prática. As organizações do Reino Unido devem separar funcionários, convidados, fornecedores e equipamentos não gerenciados em instalações compartilhadas e ambientes regulamentados. Um enterprise WiFi security guide dedicado fornece um histórico útil, enquanto o design de produção precisa de decisões claras: manter o acesso de convidados separado do EAP-TLS de funcionários, registrar a identidade apresentada ao RADIUS e definir como o acesso é removido.
O centro de administração do Entra não fornece um switch único para esse design. PKI, Intune, política RADIUS e configurações sem fio devem funcionar juntos, e dispositivos legados Apple, Windows, Android e compartilhados podem expor comportamentos diferentes de certificado ou perfil. Esse trabalho de integração é real, mas substitui um segredo compartilhado frágil por um controle repetível que pode ser aplicado em um patrimônio misto no Reino Unido.
Os blocos de construção essenciais que você precisa preparar
Uma rede de visitantes de hotel, uma ala hospitalar ou uma filial de varejo podem falhar logo na primeira verificação de certificado, enquanto o ponto de acesso ainda reporta um SSID íntegro. Evite essa confusão definindo a arquitetura antes de abrir o assistente do Intune. Quatro componentes devem entrar em acordo sobre uma cadeia de identidade:
- Uma autoridade certificadora. Comece com o Microsoft PKI, AD CS ou um provedor de certificados gerenciado. A CA deve emitir certificados com EKU de Client Authentication antes que a política RADIUS seja ajustada, e o serviço RADIUS deve confiar na cadeia emissora.
- Uma camada RADIUS. NPS, Aruba ClearPass, Cisco ISE ou uma plataforma RADIUS-as-a-Service encerra a troca 802.1X a partir dos pontos de acesso. O Entra ID não possui recurso RADIUS nativo. A extensão NPS adapta as solicitações RADIUS para verificações baseadas no Entra, em vez de transformar o Entra em um servidor RADIUS, conforme explicado no Microsoft Q&A sobre a limitação do RADIUS.
- Intune. O Intune entrega a raiz confiável, o perfil de certificado SCEP ou PKCS e a configuração de WiFi. Suas atribuições também controlam o escopo do dispositivo, de modo que um perfil inacabado não atinja toda a organização.
- 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 varejo restrita ou uma ACL específica do dispositivo.
Construa na ordem de dependência
Publique e valide o modelo de CA antes de ajustar o RADIUS. Verifique o emissor, o assunto ou SAN, a cadeia de certificados e o EKU de Autenticação do Cliente. Caso contrário, falhas de handshake podem parecer problemas de RF ou SSID quando o dispositivo não possui um certificado utilizável.
A confiança deve funcionar em ambas as direções. Os dispositivos gerenciados 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 compartilhado. Eles não se autenticam diretamente no Entra.
Decida onde a política reside
NPS, ClearPass e ISE podem impor políticas de rede sem fio, mas seus modelos de regras e tratamento de atributos diferem. Selecione uma única fonte de verdade para o mapeamento de SSID para VLAN, documente-a e evite que os painéis de AP e as regras de RADIUS produzam resultados conflitantes.
Uma listagem do setor público do Reino Unido descreve o suporte do Entra ID para autenticação de 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.
Emitindo certificados e distribuindo perfis de WiFi pelo Intune
Para dispositivos gerenciados, o EAP-TLS tem sucesso ou falha na seleção do certificado. O Intune pode entregar o perfil sem interação do usuário, mas não pode compensar um modelo de certificado que carece do uso, emissor ou mapeamento de assunto corretos.
Estabeleça o caminho do certificado
Implante o perfil de CA raiz confiável primeiro. Com o SCEP, crie um perfil de certificado que aponte para o serviço NDES e use 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 solicitações não autorizadas.
O próprio certificado precisa de Autenticação de Cliente em seu uso estendido de chave. Decida se o assunto e o SAN identificam o dispositivo, o usuário ou ambos. Essa decisão afeta o mapeamento do RADIUS, o comportamento de dispositivos compartilhados e como você investigará um evento de autenticação mais tarde.
Um perfil PFX pode funcionar onde os certificados são gerados e empacotados por meio de um fluxo de trabalho aprovado, mas o SCEP geralmente é mais fácil de operar em um parque de dispositivos gerenciados diversificado, pois o dispositivo pode solicitar e renovar seu próprio certificado. O ponto importante é a consistência. Cada plataforma deve receber uma cadeia e um certificado que a política de RADIUS compreenda.
Configure o payload de WiFi
Crie o perfil de WiFi com o SSID, modo de segurança e método EAP exatos. Selecione EAP-TLS, vincule o perfil ao certificado emitido pela configuração SCEP e ative a validação de certificado do servidor. Adicione os nomes exatos dos servidores RADIUS para que o dispositivo não aceite um serviço semelhante durante a decisão de confiança. As diretrizes de implantação do Reino Unido alinhadas com a Microsoft recomendam uma raiz confiável, um perfil de certificado de cliente SCEP e nomes de RADIUS precisos no perfil de WiFi (orientações de configuração de WiFi do Microsoft Entra ID no Reino Unido).
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 implantado, mas o sistema operacional não puder selecionar esse certificado, o dispositivo poderá recorrer a um método inadequado ou rejeitar a conexão.
Defina o escopo dos perfis SCEP e WiFi para o mesmo grupo de dispositivos piloto. Verifique os logs dos dispositivos quanto à instalação do certificado, confirme se a raiz é confiável 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 voltado para o público, mas a solução de problemas internos de EAP-TLS ainda depende dos logs do dispositivo e do RADIUS.
Conectando tudo à sua rede e camada RADIUS
O ponto de acesso vê um suplicante 802.1X. Ele não vê o Entra ID. O dispositivo apresenta 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 usual é:
- O dispositivo se associa ao SSID corporativo.
- O AP encaminha o tráfego EAP-TLS para o NPS, ClearPass, ISE ou um serviço RADIUS hospedado.
- O RADIUS valida o certificado do cliente em relação à CA emissora confiável.
- O mecanismo de política mapeia a identidade do certificado para uma conta, dispositivo ou grupo.
- A resposta RADIUS atribui a VLAN ou política de acesso permitida.
Diferenças de configuração entre fornecedores
Os painéis do Meraki geralmente exigem os detalhes do servidor RADIUS, segredo compartilhado e configurações de validação de certificado, com a substituição de AAA usada onde a resposta RADIUS controla a segmentação. As implantações do Aruba dependem frequentemente de um grupo de servidores RADIUS e regras de derivação de servidor. O Ruckus SmartZone precisa de configuração AAA com EAP-TLS selecionado, enquanto os modelos de WLAN do Juniper Mist apontam para o cluster RADIUS. O UniFi Network usa um perfil RADIUS e pode exigir um manuseio cuidadoso onde o EAP-TTLS herdado permanece ao lado do EAP-TLS.
O RADIUS-as-a-Service da Purple é uma opção hospedada para ambientes que desejam uma camada RADIUS separada sem operar a plataforma de servidor completa. NPS, ClearPass, ISE e serviços hospedados podem todos se ajustar, mas eles não interpretarão todos os atributos de certificado ou condições de política de forma idêntica.
| Fabricante | Servidor RADIUS auth | Tipo de EAP | Atributo do certificado | Problema comum |
|---|---|---|---|---|
| Meraki | NPS, ISE, ClearPass ou RADIUS hospedado | EAP-TLS | Emissor e SAN | A substituição de AAA pode colocar um usuário válido na VLAN incorreta |
| Aruba | NPS, ClearPass, ISE ou RADIUS hospedado | 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 conectado ao SmartZone | EAP-TLS | Assunto e emissor | A incompatibilidade do tipo de EAP é fácil de passar despercebida nas configurações de AAA |
| Juniper Mist | Cluster RADIUS | EAP-TLS | SAN ou identidade mapeada | O modelo de WLAN pode fazer referência a um grupo de servidores incompleto |
| UniFi | Perfil RADIUS do aplicativo 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 é presumir que o nome comum é o nome de usuário quando o serviço RADIUS analisa o SAN como um UPN. Isso quebra o mapeamento de usuários e também pode interromper os fluxos de apenas dispositivo ou de dispositivos compartilhados.
Use um cluster RADIUS com balanceamento de carga onde o parque de dispositivos exige resiliência e defina temporizadores de failover sensatos por SSID. Não presuma que um serviço de RADIUS na nuvem impõe a revogação em tempo real. Algumas soluções hospedadas carecem de validação CRL ou OCSP acessível, portanto, o certificado pode continuar sendo aceito 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 pode se registrar. É o que acontece depois que o RH desativa uma conta.
O Acesso Condicional avalia os logins suportados do Entra. Ele não interfere em uma sessão 802.1X já estabelecida para encerrá-la apenas porque o status de um diretório foi alterado. Um certificado já instalado em um laptop pode permanecer criptograficamente válido até expirar ou até que o serviço RADIUS o rejeite por meio da verificação de revogação de certificado. Isso torna o design de revogação mais importante do que a demonstração de inscrição.
Reduza 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 apresentando uma credencial 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 confiável, portanto, teste dispositivos que passam algum tempo offline ou 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 e, em seguida, confirme se os servidores RADIUS a consultam. As configurações de NPS e ClearPass podem parecer íntegras mesmo ignorando a revogação se a verificação estiver desativada ou se o ponto de distribuição estiver inacessível a partir da rede RADIUS.
A medida operacional que importa é o intervalo entre a desativação no diretório e o primeiro pacote de rede sem fio rejeitado.
Os fluxos de trabalho de desativação e limpeza do Intune ainda são valiosos, principalmente para dispositivos perdidos ou compartilhados, mas eles não apagam magicamente um certificado de um endpoint desligado. O certificado torna-se inutilizável por expiração, revogação ou remoção quando o dispositivo receber as próximas instruções de gerenciamento. As equipes devem documentar essa janela de tempo e testá-la durante os exercícios de offboarding.
O Entra Continuous Access Evaluation suporta decisões rápidas de controle para cenários selecionados de aplicativos em nuvem. No momento, ele não torna o EAP-TLS uma transação de Conditional Access baseada em navegador, portanto, o WiFi ainda depende da validade do certificado e do comportamento de revogação do RADIUS. Para leitores que estão revisando o modelo de autenticação mais amplo, este guia de MFA para usuários de Edmonton fornece um contexto útil sobre como a garantia de login mais forte se difere da autenticação por certificado de rede.
O acesso de convidados precisa de seu próprio plano de controle. A prática do setor público do Reino Unido, incluindo o GovWifi, reforça que os visitantes e o acesso compartilhado não devem ser forçados a seguir o mesmo fluxo de trabalho de certificado de funcionários (guia de integração do UK Entra WiFi).
Testando e solucionando problemas em modos de falha comuns
Um teste de laboratório prova que um dispositivo consegue se conectar. Uma implantação em produção prova que o dispositivo errado não consegue se conectar, que um certificado revogado é rejeitado e que um convidado não consegue herdar a política da equipe.
Comece com o certificado
Para uma falha de EAP-TLS, inspecione o certificado do cliente antes de alterar o AP. Confirme a cadeia, o emissor, o SAN, o vencimento e o EKU de Autenticação do Cliente. Em seguida, verifique se o perfil de WiFi seleciona esse certificado e se o dispositivo confia no certificado do servidor RADIUS.
Loops de SCEP geralmente indicam uma incompatibilidade entre o Intune, NDES e o modelo de certificado. Verifique a URL de desafio, confirme se a conta do conector NDES possui as permissões de modelo necessárias e compare a URI do perfil SCEP com a URL do NDES publicada, incluindo sua barra final. Um certificado emitido a partir do modelo errado pode parecer uma inscrição bem-sucedida, mas permanecer inutilizável para WiFi.
Teste a relação de confiança e a segmentação
Um Evil Twin pode transmitir o mesmo SSID antes que a validação do certificado ocorra. Configure a validação do certificado do servidor, especifique os nomes de RADIUS esperados no perfil de WiFi do Intune e use configurações de rede gerenciada para que o sistema operacional não se conecte livremente a um impostor. Ative os Protected Management Frames onde os clientes e os pontos de acesso forem compatíveis, e use um SSID específico da organização em vez de um nome genérico.
Um certificado revogado que ainda autentica geralmente aponta para o servidor RADIUS, não para o Entra. Verifique se a validação de CRL está habilitada e, em seguida, confirme se a sub-rede RADIUS pode resolver e alcançar o ponto de distribuição. Se o OCSP for usado, inspecione o tempo limite e a capacidade de alcance do respondedor, em vez de presumir que o serviço está verificando automaticamente.
A sobreposição entre visitantes e funcionários geralmente decorre da ordem das políticas. Coloque as regras de EAP-TLS para funcionários antes das regras baseadas em MAC ou PSK para visitantes e, em seguida, verifique os atributos de VLAN retornados no log do RADIUS. Uma autenticação válida com a VLAN incorreta é uma falha de política, não uma falha de registro.
Use uma ordem de triagem fixa
Conexões iniciais lentas podem resultar do tempo de renovação do certificado, endpoints de revogação inacessíveis ou do sistema operacional selecionando o SSID errado. Não comece reconstruindo o perfil.
- Inspecione o certificado do dispositivo: Verifique a cadeia, EKU, emissor, SAN e validade.
- Capture a troca de dados sem fio: Confirme se o AP encaminha o tráfego EAP para o destino RADIUS pretendido.
- Leia o log de eventos do RADIUS: Use logs do NPS, registros de eventos do ISE ou rastreamento de acesso do ClearPass para identificar o atributo rejeitado.
- Verifique o status do Intune: Confirme se o dispositivo está registrado, recebe os perfis e permanece dentro do grupo de atribuição pretendido.
- Verifique a política retornada: Confirme se as sessões de funcionários e convidados recebem a VLAN e a ACL corretas.
Essa ordem mantém a investigação orientada por evidências. Alterar três camadas de uma vez só costuma ocultar a falha original.
Uma lista de verificação de implantação adaptada e o que vem a seguir
Execute a implementação como uma mudança de serviço controlada, não como um experimento de certificado. Comece com um pequeno grupo de dispositivos que represente a empresa: um laptop Windows moderno, endpoints Apple, hardware Android, dispositivos compartilhados e qualquer equipamento operacional que precise permanecer conectado. A recepção de um hotel, uma ala de hospital e uma loja de varejo podem usar a mesma plataforma de identidade, mas ter requisitos de recuperação muito diferentes.
A sequência de implantação
- Escopo do piloto: Selecione usuários, locais e tipos de dispositivos representativos, incluindo locais com conectividade fraca ou caminhos de gerenciamento restritos.
- Prontidão da CA: Confirme a cadeia emissora, as permissões de modelo, o EKU e os endpoints de revogação antes de criar o perfil de WiFi.
- Construção de perfil do Intune: Crie a raiz confiável, 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 compartilhados, confiança de certificado e regras de mapeamento de identidade à plataforma RADIUS selecionada.
- Isolamento de dispositivos: Atribua perfis ao grupo piloto e mantenha o SSID herdado disponível como um fallback documentado.
- Implantação em massa: Expanda por local ou grupo de dispositivos apenas após a aprovação nos testes de emissão de certificados, atribuição de VLAN e desativação.
- Cadência de auditoria: Revise autenticações com falha, expiração de certificados, capacidade de alcance de revogação e resultados de políticas de funcionários versus convidados.
- Desativação do PSK: Remova SSIDs de chave compartilhada apenas depois que as equipes de suporte tiverem um processo de emergência testado e a frota de dispositivos tiver migrado.
Verificações específicas do Reino Unido são fáceis de esquecer. Confirme se os dispositivos BYOD da Apple confiam na cadeia emissora por meio do caminho de gerenciamento pretendido. Defina como os segredos compartilhados do RADIUS são rotacionados, registre onde a telemetria de certificados é armazenada para revisão da GDPR e alinhe os logs de autenticação com os requisitos de auditoria do PSN da organização ou específicos do setor. Hospitais e propriedades compartilhadas do setor público também precisam de um SSID de interrupção documentado ou de um processo de acesso alternativo que não se torne uma rede não gerenciada permanente.
Estima-se que as passkeys se tornarão o método de autenticação padrão para login do Entra em 2026, de acordo com a atualização do ecossistema da Microsoft (Microsoft Entra passkeys update). Isso não torna o trabalho atual com EAP-TLS descartável. As passkeys lidam com o login de identidade interativo, enquanto o WiFi ainda precisa de uma credencial de rede verificável por máquina, decisão de política e troca RADIUS. A CA, o gerenciamento de dispositivos e a disciplina de políticas desenvolvidos para certificados continuam sendo bases úteis para o próximo modelo de identidade.
Se o seu parque de dispositivos ainda depende de uma chave compartilhada ou assume que o Microsoft Entra ID pode responder a solicitações RADIUS diretamente, documente primeiro os SSIDs atuais, a autoridade de certificação, os grupos de dispositivos e a política RADIUS. Em seguida, pilote o 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 oferece uma plataforma de WiFi baseada em identidade e RADIUS em nuvem que pode conectar o acesso de funcionários baseado no Microsoft Entra ID com políticas de rede em ambientes de múltiplos fornecedores. Visite a Purple para avaliar como seus recursos de acesso de visitantes e WiFi de funcionários com nível de certificado podem se adequar à sua implementação no Reino Unido.
