Autenticação WiFi empresarial sem Active Directory ou servidor local
Este guia explica como implementar a autenticação WiFi WPA2/3-Enterprise segura sem um Active Directory local, Windows NPS ou servidor RADIUS. Abrange a incompatibilidade de protocolos entre fornecedores de identidade na nuvem e 802.1X, as vantagens do EAP-TLS face ao PEAP-MSCHAPv2 e como implementar o RADIUS na nuvem com certificados emitidos por MDM em conformidade com o Microsoft Entra ID, Okta ou Google Workspace. Escrito para responsáveis de TI em organizações focadas na nuvem e com forte presença de Mac/Chromebook que pretendem descontinuar a infraestrutura local.
Ouça este guia
Ver transcrição do podcast
📚 Part of our core series: Segurança e autenticação WiFi empresarial: o guia completo →
Resumo executivo
A maioria das organizações migrou a sua identidade para a nuvem. O Microsoft Entra ID, o Okta e o Google Workspace gerem agora utilizadores, grupos e políticas de acesso para e-mail, aplicações SaaS e gestão de dispositivos. Mas o WiFi empresarial não acompanhou este ritmo. Os pontos de acesso ainda esperam um servidor RADIUS, e esse servidor RADIUS tem sido historicamente o Windows Network Policy Server (NPS) ligado a um controlador de domínio Active Directory local.
Esta incompatibilidade força as equipas de TI a manter uma infraestrutura local redundante apenas para manter o WiFi a funcionar. A solução é o cloud RADIUS: um serviço de autenticação totalmente gerido que comunica em RADIUS com os seus pontos de acesso e em OAuth2, SCIM e SAML com o seu fornecedor de identidade na nuvem. Combine-o com a entrega de certificados EAP-TLS através do seu MDM e terá uma implementação 802.1X completa, sem servidores locais, sem patches de SO e com revogação instantânea de acessos associada diretamente ao seu diretório na nuvem.
A Purple opera cloud RADIUS em mais de 80.000 locais globalmente, com 99,999% de tempo de atividade (dados internos da Purple, 2024) e integrações nativas com o Microsoft Entra ID, Okta e Google Workspace. Pode estar operacional nos seus pontos de acesso existentes Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet em menos de uma hora.
Análise técnica aprofundada
A incompatibilidade de protocolos no cerne do problema
O desafio fundamental é que os fornecedores de identidade na nuvem e os pontos de acesso WiFi comunicam em linguagens totalmente diferentes. O Microsoft Entra ID (anteriormente Azure AD) autentica utilizadores através de SAML, OIDC e OAuth2 - os protocolos que os browsers e as aplicações SaaS utilizam. Os pontos de acesso WiFi utilizam RADIUS (Remote Authentication Dial-In User Service, RFC 2865), um protocolo baseado em UDP concebido na década de 1990 para ligações dial-up e VPN. A Microsoft nunca disponibilizou um endpoint RADIUS nativo para o Entra ID. Não é possível apontar um ponto de acesso Meraki ou Aruba diretamente para o Azure e esperar que o 802.1X funcione.
Este é o obstáculo com que todas as equipas de TI focadas na nuvem se deparam quando tentam proteger o WiFi dos colaboradores com WPA2-Enterprise ou WPA3-Enterprise. Algo tem de fazer a ponte entre o ponto de acesso e o fornecedor de identidade na nuvem. Esse algo é o cloud RADIUS.
Por que razão o PEAP-MSCHAPv2 falha sem o Active Directory
Historicamente, as implementações 802.1X dependiam do PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2). O utilizador introduzia o seu nome de utilizador e palavra-passe, o ponto de acesso reencaminhava o pedido para o servidor RADIUS e o servidor RADIUS validava a palavra-passe em relação a um hash NTLM armazenado no Active Directory.
O Microsoft Entra ID não armazena hashes NTLM. Isto não é uma falha de configuração - é uma decisão arquitetural deliberada. O Entra ID é um fornecedor de identidade em nuvem moderno, não um controlador de domínio. Consequentemente, um servidor RADIUS apontado para o Entra ID não consegue validar um desafio PEAP-MSCHAPv2. A única forma de fazer o PEAP funcionar com o Entra ID é implementar o Entra Domain Services, um Active Directory gerido e pago que sincroniza a partir do Entra ID, e depois executar o NPS contra este. Isto reintroduz a maior parte do que estava a tentar eliminar: VMs de Windows Server, patching de SO, armazenamento de hashes NTLM e gestão manual de certificados.
EAP-TLS: a resposta certa para organizações cloud-first
O EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) substitui as palavras-passe por certificados digitais X.509. O dispositivo apresenta um certificado ao servidor RADIUS. O servidor RADIUS valida o certificado contra uma Autoridade de Certificação (CA) fidedigna. Como não existe palavra-passe na troca, o servidor RADIUS não necessita de um armazenamento de hashes NTLM. Apenas precisa de confiar na CA e de verificar a pertença a grupos do utilizador no fornecedor de identidade para aplicar a VLAN e a política de acesso corretas.
O EAP-TLS é resistente a phishing por design. Não existe nenhuma credencial para roubar. Cumpre as orientações da CISA sobre autenticação multifator resistente a phishing e alinha-se com os requisitos do PCI DSS para autenticação forte em redes que processam dados de titulares de cartões. É o método de autenticação recomendado pelo IEEE 802.1X para frotas de dispositivos geridos.
Arquitetura de autenticação 802.1X cloud-first: os dispositivos autenticam-se via EAP-TLS através do RADIUS em nuvem da Purple, que valida os certificados e aplica políticas baseadas em grupos a partir do Entra ID, Okta ou Google Workspace.
Como o MDM substitui a CA local
Numa implementação tradicional de 802.1X, os certificados eram emitidos por uma Autoridade de Certificação local a executar o Active Directory Certificate Services (AD CS). Numa implementação cloud-first, o MDM assume esta função utilizando o SCEP (Simple Certificate Enrollment Protocol). O Microsoft Intune, o Jamf Pro e outras plataformas de MDM podem solicitar certificados a uma CA alojada na nuvem e enviá-los silenciosamente para os dispositivos geridos.
O fluxo funciona da seguinte forma. O administrador de TI cria um perfil de certificado SCEP no MDM, direcionado para os grupos de dispositivos que necessitam de acesso WiFi. O MDM envia o certificado para dispositivos Windows, macOS, iOS, iPadOS, Android Enterprise e ChromeOS de forma automática. O utilizador não vê nada. O certificado é associado à identidade do dispositivo no MDM e renova-se automaticamente antes de expirar. Quando o dispositivo se liga ao WiFi, apresenta o certificado ao servidor RADIUS em nuvem, que o valida contra a CA e aplica a política de rede correta.
Para organizações que utilizam o Microsoft Intune, o Microsoft Cloud PKI fornece uma CA totalmente gerida que se integra diretamente com os perfis SCEP do Intune, eliminando a necessidade de um servidor NDES (Network Device Enrollment Service) local. Para frotas Mac e iOS geridas pelo Jamf, a CA integrada do Jamf ou uma CA de nuvem de terceiros servem o mesmo propósito.
SCIM e revogação de acesso instantânea
Um dos aspetos operacionalmente mais importantes do cloud RADIUS é o aprovisionamento SCIM (System for Cross-domain Identity Management). O SCIM é um padrão aberto que envia alterações de identidade da fonte de verdade - o seu fornecedor de identidade na nuvem - para os sistemas dependentes em tempo real. Quando um colaborador é desativado no Entra ID ou Okta, o SCIM envia essa alteração para o serviço cloud RADIUS imediatamente. Na próxima vez que o dispositivo tentar autenticar-se, o servidor RADIUS devolve um Access-Reject. Com um tempo limite de sessão curto configurado no ponto de acesso, o dispositivo é removido da rede poucos minutos após a conta ser desativada.
Esta é uma melhoria de segurança material em relação às redes PSK partilhadas, onde a única forma de revogar o acesso é alterar a palavra-passe em todos os dispositivos, e em relação às implementações RADIUS legadas que dependem de sincronizações LDAP periódicas com uma janela de horas ou dias.
RadSec: proteger o tráfego RADIUS através da internet
O RADIUS tradicional utiliza UDP e fornece apenas autenticação de mensagens básica. Quando o seu servidor RADIUS está no mesmo centro de dados que os seus pontos de acesso, isto é aceitável. Quando o seu servidor RADIUS é um serviço de nuvem, o tráfego de autenticação atravessa a internet pública. O RadSec (RADIUS sobre TLS, RFC 6614) encripta a troca RADIUS utilizando TLS, fornecendo confidencialidade e integridade para o tráfego de autenticação. A Purple suporta RadSec nativamente, com fallback IPsec para pontos de acesso que ainda não suportam RadSec.
Guia de implementação
A implementação de cloud RADIUS com EAP-TLS requer quatro passos coordenados. Um SSID piloto pode estar ativo em menos de uma hora se o Entra ID e um MDM já estiverem configurados.
Passo 1: Ligar o cloud RADIUS ao seu fornecedor de identidade
Ligue a Purple ao seu fornecedor de identidade através do consentimento de administrador OAuth2 (para Entra ID) ou token de API (para Okta e Google Workspace). Isto autoriza a Purple a ler utilizadores, grupos e associações de grupos a partir do diretório. Configure o aprovisionamento SCIM para enviar alterações de estado do utilizador para a Purple em tempo real. Nenhumas credenciais de principal de serviço são armazenadas no disco. As alterações de grupo propagam-se no evento de autenticação seguinte, e não num agendamento de sincronização.
Passo 2: Configurar o seu MDM e perfil SCEP
No Microsoft Intune, crie um Perfil de Certificado Fidedigno para a raiz da CA e, em seguida, crie um perfil de certificado SCEP que aponte para a CA gerida pela Purple. Defina o âmbito de ambos os perfis para os grupos de dispositivos que necessitam de acesso WiFi. Para o Jamf, configure um payload SCEP num perfil de configuração. O MDM envia os certificados de forma silenciosa. Verifique a entrega dos certificados no painel de conformidade do MDM antes de prosseguir.
Passo 3: Definir políticas de rede no painel do cloud RADIUS
Crie políticas RADIUS que mapeiem grupos de fornecedores de identidade para VLANs e controlos de acesso específicos. Por exemplo, mapeie o grupo do Entra ID "Staff-Finance" para a VLAN 20 com acesso total à internet, e mapeie "Staff-Contractors" para a VLAN 30 com acesso limitado no tempo que expira automaticamente. O painel da Purple aplica estas políticas no momento da autenticação, sem necessidade de alterações na firewall.
Passo 4: Atualizar a configuração do ponto de acesso
Atualize a configuração do SSID nos seus pontos de acesso para utilizar WPA2-Enterprise ou WPA3-Enterprise com 802.1X. Introduza os nomes de anfitrião ou endereços IP dos endpoints primário e secundário do cloud RADIUS da Purple, juntamente com o segredo partilhado. Configure os pontos de acesso para utilizarem a atribuição dinâmica de VLAN com base nos atributos RADIUS devolvidos pela Purple. Teste com um único SSID num subconjunto de pontos de acesso antes de implementar em toda a infraestrutura.
Cloud RADIUS vs RADIUS local: uma comparação direta entre tempo de implementação, dependência do Active Directory, elevada disponibilidade, aplicação de patches do SO, integração de identidade e gestão do ciclo de vida dos certificados.
Melhores práticas
Estas recomendações refletem as normas IEEE 802.1X, os requisitos PCI DSS v4.0 e a experiência operacional em mais de 80.000 locais da Purple.
Exija EAP-TLS para dispositivos geridos. As palavras-passe são suscetíveis a phishing e credential stuffing. Os certificados fornecem prova criptográfica de identidade e conformidade do dispositivo. O EAP-TLS é o único método 802.1X resistente a phishing por conceção.
Utilize SCIM para revogação instantânea. As sincronizações periódicas de LDAP deixam uma janela temporal em que um funcionário demitido mantém o acesso à rede. O SCIM garante que o acesso é revogado no momento em que a conta é desativada no fornecedor de identidade.
Implemente RADIUS multi-região. Configure os seus pontos de acesso com pelo menos dois endpoints RADIUS em regiões geográficas diferentes. A Purple fornece failover multi-região ativo-ativo por predefinição, com o failover a concluir-se em segundos.
Segmente o tráfego com VLANs dinâmicas. Utilize as associações a grupos do fornecedor de identidade para atribuir utilizadores a VLANs específicas de forma dinâmica. Isto isola o tráfego sensível e limita o raio de impacto de um dispositivo comprometido sem exigir alterações manuais na firewall.
Ative o RadSec. Se os seus pontos de acesso suportarem RadSec, ative-o para encriptar o tráfego de autenticação entre o ponto de acesso e o servidor cloud RADIUS. Isto é particularmente importante para filiais e locais onde o ponto de acesso se encontra num segmento de rede não confiável.
Monitorize o ciclo de vida dos certificados. Configure a renovação automática do MDM para ser acionada a 80% do tempo de vida do certificado. Para um certificado de um ano, a renovação começa aos 10 meses. Crie alertas para dispositivos que não consigam renovar antes de o certificado expirar. Para uma abordagem mais ampla sobre normas e estruturas de segurança de WiFi empresarial, consulte o nosso Enterprise WiFi Security: A Complete Guide for 2026 .
Resolução de problemas e mitigação de riscos
A transição para o RADIUS na nuvem introduz novas dependências. Prepare-se para estes modos de falha comuns antes que afetem a produção.
Expiração de certificados. Se o certificado de um dispositivo expirar antes de o MDM o renovar, a autenticação do dispositivo falha silenciosamente. O utilizador vê um erro de ligação sem qualquer explicação. Mitigue este problema configurando a renovação automática do MDM a 80% do tempo de vida do certificado e monitorizando o painel de conformidade do MDM para identificar dispositivos com certificados prestes a expirar.
Falhas de sincronização do MDM. Um dispositivo que deixe de estar em conformidade com o MDM ou que não consiga efetuar a verificação pode não receber um certificado renovado. Implemente políticas de conformidade que sinalizem dispositivos problemáticos e alertem os administradores antes que o certificado expire.
Bloqueio de tráfego RADIUS pela firewall. Os pontos de acesso devem conseguir aceder aos endpoints do RADIUS na nuvem através da porta UDP 1812 (autenticação) e da porta UDP 1813 (accounting), ou da porta TCP 2083 para RadSec. As regras de firewall de saída nas filiais bloqueiam frequentemente estas portas. Teste a acessibilidade a partir da VLAN de gestão do ponto de acesso antes da implementação.
Falhas de aprovisionamento SCIM. Se a ligação SCIM entre o fornecedor de identidade e a Purple for interrompida, as alterações de estado do utilizador não serão propagadas. Monitorize o estado de sincronização do SCIM tanto no fornecedor de identidade como no painel da Purple. Configure alertas para falhas de sincronização.
Dispositivos legados sem suporte para certificados. Dispositivos IoT, impressoras e hardware mais antigo podem não suportar EAP-TLS. Para estes dispositivos, utilize iPSK (chaves pré-partilhadas individuais) em vez de uma PSK partilhada. A Purple suporta iPSK nativamente, atribuindo uma chave exclusiva por dispositivo e colocando cada dispositivo na VLAN correta sem necessitar de suporte de suplicante 802.1X.
ROI e impacto empresarial
A migração de um RADIUS local para o RADIUS na nuvem proporciona um valor mensurável em termos de infraestrutura, operações e segurança.
| Dimensão | NPS local | RADIUS na nuvem (Purple) |
|---|---|---|
| Custo de infraestrutura | Licenças de Windows Server, computação de VM, armazenamento | Subscrição por AP, sem hardware de servidor |
| Tempo de implementação | Dias a semanas | Menos de uma hora |
| Alta disponibilidade | Manual - dois servidores mais replicação | Ativo-ativo multi-região, por predefinição |
| Atualização do SO | Mensal, pela sua equipa | Gerido pelo fornecedor |
| Pedidos de suporte de WiFi | Elevado - reposição de palavras-passe, integração manual | Redução de 80% (dados de clientes Purple) |
| Revogação de acessos | Horas a dias via sincronização LDAP | Segundos via SCIM |
As equipas de TI que utilizam o Staff WiFi da Purple registam tipicamente uma redução de 80% nos pedidos de suporte de WiFi (dados internos da Purple, 2024), impulsionada pela eliminação de reposições de palavras-passe e pela integração manual de dispositivos. A autenticação baseada em certificados também cumpre o requisito 8.3 do PCI DSS para autenticação forte e o controlo A.9.4 da ISO 27001 para controlo de acessos a sistemas e aplicações, reduzindo a carga de auditoria sobre a sua equipa de segurança.
Para organizações no retalho e na hotelaria , a capacidade de gerir o Staff WiFi e o Guest WiFi a partir de um único painel na nuvem - com uma camada de identidade unificada - reduz a complexidade operacional em propriedades multi-site. Para operadores de transportes e prestadores de cuidados de saúde , a capacidade de revogação instantânea e o registo de auditoria completo satisfazem os requisitos regulamentares sem necessidade de ferramentas adicionais.
A camada de WiFi Analytics da Purple adiciona dados de ocupação e de trabalho híbrido sobre a infraestrutura de autenticação, transformando o Staff WiFi de um centro de custos numa fonte de inteligência operacional.
Leitura relacionada: Enterprise WiFi Security: A Complete Guide for 2026 - OpenWrt Custom Firmware Integration with Purple WiFi
Definições Principais
802.1X
Uma norma IEEE (IEEE 802.1X-2020) para controlo de acesso à rede baseado em portas. Exige que os dispositivos se autentiquem antes de o ponto de acesso conceder acesso à rede, utilizando uma troca EAP mediada por um servidor RADIUS.
As equipas de TI utilizam o 802.1X para garantir que apenas utilizadores e dispositivos autorizados se ligam à rede corporativa. Este fornece encriptação por utilizador, chaves por sessão e um registo de auditoria completo de cada evento de ligação.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Contabilização (AAA) para acesso à rede.
Os pontos de acesso encaminham todos os pedidos de ligação para o servidor RADIUS, que decide se admite o dispositivo e qual a VLAN a atribuir-lhe. O Cloud RADIUS substitui os servidores NPS ou FreeRADIUS locais.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Um método de autenticação 802.1X que utiliza a troca mútua de certificados X.509 em vez de palavras-passe.
O EAP-TLS é o padrão de excelência para frotas de dispositivos geridos. É resistente a phishing, não requer armazenamento de hashes de palavras-passe e é o único método 802.1X que cumpre as orientações de MFA resistente a phishing da CISA.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2. Um método 802.1X legado que valida palavras-passe contra hashes NTLM armazenados no Active Directory.
O PEAP-MSCHAPv2 falha em ambientes exclusivamente na nuvem porque o Entra ID não armazena hashes NTLM. As organizações que estão a migrar do AD local devem substituir o PEAP pelo EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Um protocolo utilizado por plataformas MDM para solicitar e instalar automaticamente certificados digitais em dispositivos, sem interação do utilizador.
As equipas de TI utilizam o SCEP com o Intune ou o Jamf para aprovisionar silenciosamente certificados WiFi em dispositivos de colaboradores. O SCEP substitui o servidor NDES (Network Device Enrollment Service) local em implementações prioritariamente na nuvem.
SCIM
System for Cross-domain Identity Management (RFC 7644). Uma norma aberta que automatiza a troca em tempo real de informações de identidade de utilizadores entre sistemas de TI.
O SCIM garante que, quando um colaborador é desativado no Entra ID ou Okta, essa alteração é enviada imediatamente para o serviço Cloud RADIUS, revogando o acesso WiFi em segundos em vez de horas.
NPS
Network Policy Server. A implementação de RADIUS da Microsoft, normalmente executada em Windows Server como parte de um ambiente Active Directory local.
As organizações focadas na nuvem estão a descontinuar o NPS para eliminar VMs de Windows Server, atualizações de SO e a dependência do Active Directory local. O Cloud RADIUS é a substituição direta.
RadSec
RADIUS sobre TLS (RFC 6614). Um protocolo que encripta o tráfego de autenticação RADIUS utilizando TLS, substituindo o transporte de texto simples baseado em UDP utilizado pelo RADIUS tradicional.
O RadSec é essencial ao utilizar o Cloud RADIUS, uma vez que o tráfego de autenticação deve atravessar a internet pública entre o ponto de acesso e o serviço de nuvem. O Purple suporta RadSec nativamente.
iPSK
Individual Pre-Shared Key. Uma variante do WPA2-Personal que atribui uma chave pré-partilhada única a cada dispositivo, em vez de uma única chave partilhada para todos os dispositivos.
O iPSK é utilizado para dispositivos IoT, impressoras e outro hardware que não suporta 802.1X EAP-TLS. Fornece responsabilização por dispositivo e atribuição de VLAN sem necessitar de suporte para certificados.
Dynamic VLAN
Uma técnica de segmentação de rede onde o servidor RADIUS devolve um identificador de VLAN na resposta Access-Accept, e o ponto de acesso coloca o dispositivo nessa VLAN automaticamente.
As VLANs dinâmicas permitem que as equipas de TI segmentem funcionários, prestadores de serviços, dispositivos IoT e convidados em segmentos de rede separados com base na pertença a grupos do fornecedor de identidade, sem alterações manuais na firewall.
Exemplos Práticos
Uma cadeia de retalho com 400 lojas precisa de proteger o WiFi dos funcionários em todas as localizações. Utilizam pontos de acesso Cisco Meraki e o Microsoft Entra ID com o Intune para a gestão de dispositivos. Atualmente, utilizam uma PSK WPA2-Personal partilhada porque não têm Active Directory local para executar o NPS. Uma auditoria interna recente sinalizou a PSK partilhada como uma falha de conformidade com a norma PCI DSS.
A cadeia de retalho implementa o RADIUS na nuvem da Purple. Primeiro, ligam a Purple ao Entra ID através do consentimento de administrador OAuth e configuram o aprovisionamento SCIM. No Intune, criam um Perfil de Certificado Fidedigno para a AC raiz da Purple e um perfil de certificado SCEP direcionado ao grupo de dispositivos 'Staff-Retail'. O Intune envia silenciosamente os certificados para todos os terminais de ponto de venda geridos e tablets dos funcionários. No painel da Meraki, atualizam o SSID dos funcionários para WPA2-Enterprise, introduzem os endpoints primário e secundário do RADIUS na nuvem da Purple e ativam a atribuição dinâmica de VLAN. Quando um dispositivo se liga, apresenta o seu certificado emitido pelo Intune, a Purple valida-o face à AC e verifica o grupo do Entra ID, e o dispositivo é colocado na VLAN 10 (rede de funcionários) ou na VLAN 20 (rede de gestão) com base na pertença ao grupo. A PSK partilhada é desativada. A implementação nas 400 lojas demora um fim de semana, uma vez que não é implementado hardware local - apenas alterações de configuração de SSID na Meraki.
Uma universidade com 15.000 estudantes utiliza o Google Workspace como o seu fornecedor de identidade principal. A equipa de TI pretende fornecer WiFi seguro para funcionários e estudantes num parque de dispositivos BYOD composto por MacBooks, Chromebooks e telemóveis Android. Não têm Active Directory local nem interesse em gerir servidores.
A universidade integra o RADIUS na nuvem da Purple com o Google Workspace. Para os Chromebooks geridos, utilizam a Consola de Administração do Google para enviar um perfil de certificado WiFi via SCEP, registando silenciosamente cada dispositivo. Para os MacBooks e telemóveis Android BYOD, implementam uma aplicação de integração leve que autentica o utilizador com as suas credenciais do Google e instala um certificado no dispositivo com um único toque. As ligações subsequentes utilizam EAP-TLS de forma silenciosa. A Purple mapeia as Unidades Organizacionais do Google Workspace para VLANs: os funcionários entram na VLAN 10, os estudantes na VLAN 20 e os visitantes convidados num SSID de Captive Portal. Quando um estudante se licencia e a sua conta Google é suspensa, o SCIM envia a alteração para a Purple e o seu acesso WiFi é revogado em poucos minutos.
Perguntas de Prática
Q1. A sua organização migrou totalmente do Active Directory local para o Microsoft Entra ID. O seu WiFi de funcionários atual utiliza PEAP-MSCHAPv2 contra um servidor NPS que estava associado ao domínio antigo. Após a desativação do controlador de domínio, os funcionários relatam que já não conseguem ligar-se ao WiFi. Qual é a causa raiz e qual é a correção correta a longo prazo?
Dica: Considere o que o PEAP-MSCHAPv2 exige do diretório e se o Entra ID o fornece.
Ver resposta modelo
A causa raiz é que o PEAP-MSCHAPv2 exige que o servidor RADIUS valide a palavra-passe do utilizador contra um hash NTLM armazenado no Active Directory. Com o controlador de domínio desativado, o NPS não tem nenhum diretório contra o qual validar. O Entra ID não armazena hashes NTLM, pelo que o NPS não pode ser redirecionado para o Entra ID. A correção correta a longo prazo é substituir o NPS por um serviço de cloud RADIUS, migrar de PEAP-MSCHAPv2 para EAP-TLS e utilizar o MDM (Intune) para emitir certificados de dispositivo via SCEP. Isto elimina a dependência de qualquer diretório local.
Q2. Está a implementar o cloud RADIUS para uma frota de 200 dispositivos MacBooks corporativos geridos pelo Jamf Pro. O seu fornecedor de identidade é o Okta. Qual é a forma mais segura e operacionalmente eficiente de aprovisionar as credenciais de WiFi para estes dispositivos?
Dica: Procure um método que não exija interação do utilizador, evite palavras-passe e se integre com o seu MDM existente.
Ver resposta modelo
Configure o Jamf Pro para utilizar SCEP para enviar silenciosamente certificados de dispositivo para os MacBooks. Crie um payload SCEP num perfil de configuração do Jamf, apontando para a CA gerida pelo seu fornecedor de cloud RADIUS. Defina o âmbito do perfil para o grupo de dispositivos relevante. O Jamf enviará o certificado para cada MacBook automaticamente, sem qualquer interação do utilizador. Configure o perfil de WiFi no mesmo perfil de configuração para utilizar EAP-TLS com o certificado emitido por SCEP. Ligue o serviço de cloud RADIUS ao Okta via SCIM para garantir que, quando um funcionário for desativado no Okta, o seu acesso ao WiFi seja revogado imediatamente.
Q3. Um funcionário é despedido às 9:00 de uma segunda-feira. A sua conta do Entra ID é desativada pelos RH às 9:05. Às 9:30, um alerta de segurança mostra que o portátil do funcionário ainda está ligado ao WiFi corporativo a partir do parque de estacionamento. Que configuração está em falta e como a resolve?
Dica: Como é que o servidor RADIUS sabe que o estado do utilizador foi alterado no fornecedor de identidade?
Ver resposta modelo
A implementação está a depender de sincronizações LDAP periódicas em vez de aprovisionamento SCIM. A sincronização LDAP ainda não foi executada desde que a conta foi desativada, pelo que o serviço de cloud RADIUS ainda considera o utilizador ativo. A solução é ativar o aprovisionamento SCIM entre o Entra ID e o serviço de cloud RADIUS. O SCIM envia as alterações de estado do utilizador em tempo real, pelo que, quando a conta é desativada no Entra ID às 9:05, o serviço RADIUS recebe a alteração imediatamente. Na próxima vez que o dispositivo tentar reautenticar-se (controlado pelo tempo limite da sessão no ponto de acesso), receberá um Access-Reject. Definir um tempo limite de sessão curto (15 a 30 minutos) no ponto de acesso limita a janela máxima entre a desativação da conta e a expulsão da rede.
Q4. O seu espaço tem 50 dispositivos IoT - leitores de sinalização digital, sensores ambientais e impressoras - que não suportam 802.1X EAP-TLS. Como protege estes dispositivos na mesma infraestrutura de WiFi que a sua rede de funcionários EAP-TLS?
Dica: Considere qual o método de autenticação que fornece responsabilidade por dispositivo sem exigir suporte a certificados.
Ver resposta modelo
Utilize iPSK (chaves pré-partilhadas individuais) para os dispositivos IoT. Atribua uma chave pré-partilhada única a cada dispositivo no painel do cloud RADIUS, juntamente com uma atribuição de VLAN. Cada dispositivo autentica-se com a sua chave única, que o servidor RADIUS valida e utiliza para colocar o dispositivo na VLAN de IoT, isolada da rede de funcionários. Se um dispositivo for comprometido ou desativado, revoga apenas a chave desse dispositivo sem afetar nenhum outro. Esta abordagem fornece responsabilidade por dispositivo e segmentação de rede sem exigir suporte a suplicante 802.1X no hardware IoT.
Continue a ler esta série
Três SSIDs para a todos governar: guia de configuração de WiFi para convidados, funcionários e IoT
Este guia de referência técnica autoritário fornece um plano passo a passo para implementar uma arquitetura de três SSIDs de WiFi. Explica como segmentar o tráfego de convidados, funcionários e IoT utilizando Captive Portals, 802.1X RADIUS e PSK por dispositivo (xPSK) para otimizar o desempenho e garantir a conformidade com o PCI DSS.
Como revogar o acesso WiFi quando um colaborador sai
Este guia detalha como revogar o acesso WiFi quando um colaborador sai, substituindo palavras-passe partilhadas inseguras por certificados 802.1X por utilizador ou iPSK. Abrange o desaprovisionamento automatizado via SCIM para cumprir os requisitos de auditoria ISO 27001 e SOC 2.
Google Workspace WiFi Authentication: Chromebook and LDAP Integration
Uma referência técnica definitiva para administradores de TI que implementam WiFi seguro em ambientes Google Workspace. Este guia abrange a implementação de certificados 802.1X em Chromebooks geridos através da Google Admin Console, a integração do Google Secure LDAP como backend RADIUS e decisões de arquitetura para espaços de educação, media e empresariais. Fornece passos de implementação práticos, estudos de caso do mundo real e uma comparação direta de métodos EAP para ajudar as equipas a transitar de PSKs partilhadas vulneráveis para um controlo de acesso à rede robusto e baseado em identidade.