Autenticação WiFi Enterprise sem Active Directory ou servidor local
Este guia explica como implementar uma 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 cloud e o 802.1X, o argumento a favor do EAP-TLS sobre o PEAP-MSCHAPv2, e como implementar o cloud RADIUS com certificados emitidos por MDM contra o Microsoft Entra ID, Okta ou Google Workspace. Escrito para responsáveis de TI em organizações prioritariamente na cloud e com forte presença de Mac/Chromebook que estejam prontas para descontinuar a infraestrutura local.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança de WiFi Enterprise →
Resumo executivo
A maioria das organizações migrou a sua identidade para a cloud. O Microsoft Entra ID, Okta e 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 cloud. Combine-o com a distribuição de certificados EAP-TLS através do seu MDM e terá uma implementação 802.1X completa sem servidores locais, sem patching de SO e com revogação instantânea de acessos associada diretamente ao seu diretório na cloud.
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 da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet em menos de uma hora.
Análise técnica detalhada
A incompatibilidade de protocolos no centro do problema
O desafio fundamental é que os fornecedores de identidade na cloud 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 nos anos 90 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 cloud 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 cloud. Esse algo é o cloud RADIUS.
Por que razão o PEAP-MSCHAPv2 falha sem 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 encaminhava 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 de arquitetura deliberada. O Entra ID é um fornecedor de identidade na nuvem moderno, não um controlador de domínio. Consequentemente, um servidor RADIUS direcionado ao 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 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 Windows Server, aplicação de patches do 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 há palavra-passe na troca, o servidor RADIUS não necessita de um armazenamento de hashes NTLM. Precisa apenas 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 há credenciais para roubar. Satisfaz 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 lidam com 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 na nuvem da Purple, que valida os certificados e aplica políticas baseadas em grupos a partir do Microsoft 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 SCEP (Simple Certificate Enrollment Protocol). O Microsoft Intune, 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 aos 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 fica 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 na 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 por Jamf, a CA integrada da Jamf ou uma CA de nuvem de terceiros serve o mesmo propósito.
SCIM e revogação instantânea de acesso
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 funcionário é 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 legadas de RADIUS 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 uma autenticação básica de mensagens. 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.
-
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.
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: Ligue o cloud RADIUS ao seu fornecedor de identidade
Ligue a Purple ao seu fornecedor de identidade através do consentimento do 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 grupo 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 próximo evento de autenticação, e não num calendário de sincronização.
Passo 2: Configure o seu MDM e perfil SCEP
No Microsoft Intune, crie um Trusted Certificate Profile para a raiz da CA, depois crie um perfil de certificado SCEP a apontar 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 RADIUS na nuvem
Crie políticas RADIUS que associem grupos de fornecedores de identidade a VLANs específicas e controlos de acesso. Por exemplo, associe o grupo do Entra ID "Staff-Finance" à VLAN 20 com acesso total à internet, e associe "Staff-Contractors" à VLAN 30 com acesso limitado por 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 RADIUS na nuvem da Purple, juntamente com o segredo partilhado. Configure os pontos de acesso para utilizar 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.
RADIUS na nuvem vs RADIUS local: uma comparação direta entre tempo de implementação, dependência de 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 na infraestrutura de mais de 80.000 locais da Purple.
Exija EAP-TLS para dispositivos geridos. As palavras-passe são suscetíveis a phishing e roubo de credenciais. 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 de oportunidade onde um funcionário cessante 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 multirregião. Configure os seus pontos de acesso com pelo menos dois endpoints RADIUS em regiões geográficas diferentes. A Purple fornece redundância ativa-ativa multirregião por predefinição, com a transição a concluir-se em segundos.
Segmente o tráfego com VLANs dinâmicas. Utilize a pertença 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 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 RADIUS na nuvem. Isto é particularmente importante para filiais e locais onde o ponto de acesso se encontra num segmento de rede não fidedigno.
Monitorize o ciclo de vida dos certificados. Defina a renovação automática do MDM para ser acionada aos 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 frameworks 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 cloud RADIUS introduz novas dependências. Prepare-se para estes modos de falha comuns antes que afetem a produção.
Expiração de certificados. Se um certificado de 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 esta situação configurando a renovação automática no 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 perca a conformidade com o MDM ou que não consiga ligar-se pode não receber um certificado renovado. Implemente políticas de conformidade que identifiquem dispositivos problemáticos e alertem os administradores antes que o certificado expire.
Bloqueio de tráfego RADIUS pela firewall. Os pontos de acesso têm de alcançar os endpoints de cloud RADIUS na porta UDP 1812 (autenticação) e na porta UDP 1813 (accounting), ou na porta TCP 2083 para RadSec. As regras de firewall de saída nos escritórios 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 provisionamento SCIM. Se a ligação SCIM entre o fornecedor de identidade e a Purple for interrompida, as alterações de estado dos utilizadores não serão propagadas. Monitorize o estado da sincronização SCIM tanto no fornecedor de identidade como no painel de controlo 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 individuais pré-partilhadas) em vez de uma PSK partilhada. A Purple suporta iPSK de forma nativa, atribuindo uma chave única por dispositivo e colocando cada dispositivo na VLAN correta sem exigir suporte de suplicante 802.1X.
Retorno do investimento (ROI) e impacto comercial
A migração de um RADIUS local para o cloud RADIUS proporciona um valor mensurável em toda a infraestrutura, operações e segurança.
| Dimensão | NPS local | Cloud RADIUS (Purple) |
|---|---|---|
| Custo de infraestrutura | Licenças de Windows Server, computação 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ções do SO | Mensal, pela sua equipa | Gerido pelo fornecedor |
| Pedidos de suporte de WiFi | Elevado - reposição de palavra-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 habitualmente uma redução de 80% nos pedidos de suporte de WiFi (dados internos da Purple, 2024), impulsionada pela eliminação da reposição de palavras-passe e do registo 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 as organizações nos setores do retalho e da 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 de vários locais. Para operadores de transportes e prestadores de cuidados de saúde, a capacidade de revogação instantânea e o registo de auditoria completo cumprem os requisitos regulamentares sem 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
Um padrão IEEE (IEEE 802.1X-2020) para controlo de acesso à rede baseado em portas. Requer 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 protocolo 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 Monitorização (AAA) para acesso à rede.
Os pontos de acesso encaminham cada pedido de ligação para o servidor RADIUS, que decide se aceita o dispositivo e qual a VLAN a atribuir. 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 hash de palavra-passe e é o único método 802.1X que satisfaz 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 Microsoft Entra ID não armazena hashes NTLM. As organizações que estão a migrar de AD local devem substituir o PEAP por EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Um protocolo utilizado por plataformas MDM para solicitar e instalar certificados digitais em dispositivos de forma automática, sem interação do utilizador.
As equipas de TI utilizam o SCEP com o Intune ou Jamf para aprovisionar silenciosamente certificados WiFi em dispositivos de funcionários. 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). Um padrão aberto que automatiza a troca em tempo real de informações de identidade de utilizadores entre sistemas de TI.
O SCIM garante que, quando um funcionário é desativado no Microsoft 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 RADIUS da Microsoft, executada normalmente em Windows Server como parte de um ambiente Active Directory local.
As organizações prioritariamente na nuvem estão a descontinuar o NPS para eliminar VMs de Windows Server, atualizações do 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 em texto simples baseado em UDP utilizado pelo RADIUS tradicional.
O RadSec é essencial ao utilizar o cloud RADIUS, pois o tráfego de autenticação tem de atravessar a internet pública entre o ponto de acesso e o serviço cloud. 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 EAP-TLS 802.1X. Fornece responsabilidade por dispositivo e atribuição de VLAN sem necessitar de suporte para certificados.
Dynamic VLAN
Uma técnica de segmentação de rede na qual 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, subcontratados, dispositivos IoT e convidados em segmentos de rede separados com base na adesão a grupos do fornecedor de identidade, sem alterações manuais de firewall.
Exemplos Práticos
Uma cadeia de retalho com 400 lojas precisa de proteger o WiFi do pessoal em todos os locais. Utilizam pontos de acesso Cisco Meraki e o Microsoft Entra ID com Intune para a gestão de dispositivos. Atualmente, utilizam uma chave partilhada WPA2-Personal PSK porque não têm Active Directory local para executar o NPS. Uma auditoria interna recente identificou a PSK partilhada como uma lacuna de conformidade com o PCI-DSS.
A cadeia de lojas implementa o cloud RADIUS da Purple. Primeiro, ligam o Purple ao Entra ID através de consentimento de administrador OAuth e configuram o aprovisionamento SCIM. No Intune, criam um Perfil de Certificado Fidedigno para a raiz da AC 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 do pessoal para WPA2-Enterprise, inserem os pontos de extremidade primário e secundário do cloud RADIUS Purple e ativam a atribuição dinâmica de VLAN. Quando um dispositivo se liga, apresenta o seu certificado emitido pelo Intune, o Purple valida-o em relação à AC e verifica o grupo do Entra ID, e o dispositivo é colocado na VLAN 10 (rede do pessoal) ou na VLAN 20 (rede de gestão) com base na pertença ao grupo. A PSK partilhada é descontinuada. A implementação nas 400 lojas demora um fim de semana, uma vez que não é instalado qualquer hardware no local - apenas alterações de configuração do SSID na Meraki.
Uma universidade com 15.000 estudantes utiliza o Google Workspace como o seu principal fornecedor de identidade. A equipa de TI pretende disponibilizar WiFi seguro para funcionários e estudantes num parque 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 cloud RADIUS da Purple com o Google Workspace. Para Chromebooks geridos, utilizam o Google Admin para enviar um perfil de certificado WiFi via SCEP, registando silenciosamente cada dispositivo. Para Macbooks e telemóveis Android BYOD, implementam uma aplicação de integração leve que autentica o utilizador com as suas credenciais Google e instala um certificado no dispositivo com um único toque. As ligações subsequentes utilizam EAP-TLS de forma silenciosa. A Purple mapeia Unidades Organizacionais do Google Workspace para VLANs: os funcionários entram na VLAN 10, os estudantes na VLAN 20 e os visitantes temporários num SSID com 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 solução correta a longo prazo?
Dica: Considere o que o PEAP-MSCHAPv2 exige do diretório e se o Microsoft 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 um 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 solução correta a longo prazo é substituir o NPS por um serviço cloud RADIUS, migrar de PEAP-MSCHAPv2 para EAP-TLS e utilizar o MDM (Intune) para emitir certificados de dispositivo através de 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 nestes 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 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 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 Recursos Humanos à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 pode corrigi-la?
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 correu desde que a conta foi desativada, pelo que o serviço cloud RADIUS ainda considera o utilizador ativo. A solução é ativar o aprovisionamento SCIM entre o Entra ID e o serviço 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 de sessão no ponto de acesso), receberá um Access-Reject. Configurar 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 - ecrãs 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 com EAP-TLS?
Dica: Considere qual o método de autenticação que oferece responsabilização 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 mais nenhum. Esta abordagem oferece responsabilização por dispositivo e segmentação de rede sem exigir suporte de suplicante 802.1X no hardware IoT hardware IoT hardware IoT de IoT.
Continue a ler esta série
Como revogar o acesso WiFi quando um funcionário sai
Este guia mostra às equipas de TI e de operações de locais como remover o acesso WiFi da equipa quando um funcionário sai, sem perturbar o resto da força de trabalho. Compara 802.1X baseado em certificados, iPSK específico de identidade e desprovisionamento gerido por SCIM, fornecendo de seguida um manual para o próprio dia, um método de teste e um modelo de evidência de auditoria.
Secure BYOD WiFi: Integração de certificados Passpoint vs xPSK (iPSK)
Um guia técnico abrangente para equipas de TI sobre como proteger dispositivos não geridos de funcionários e estudantes (BYOD) utilizando certificados Passpoint EAP-TLS com configuração automática (zero-touch) vs xPSK específicos do fabricante (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual é a diferença e qual deve utilizar?
Este guia de referência técnica fornece uma comparação autoritária entre os padrões de segurança sem fios WPA2 Personal e WPA2 Enterprise. Detalha os handshakes criptográficos subjacentes, os requisitos de arquitetura e as metodologias de implementação necessárias para que os líderes de TI protejam as redes empresariais. Os leitores aprenderão a transitar de palavras-passe partilhadas para uma autenticação individualizada, baseada em certificados, para se alinharem com os quadros de conformidade e mitigarem ameaças internas.
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.