Como Configurar o Azure Entra ID (Azure AD) para Autenticação WiFi

Este guia de referência detalha a arquitetura, os passos de implementação e o impacto empresarial da integração do Azure Entra ID com o 802.1X para autenticação WiFi empresarial. Fornece aos arquitetos de rede e gestores de TI estratégias práticas de implementação, substituindo as PSKs legadas por um acesso à rede baseado em certificados e de confiança zero (zero-trust).

📖 4 min de leitura📝 945 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast

[INTRO - 1 MIN]
Host: Bem-vindos ao Purple Enterprise Network Briefing. Sou o vosso anfitrião e hoje vamos abordar uma atualização de infraestrutura crítica que está no topo das prioridades dos CTOs e arquitetos de rede: a migração da autenticação do vosso WiFi corporativo para o Azure Entra ID — anteriormente Azure AD. Se gerem uma cadeia de hotéis, um estádio ou uma grande infraestrutura do setor público, conhecem bem a dor de cabeça que são os servidores RADIUS locais legados e as PSKs partilhadas. Hoje, falamos de acesso à rede de confiança zero (zero-trust), especificamente sobre como implementar a autenticação baseada em certificados 802.1X utilizando o Azure Entra ID. Sem rodeios, apenas a realidade técnica desta implementação.

[TECHNICAL DEEP-DIVE - 5 MIN]
Host: Vamos diretos à arquitetura. Os dias do WPA2-Personal com uma palavra-passe partilhada num post-it chegaram ao fim. Numa empresa moderna, quer estejam a proteger as operações de back-of-house num ambiente de retalho ou as redes de funcionários num hospital, precisam de um acesso baseado na identidade.

Quando falamos de Azure Entra ID para WiFi, estamos fundamentalmente a falar de EAP-TLS. Ou seja, Extensible Authentication Protocol com Transport Layer Security. É o padrão de excelência. Porquê? Porque depende de certificados, não de palavras-passe. As palavras-passe podem ser alvo de phishing, partilhadas ou descobertas por força bruta. Os certificados associados a um dispositivo gerido via Intune não podem.

Então, como flui o tráfego? Um dispositivo corporativo — por exemplo, um portátil gerido — tenta ligar-se ao SSID corporativo. O ponto de acesso sem fios, agindo como autenticador, bloqueia o acesso e envia as credenciais via RADIUS para o vosso servidor de autenticação. Ora, o Azure Entra ID não comunica nativamente em RADIUS. Esta é a ponte arquitetónica crítica. Precisam de um fornecedor de Cloud RADIUS ou de um Network Policy Server (NPS) local com a extensão Azure MFA.

O dispositivo apresenta o seu certificado de cliente. O servidor RADIUS valida esse certificado na vossa Autoridade de Certificação — frequentemente gerida via SCEP no Intune. Se o certificado for válido, o servidor RADIUS consulta o Azure Entra ID para garantir que a conta de utilizador está ativa, não desativada e em conformidade com as políticas de Conditional Access. Só então o servidor RADIUS envia uma mensagem Access-Accept de volta para o ponto de acesso, colocando o utilizador na VLAN correta.

[IMPLEMENTATION RECOMMENDATIONS & PITFALLS - 2 MIN]
Host: Agora, onde é que as implementações costumam falhar? Identifico três erros comuns.

Primeiro: a disponibilidade da Lista de Revogação de Certificados (CRL). Se o vosso servidor RADIUS não conseguir aceder à CRL, a autenticação falha. Garantam que os vossos endpoints de CRL estão altamente disponíveis e acessíveis a partir da infraestrutura RADIUS.

Segundo: a configuração do supplicant. Não deixem isto para o utilizador final. Utilizem o vosso MDM — Microsoft Intune, Workspace ONE, o que utilizarem — para enviar o perfil de WiFi. O perfil deve definir explicitamente a CA raiz de confiança e especificar que o cliente só se deve ligar aos nomes específicos do vosso servidor RADIUS. Se não o fizerem, ficam vulneráveis a ataques do tipo Evil Twin.

Terceiro: dispositivos legados. Dispositivos IoT, terminais de ponto de venda ou leitores de códigos de barras mais antigos num armazém muitas vezes não suportam 802.1X ou EAP-TLS. Devem planear uma estratégia de MAC Authentication Bypass (MAB) ou uma rede dedicada com chave pré-partilhada e isolamento de rede rigoroso para estes dispositivos. Não comprometam o vosso SSID corporativo principal por causa de uma impressora antiga.

[RAPID-FIRE Q&A - 1 MIN]
Host: Vamos a algumas perguntas rápidas que costumamos ouvir dos arquitetos de rede.

Pergunta um: Podemos utilizar PEAP-MSCHAPv2 com o Azure Entra ID?
Resposta: Sim, através de NPS, mas a Microsoft está a descontinuar ativamente a autenticação baseada em credenciais. Migrem para EAP-TLS. É mais seguro e proporciona uma melhor experiência de utilizador.

Pergunta dois: Como é que isto se integra com o WiFi de convidados da Purple?
Resposta: Mantenham-nos separados. A vossa rede corporativa utiliza 802.1X associado ao Azure Entra ID. A vossa rede de convidados utiliza um SSID aberto com um Captive Portal gerido pela Purple para análise de dados, aceitação de termos e captura de dados de marketing. Podem inclusivamente utilizar a autenticação baseada em perfil da Purple para visitas de retorno fluidas dos convidados, mantendo esse tráfego completamente isolado dos vossos dados corporativos.

[SUMMARY & NEXT STEPS - 1 MIN]
Host: Para resumir: a transição para o Azure Entra ID para autenticação WiFi é um passo fundamental em direção a uma arquitetura de confiança zero (zero-trust). Elimina os pedidos de suporte para alteração de palavras-passe, mitiga o roubo de credenciais e garante que apenas dispositivos geridos e em conformidade acedem à vossa rede interna.

O vosso próximo passo? Auditar a vossa infraestrutura RADIUS atual. Se estão a executar um NPS legado localmente, avaliem soluções de Cloud RADIUS que se integrem diretamente com o Azure Entra ID e o Intune. Desenhem a vossa estratégia de implementação de certificados.

Obrigado por acompanharem este briefing técnico. Protejam as vossas redes e até à próxima.

Resumo Executivo

Para CTOs e arquitetos de rede que gerem ambientes complexos — desde grandes espaços de Hospitality a áreas dinâmicas de Retail —, proteger a rede corporativa já não se resume a palavras-passe fortes. As chaves pré-partilhadas (PSKs) legadas e a autenticação básica por credenciais são fundamentalmente incompatíveis com as arquiteturas modernas de zero-trust.

Este guia detalha a transição para a autenticação WiFi baseada em certificados 802.1X integrada diretamente com o Azure Entra ID (anteriormente Azure AD). Ao migrar para o EAP-TLS (Extensible Authentication Protocol com Transport Layer Security), as organizações podem eliminar os riscos associados ao roubo de credenciais, automatizar a integração de dispositivos através de Mobile Device Management (MDM) e garantir que apenas dispositivos geridos e em conformidade podem aceder a VLANs corporativas confidenciais. Vamos explorar a arquitetura técnica, as etapas de implementação e como esta postura de segurança corporativa corre em paralelo com as estratégias de rede de convidados geridas por plataformas como a Purple.

Análise Técnica Detalhada

A Transição de Credenciais para Certificados

Historicamente, o WiFi empresarial dependia do PEAP-MSCHAPv2, exigindo que os utilizadores introduzissem as suas credenciais de domínio. No entanto, a Microsoft está a descontinuar ativamente a autenticação baseada em credenciais devido à sua vulnerabilidade a ataques de adversário no meio (AiTM). O padrão da indústria é agora o EAP-TLS, que utiliza autenticação mútua por certificado.

Numa implementação EAP-TLS, tanto o servidor RADIUS como o dispositivo cliente apresentam certificados digitais. Se um dispositivo não possuir um certificado válido emitido pela sua Autoridade de Certificação (CA) fidedigna, o servidor RADIUS rejeita a ligação antes mesmo de o dispositivo obter um endereço IP.

A Ponte Arquitetónica: RADIUS e Entra ID

O Azure Entra ID é um fornecedor de identidade (IdP) na nuvem que utiliza protocolos modernos como SAML e OIDC; não comunica nativamente em RADIUS, o protocolo utilizado pelos pontos de acesso sem fios (WAPs). Para colmatar esta lacuna, os arquitetos de rede devem implementar um servidor RADIUS capaz de comunicar com o Entra ID. Isto é normalmente alcançado através de:

Soluções RADIUS na Nuvem: Plataformas concebidas para o efeito (por exemplo, SecureW2, SCEPman ou Portnox) que se integram diretamente com o Entra ID e o Intune através de APIs.
Servidor de Políticas de Rede (NPS) Local: Utilizando a extensão Azure MFA, embora esta seja cada vez mais vista como uma abordagem legada em comparação com o RADIUS nativo na nuvem.

Guia de Implementação

A implementação do Azure Entra ID para autenticação WiFi requer coordenação entre as equipas de identidade, gestão de dispositivos e infraestrutura de rede.

Passo 1: Estabelecer a Infraestrutura de Chaves Públicas (PKI)

Deve estabelecer uma CA para emitir certificados de cliente e servidor. Num ambiente prioritariamente na nuvem, trata-se frequentemente de uma PKI na nuvem integrada com o Microsoft Intune através do Simple Certificate Enrollment Protocol (SCEP).

Passo 2: Configurar o Servidor RADIUS

Implemente a sua infraestrutura RADIUS e associe-a ao seu inquilino do Entra ID. O servidor RADIUS necessita do seu próprio certificado de servidor, fidedigno para os seus dispositivos cliente, para provar a sua identidade durante o handshake EAP.

Passo 3: Implementar Perfis de MDM através do Intune

Não dependa dos utilizadores para configurar manualmente as suas definições de WiFi. Utilize o Intune para enviar um perfil de WiFi abrangente que inclua:

O certificado da CA Raiz fidedigna.
O perfil SCEP para solicitar o certificado de cliente.
A própria configuração de WiFi, definindo explicitamente o SSID e os nomes exatos dos servidores da sua infraestrutura RADIUS para evitar ataques Evil Twin.

Passo 4: Configurar o Controlador de LAN Sem Fios (WLC)

Configure os seus pontos de acesso ou WLC para utilizar WPA2/WPA3-Enterprise (802.1X). Direcione o tráfego de autenticação e faturação para os novos endereços IP do seu servidor RADIUS e configure os segredos RADIUS partilhados.

> "Ao configurar o 802.1X, certifique-se de que os valores de timeout do RADIUS no WLC são suficientes para lidar com a latência da validação de certificados baseada na nuvem, aumentando normalmente de 2 segundos para 5 segundos." [1]

Boas Práticas

Separar o Tráfego Corporativo do de Convidados: Os dispositivos corporativos devem utilizar o 802.1X associado ao Entra ID. Os dispositivos de convidados devem utilizar um SSID aberto com um Captive Portal. Para um acesso de convidados e análises robustos, aproveite as soluções de Guest WiFi . Isto garante o isolamento total do tráfego não fidedigno.
Implementar o MAC Authentication Bypass (MAB) com Cuidado: Os dispositivos IoT e o hardware legado (por exemplo, scanners antigos em centros de Transport ) frequentemente não suportam o 802.1X. Coloque-os num SSID separado utilizando MAB ou uma PSK dedicada, e restrinja o seu acesso à rede através de ACLs rigorosas.
Priorizar a Revogação de Certificados: Garanta que os seus endpoints de Lista de Revogação de Certificados (CRL) ou Online Certificate Status Protocol (OCSP) estão altamente disponíveis. Se o servidor RADIUS não conseguir verificar o estado de revogação, a autenticação irá falhar.

Resolução de Problemas e Mitigação de Riscos

Quando as implementações falham, raramente a culpa é do IdP na nuvem. Os modos de falha comuns incluem:

Desvio de Relógio (Clock Skew): O EAP-TLS é extremamente sensível ao tempo. Certifique-se de que todos os componentes da infraestrutura, especialmente o WLC e os servidores RADIUS, estão sincronizados via NTP.
Atrasos de Sincronização do Intune: Quando um novo dispositivo é registado, pode demorar algum tempo até que o certificado SCEP seja emitido e o dispositivo tente a ligação. Planeie esta latência durante a integração.
Incompatibilidade de Nome do Servidor Radius: Se o nome do servidor definido no perfil de WiFi do Intune não corresponder exatamente ao Common Name (CN) ou Subject Alternative Name (SAN) no certificado do servidor RADIUS, o cliente irá silenciosamente interromper a ligação para se proteger contra APs fraudulentos.

Para obter mais informações sobre como proteger a sua infraestrutura, consulte o nosso guia sobre como Proteger a sua Rede com DNS Forte e Segurança .

ROI e Impacto no Negócio

A transição para a autenticação WiFi do Azure Entra ID proporciona retornos mensuráveis:

Redução de Custos de Helpdesk: A eliminação da autenticação baseada em palavra-passe reduz drasticamente os pedidos de suporte relacionados com bloqueios de palavras-passe e atualizações de credenciais de WiFi.
Aceleração da Conformidade: O EAP-TLS fornece a prova criptográfica de identidade exigida por estruturas como PCI DSS e ISO 27001, crucial para ambientes de Saúde e retalho.
Desativação Automatizada: Quando um colaborador sai, a desativação da sua conta no Entra ID revoga imediatamente o seu acesso à rede em todos os locais, mitigando ameaças internas.

Ao proteger a infraestrutura corporativa, as equipas de TI podem concentrar-se em iniciativas geradoras de receita, tais como tirar partido do WiFi Analytics para compreender o comportamento dos visitantes e impulsionar o envolvimento.

Referências

[1] Microsoft Learn. (2023). Secure Wi-Fi access with Intune and EAP-TLS.

Definições Principais

802.1X

Uma norma IEEE para controlo de acesso à rede baseado em portas, que exige que os dispositivos se autentiquem antes de obterem acesso à LAN ou WLAN.

Este é o protocolo subjacente que torna o WiFi empresarial seguro, indo além das simples palavras-passe partilhadas.

EAP-TLS

Extensible Authentication Protocol com Transport Layer Security. Um método de autenticação que exige certificados digitais tanto no cliente como no servidor.

Considerado o método mais seguro para autenticação WiFi, prevenindo o roubo de credenciais e ataques AiTM.

RADIUS

Remote Authentication Dial-In User Service. Um protocolo de rede que fornece serviços centralizados de Autenticação, Autorização e Contabilização (AAA).

O protocolo que os seus pontos de acesso utilizam para perguntar ao servidor de autenticação: 'Devo permitir este dispositivo na rede?'

SCEP

Simple Certificate Enrollment Protocol. Um protocolo utilizado para emitir certificados de forma segura para dispositivos de rede.

Utilizado por plataformas MDM como o Intune para solicitar e instalar silenciosamente certificados de cliente em portáteis e telemóveis corporativos.

MAC Authentication Bypass (MAB)

Um método de concessão de acesso à rede baseado no endereço MAC do dispositivo, em vez de um nome de utilizador ou certificado.

Utilizado como alternativa para dispositivos legados (como impressoras antigas ou sensores IoT) que não possuem o software necessário para realizar o handshake 802.1X.

Evil Twin Attack

Um ponto de acesso não autorizado (rogue) que se disfarça de um SSID corporativo legítimo para intercetar tráfego ou roubar credenciais.

O EAP-TLS mitiga este ataque porque o dispositivo cliente está configurado para confiar apenas no certificado específico do servidor RADIUS corporativo legítimo.

Supplicant

O cliente de software no dispositivo final (por exemplo, o gestor de WiFi do Windows) que lida com o processo de autenticação 802.1X.

As equipas de TI devem configurar o supplicant via MDM para garantir que este se comporta de forma segura e não solicita aos utilizadores que aceitem certificados de servidor não confiáveis.

Conditional Access

Políticas do Azure Entra ID que avaliam sinais (utilizador, localização, conformidade do dispositivo) para tomar decisões de acesso.

As soluções modernas de Cloud RADIUS podem verificar o Conditional Access durante o handshake do WiFi, negando o acesso à rede se o Intune sinalizar o dispositivo como não conforme.

Exemplos Práticos

Uma cadeia de retalho com 500 lojas precisa de proteger os iPads de back-of-house utilizados para a gestão de inventário. Atualmente, utilizam uma única PSK partilhada em todas as lojas. Como devem migrar para a autenticação do Azure Entra ID?

Registar todos os iPads no Microsoft Intune.
Implementar uma solução Cloud RADIUS integrada com o tenant corporativo do Entra ID.
Configurar o Intune para implementar um certificado SCEP em cada iPad.
Enviar um perfil de WiFi através do Intune que configure os iPads para se ligarem ao SSID 'Corporate-BOH' utilizando EAP-TLS, validando o certificado do servidor Cloud RADIUS.
Atualizar os pontos de acesso Meraki/Aruba em todas as 500 lojas para apontarem para os endereços IP do Cloud RADIUS para o SSID 'Corporate-BOH'.
Implementação faseada: Ativar o novo SSID, verificar a conectividade dos iPads através dos relatórios do Intune e, em seguida, desativar o SSID com a PSK legada.

Comentário do Examinador: Esta abordagem elimina a PSK partilhada, que representa um enorme risco de segurança caso um dispositivo seja roubado. Ao utilizar EAP-TLS e o Intune, a autenticação fica associada ao estado de gestão do dispositivo. Se um iPad for perdido, a equipa de TI simplesmente revoga o certificado ou limpa o dispositivo no Intune, cortando instantaneamente o acesso à rede sem afetar as outras 499 lojas.

O campus de uma universidade está a migrar do Active Directory local para o Azure Entra ID. Têm milhares de portáteis pessoais de estudantes (BYOD) que atualmente se ligam utilizando PEAP-MSCHAPv2 (nome de utilizador e palavra-passe). Como devem gerir o BYOD num ambiente Entra ID cloud-first?

Implementar um portal de integração (por exemplo, SecureW2 JoinNow ou uma ferramenta de integração BYOD semelhante).
Os estudantes ligam-se a um SSID 'Onboarding' aberto, que os redireciona para o portal.
O portal solicita ao estudante que se autentique no Azure Entra ID (utilizando o seu e-mail universitário e MFA).
Após a autenticação bem-sucedida, o portal gera um certificado de cliente exclusivo e configura automaticamente o dispositivo do estudante para EAP-TLS.
O dispositivo liga-se automaticamente ao SSID seguro 'Edu-Secure' utilizando o novo certificado.

Comentário do Examinador: A gestão de certificados para dispositivos BYOD não geridos é a parte mais difícil do 802.1X. Não é possível utilizar o Intune porque a universidade não é proprietária dos portáteis. A utilização de um portal de integração colmata esta lacuna, permitindo a utilização de EAP-TLS seguro sem exigir que a equipa de TI configure manualmente milhares de portáteis de estudantes.

Perguntas de Prática

Q1. A sua organização está a migrar para o Azure Entra ID e para o Intune. Atualmente, utiliza PEAP-MSCHAPv2 para o WiFi. A equipa de segurança exige que a autenticação WiFi seja resistente ao roubo de credenciais. Qual o método EAP que deve implementar?

Dica: Qual é o método que depende inteiramente de certificados em vez de palavras-passe?

Ver resposta modelo

Deve implementar o EAP-TLS. O EAP-TLS utiliza autenticação mútua por certificado, o que significa que o dispositivo cliente deve apresentar um certificado válido emitido pela sua PKI. Como não utiliza palavras-passe, é altamente resistente ao roubo de credenciais e a ataques de intermediário (adversary-in-the-middle).

Q2. Após a implementação do EAP-TLS via Intune, os utilizadores reportam que não se conseguem ligar ao WiFi. Ao analisar os registos do RADIUS, depara-se com a mensagem 'Certificate Revocation Check Failed'. Qual é a causa mais provável?

Dica: Com que infraestrutura deve o servidor RADIUS comunicar para verificar se um certificado não foi comprometido?

Ver resposta modelo

O servidor RADIUS não consegue aceder à Lista de Revogação de Certificados (CRL) ou ao endpoint OCSP da sua Autoridade de Certificação. Certifique-se de que as firewalls permitem ao servidor RADIUS o acesso de saída aos URLs HTTP especificados nos certificados de cliente.

Q3. Um hospital precisa de ligar 50 monitores de ritmo cardíaco legados à rede. Estes dispositivos apenas suportam WPA2-Personal (Pre-Shared Key) e não podem ser registados no Intune. Como deve protegê-los, mantendo a sua implementação de 802.1X com o Entra ID para os portáteis corporativos?

Dica: Não misture tipos de autenticação no mesmo SSID.

Ver resposta modelo

Crie um SSID dedicado e separado especificamente para os dispositivos IoT médicos. Utilize uma Pre-Shared Key forte e exclusiva (ou Identity PSK/iPSK, se suportado pelo seu fornecedor de rede) ou MAC Authentication Bypass (MAB). Crucialmente, coloque este SSID numa VLAN altamente restrita com Listas de Controlo de Acesso (ACLs) rigorosas que apenas permitam aos monitores comunicar com o seu servidor médico específico, bloqueando qualquer outro acesso lateral à rede.

Continue a ler esta série

Per-Device PSK por Fabricante: iPSK, DPSK, MPSK e PPSK Comparados (e Suporte a WPA3)

Uma comparação abrangente de implementações de per-device PSK na Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Saiba como o WPA3-SAE afeta as estratégias de chaves por dispositivo e quando implementar modos de transição versus migrar para o 802.1X.

Métodos de Autenticação de Captive Portal Comparados

Este guia de referência técnica de autoridade avalia as compensações arquitetónicas, operacionais e de conformidade de cinco métodos principais de autenticação de captive portal. Fornece aos arquitetos de rede, diretores de TI e gestores de marketing os dados quantitativos e as estruturas de decisão necessários para equilibrar a fricção no registo de convidados com os requisitos de recolha de dados em locais empresariais.

O que é a Autenticação por Endereço MAC? Quando Usar e Quando Evitar

Este guia de referência técnica abrangente aborda a autenticação por endereço MAC em ambientes de WiFi empresarial — como funciona a autenticação MAC baseada em RADIUS na Camada 2, as suas vulnerabilidades de segurança inerentes (incluindo falsificação de MAC e o impacto da randomização de MAC ao nível do SO) e os contextos operacionais precisos onde continua a ser uma ferramenta válida para gerir IoT e dispositivos headless. Fornece orientações de implementação práticas para gestores de TI e arquitetos de rede em setores como hotelaria, retalho, saúde e espaços públicos, com exemplos práticos reais, estruturas de decisão e contexto de integração para a plataforma de guest WiFi e analytics da Purple.