Autenticação WiFi Enterprise sem Active Directory ou um servidor local
Este guia explica como implantar a autenticação de WiFi segura WPA2/3-Enterprise sem um Active Directory local, Windows NPS ou servidor RADIUS. Ele aborda a incompatibilidade de protocolos entre provedores de identidade em nuvem e 802.1X, os argumentos para o uso de EAP-TLS em vez de PEAP-MSCHAPv2, e como implantar o RADIUS em nuvem com certificados emitidos por MDM no Microsoft Entra ID, Okta ou Google Workspace. Escrito para líderes de TI em organizações prioritárias em nuvem e com forte presença de Mac/Chromebook que estão prontas para desativar 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 sua identidade para a nuvem. Microsoft Entra ID, Okta e Google Workspace agora gerenciam usuários, grupos e políticas de acesso para e-mail, aplicativos SaaS e gerenciamento de dispositivos. Mas o WiFi empresarial não acompanhou esse ritmo. Os pontos de acesso ainda exigem um servidor RADIUS, e esse servidor RADIUS historicamente tem sido o Windows Network Policy Server (NPS) conectado a um controlador de domínio local do Active Directory.
Essa incompatibilidade força as equipes de TI a manter uma infraestrutura local redundante apenas para manter o WiFi funcionando. A solução é o cloud RADIUS: um serviço de autenticação totalmente gerenciado que se comunica via RADIUS com seus pontos de acesso e via OAuth2, SCIM e SAML com seu provedor de identidade na nuvem. Combine-o com a entrega de certificados EAP-TLS por meio do seu MDM, e você terá uma implantação 802.1X completa, sem servidores locais, sem aplicação de patches de SO e com revogação de acesso instantânea vinculada 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 Microsoft Entra ID, Okta e Google Workspace. Você pode estar ativo em seus pontos de acesso existentes Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet em menos de uma hora.
Detalhamento técnico
A incompatibilidade de protocolos no cerne do problema
O desafio fundamental é que os provedores de identidade na nuvem e os pontos de acesso WiFi falam idiomas totalmente diferentes. O Microsoft Entra ID (anteriormente Azure AD) autentica usuários via SAML, OIDC e OAuth2 - os protocolos que os navegadores e aplicativos SaaS usam. Os pontos de acesso WiFi usam RADIUS (Remote Authentication Dial-In User Service, RFC 2865), um protocolo baseado em UDP projetado na década de 1990 para conexões discadas e VPN. A Microsoft nunca forneceu um endpoint RADIUS nativo para o Entra ID. Você não pode apontar um ponto de acesso Meraki ou Aruba diretamente para o Azure e esperar que o 802.1X funcione.
Essa é a barreira com a qual toda equipe de TI focada em nuvem se depara ao tentar proteger o WiFi de funcionários com WPA2-Enterprise ou WPA3-Enterprise. Algo precisa fazer a ponte entre o ponto de acesso e o provedor de identidade na nuvem. Esse algo é o cloud RADIUS.
Por que o PEAP-MSCHAPv2 falha sem o Active Directory
Historicamente, as implantações de 802.1X dependiam do PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2). O usuário digitava seu nome de usuário e senha, o ponto de acesso encaminhava a solicitação para o servidor RADIUS e o servidor RADIUS validava a senha em relação a um hash NTLM armazenado no Active Directory.Microsoft Entra ID não armazena hashes NTLM. Isso não é uma falha de configuração - é uma decisão arquitetônica deliberada. O Entra ID é um provedor de identidade em nuvem moderno, não um controlador de domínio. Consequentemente, um servidor RADIUS apontado para o Entra ID não pode validar um desafio PEAP-MSCHAPv2. A única maneira de fazer o PEAP funcionar com o Entra ID é implantar o Entra Domain Services, um Active Directory gerenciado pago que sincroniza a partir do Entra ID, e então executar o NPS contra ele. Isso reintroduz a maior parte do que você estava tentando eliminar: VMs do Windows Server, patching de SO, armazenamento de hash NTLM e gerenciamento 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 senhas por certificados digitais X.509. O dispositivo apresenta um certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação a uma Autoridade Certificadora (CA) confiável. Como não há senha na troca, o servidor RADIUS não precisa de um armazenamento de hash NTLM. Ele precisa apenas confiar na CA e verificar a associação de grupo do usuário no provedor de identidade para aplicar a VLAN e a política de acesso corretas.
O EAP-TLS é resistente a phishing por design. Não há credencial para roubar. Ele atende às diretrizes da CISA sobre autenticação multifator resistente a phishing e se alinha com os requisitos do PCI-DSS para autenticação forte em redes que lidam com dados de titulares de cartão. É o método de autenticação recomendado pelo IEEE 802.1X para frotas de dispositivos gerenciados.
Arquitetura de autenticação 802.1X cloud-first: os dispositivos se autenticam via EAP-TLS através do cloud RADIUS do Purple, que valida os certificados e aplica políticas baseadas em grupo a partir do Microsoft Entra ID, Okta ou Google Workspace.
Como o MDM substitui a CA local
Em uma implantação tradicional de 802.1X, os certificados eram emitidos por uma Autoridade Certificadora local executando o Active Directory Certificate Services (AD CS). Em uma implantação cloud-first, o MDM assume essa função usando o SCEP (Simple Certificate Enrollment Protocol). O Microsoft Intune, Jamf Pro e outras plataformas MDM podem solicitar certificados de uma CA hospedada na nuvem e enviá-los silenciosamente para os dispositivos gerenciados.
O fluxo funciona da seguinte forma. O administrador de TI cria um perfil de certificado SCEP no MDM, direcionado aos grupos de dispositivos que exigem acesso WiFi. O MDM envia o certificado para dispositivos Windows, macOS, iOS, iPadOS, Android Enterprise e ChromeOS automaticamente. O usuário não vê nada. O certificado é vinculado à identidade do dispositivo no MDM e se renova automaticamente antes de expirar. Quando o dispositivo se conecta ao WiFi, ele apresenta o certificado ao servidor cloud RADIUS, que o valida em relação à CA e aplica a política de rede correta.
Para organizações que usam o Microsoft Intune, o Microsoft Cloud PKI fornece uma CA totalmente gerenciada 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 gerenciadas pelo Jamf, a CA integrada do Jamf ou uma CA em nuvem de terceiros atende ao mesmo propósito.
SCIM e revogação de acesso instantânea
Um dos aspectos operacionalmente mais importantes do RADIUS em nuvem é o provisionamento SCIM (System for Cross-domain Identity Management). O SCIM é um padrão aberto que envia alterações de identidade do provedor de identidade em nuvem - a sua fonte de verdade - 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 RADIUS em nuvem imediatamente. Na próxima vez que o dispositivo tentar se autenticar, o servidor RADIUS retornará Access-Reject. Com um tempo limite de sessão curto configurado no ponto de acesso, o dispositivo é removido da rede em poucos minutos após a conta ser desativada.
Essa é uma melhoria de segurança material em relação às redes PSK compartilhadas, onde a única maneira de revogar o acesso é alterar a senha em todos os dispositivos, e em relação às implantações legadas de RADIUS que dependem de sincronizações LDAP periódicas com uma janela de horas ou dias.
RadSec: protegendo o tráfego RADIUS pela internet
O RADIUS tradicional usa UDP e fornece apenas autenticação básica de mensagens. Quando o seu servidor RADIUS está no mesmo data center que os seus pontos de acesso, isso é 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) criptografa a troca RADIUS usando TLS, fornecendo confidencialidade e integridade para o tráfego de autenticação. O Purple oferece suporte nativo ao RadSec, com fallback IPsec para pontos de acesso que ainda não oferecem suporte ao 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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.
Guia de implementação
A implantação do RADIUS em nuvem com EAP-TLS requer quatro etapas coordenadas. Um SSID piloto pode estar ativo em menos de uma hora se o Entra ID e um MDM já estiverem configurados.
Etapa 1: Conecte o RADIUS em nuvem ao seu provedor de identidade
Conecte o Purple ao seu provedor de identidade via consentimento de administrador OAuth2 (para Entra ID) ou token de API (para Okta e Google Workspace). Isso autoriza o Purple a ler usuários, grupos e associações de grupo do diretório. Configure o provisionamento SCIM para enviar alterações de status do usuário para o Purple em tempo real. Nenhuma credencial de principal de serviço é armazenada no disco. As alterações de grupo são propagadas no próximo evento de autenticação, não em um cronograma de sincronização.
Etapa 2: Configure seu MDM e perfil SCEP
No Microsoft Intune, crie um Perfil de Certificado Confiável para a raiz da CA e, em seguida, crie um perfil de certificado SCEP apontando para a CA gerenciada pelo Purple. Defina o escopo de ambos os perfis para os grupos de dispositivos que exigem acesso WiFi. Para o Jamf, configure um payload SCEP em um perfil de configuração. O MDM envia os certificados de forma silenciosa. Verifique a entrega do certificado no painel de conformidade do MDM antes de prosseguir.
Passo 3: Defina políticas de rede no painel RADIUS na nuvem
Crie políticas RADIUS que mapeiem grupos de provedores de identidade para VLANs e controles 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 por tempo que expira automaticamente. O painel da Purple aplica essas políticas no momento da autenticação, sem a necessidade de alterações no firewall.
Passo 4: Atualize a configuração do ponto de acesso
Atualize a configuração do SSID em seus pontos de acesso para usar WPA2-Enterprise ou WPA3-Enterprise com 802.1X. Insira os nomes de host ou endereços IP dos endpoints primário e secundário do RADIUS na nuvem da Purple, junto com o segredo compartilhado. Configure os pontos de acesso para usar atribuição dinâmica de VLAN com base nos atributos RADIUS retornados pela Purple. Teste com um único SSID em um subconjunto de pontos de acesso antes de implementar em toda a propriedade.
RADIUS na nuvem vs RADIUS local: uma comparação direta em relação ao tempo de implantação, dependência de Active Directory, alta disponibilidade, aplicação de patches de SO, integração de identidade e gerenciamento do ciclo de vida de certificados.
-
Melhores práticas
Estas recomendações refletem os padrões IEEE 802.1X, os requisitos do PCI DSS v4.0 e a experiência operacional na propriedade de mais de 80.000 locais da Purple.
Exija EAP-TLS para dispositivos gerenciados. As senhas são suscetíveis a phishing e preenchimento 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 design.
Use SCIM para revogação instantânea. Sincronizações periódicas de LDAP deixam uma janela onde um funcionário demitido mantém o acesso à rede. O SCIM garante que o acesso seja revogado no momento em que a conta é desativada no provedor de identidade.
Implante RADIUS multi-região. Configure seus pontos de acesso com pelo menos dois endpoints RADIUS em diferentes regiões geográficas. A Purple fornece failover multi-região ativo-ativo por padrão, com o failover sendo concluído em segundos.
Segmente o tráfego com VLANs dinâmicas. Use associações de grupo de provedores de identidade para atribuir usuários a VLANs específicas de forma dinâmica. Isso isola o tráfego sensível e limita o raio de alcance de um dispositivo comprometido sem exigir alterações manuais no firewall.
Habilite RadSec. Se seus pontos de acesso suportarem RadSec, habilite-o para criptografar o tráfego de autenticação entre o ponto de acesso e o servidor RADIUS na nuvem. Isso é particularmente importante para filiais e locais onde o ponto de acesso está em um segmento de rede não confiável.
Monitore o ciclo de vida do certificado. Configure a renovação automática do MDM para ser acionada em 80% do tempo de vida do certificado. Para um certificado de um ano, a renovação começa na marca de 10 meses. Crie alertas para dispositivos que não renovarem antes do vencimento do certificado. Para um tratamento mais amplo das normas e estruturas de segurança de WiFi corporativo, consulte o nosso Enterprise WiFi Security: A Complete Guide for 2026.
-
Soluçã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 eles afetem a produção.
Expiração de certificado. Se o certificado de um dispositivo expirar antes que o MDM o renove, o dispositivo falhará na autenticação silenciosamente. O usuário verá um erro de conexão sem explicação. Mitigue isso configurando a renovação automática do MDM em 80% do tempo de vida do certificado e monitorando o painel de conformidade do MDM para dispositivos com certificados prestes a expirar.
Falhas de sincronização do MDM. Um dispositivo que não cumpre as políticas de conformidade do MDM ou falha ao se conectar 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 pelo firewall. Os pontos de acesso devem alcançar os endpoints do RADIUS na nuvem 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 em filiais frequentemente bloqueiam essas portas. Teste a conectividade a partir da VLAN de gerenciamento do ponto de acesso antes da implantação.
Falhas de provisionamento SCIM. Se a conexão SCIM entre o provedor de identidade e o Purple for interrompida, as alterações de status do usuário não serão propagadas. Monitore o status de sincronização do SCIM tanto no provedor de identidade quanto no painel do Purple. Configure alertas para falhas de sincronização.
Dispositivos legados sem suporte a certificado. Dispositivos IoT, impressoras e hardware mais antigo podem não suportar EAP-TLS. Para esses dispositivos, use iPSK (chaves pré-compartilhadas individuais) em vez de uma PSK compartilhada. O Purple suporta iPSK nativamente, atribuindo uma chave exclusiva por dispositivo e colocando cada dispositivo na VLAN correta sem exigir suporte a suplicante 802.1X.
-
Retorno sobre o investimento (ROI) e impacto nos negócios
A migração de um RADIUS local para o RADIUS na nuvem entrega valor mensurável em infraestrutura, operações e segurança.
| Dimensão | NPS local | RADIUS na Nuvem (Purple) |
|---|---|---|
| Custo de infraestrutura | Licenças de Windows Server, computação VM, armazenamento | Assinatura por AP, sem hardware de servidor |
| Tempo de implantação | Dias a semanas | Menos de uma hora |
| Alta disponibilidade | Manual - dois servidores mais replicação | Ativo-ativo multirregião, padrão |
| Correção de OS | Mensal, por sua equipe | Gerenciado pelo fornecedor |
| Chamados de WiFi no suporte | Alto - redefinições de senha, integração manual | Queda de 80% (dados de clientes Purple) |
| Revogação de acesso | Horas a dias via sincronização LDAP | Segundos via SCIM |
As equipes de TI que utilizam o Staff WiFi da Purple normalmente veem os chamados de suporte de WiFi caírem em 80% (dados internos da Purple, 2024), impulsionados pela eliminação de redefinições de senha e integração manual de dispositivos. A autenticação baseada em certificado também atende ao requisito PCI-DSS 8.3 para autenticação forte e ao controle ISO 27001 A.9.4 para controle de acesso a sistemas e aplicativos, reduzindo a carga de auditoria sobre sua equipe de segurança.
Para organizações em varejo e hotelaria, a capacidade de gerenciar o Staff WiFi e o Guest WiFi a partir de um único painel em nuvem - com uma camada de identidade unificada - reduz a complexidade operacional em propriedades de vários locais. Para operadores de transporte e provedores de saúde, a capacidade de revogação instantânea e a trilha de auditoria completa atendem aos requisitos regulatórios sem ferramentas adicionais.
A camada de WiFi Analytics da Purple adiciona dados de ocupação e trabalho híbrido sobre a infraestrutura de autenticação, transformando o Staff WiFi de um centro de custo em uma 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 controle de acesso à rede baseado em porta. Ele exige que os dispositivos se autentiquem antes que o ponto de acesso conceda acesso à rede, utilizando uma troca EAP mediada por um servidor RADIUS.
As equipes de TI utilizam o 802.1X para garantir que apenas usuários e dispositivos autorizados se conectem à rede corporativa. Ele oferece criptografia por usuário, chaves por sessão e uma trilha de auditoria completa de cada evento de conexão.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Um protocolo de rede que fornece gerenciamento centralizado de Autenticação, Autorização e Contabilização (AAA) para acesso à rede.
Os pontos de acesso encaminham cada solicitação de conexão para o servidor RADIUS, que decide se aceita o dispositivo e qual VLAN deve atribuir a ele. O Cloud RADIUS substitui os servidores locais NPS ou FreeRADIUS.
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 senhas.
O EAP-TLS é o padrão ouro para frotas de dispositivos gerenciados. Ele é resistente a phishing, não exige armazenamento de hash de senha e é o único método 802.1X que atende às diretrizes 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 senhas em relação a hashes NTLM armazenados no Active Directory.
O PEAP-MSCHAPv2 falha em ambientes exclusivamente em nuvem porque o Microsoft Entra ID não armazena hashes NTLM. As organizações que estão migrando do AD local precisam substituir o PEAP pelo 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 a necessidade de interação do usuário.
As equipes de TI usam o SCEP com o Intune ou Jamf para provisionar silenciosamente certificados WiFi nos dispositivos dos funcionários. O SCEP substitui o servidor local NDES (Network Device Enrollment Service) em implantações voltadas primeiro para a 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 usuários entre sistemas de TI.
O SCIM garante que, quando um funcionário é desativado no Microsoft Entra ID ou Okta, essa alteração seja enviada ao serviço RADIUS em nuvem imediatamente, revogando o acesso ao WiFi em questão de segundos, em vez de horas.
NPS
Network Policy Server. A implementação de RADIUS da Microsoft, geralmente executada no Windows Server como parte de um ambiente Active Directory local.
As organizações focadas em nuvem estão desativando o NPS para eliminar VMs do Windows Server, patches de SO e a dependência do Active Directory local. O RADIUS em nuvem é o substituto direto.
RadSec
RADIUS sobre TLS (RFC 6614). Um protocolo que criptografa o tráfego de autenticação RADIUS usando TLS, substituindo o transporte de texto simples baseado em UDP utilizado pelo RADIUS tradicional.
O RadSec é essencial ao usar o RADIUS em nuvem, pois o tráfego de autenticação precisa atravessar a internet pública entre o ponto de acesso e o serviço em nuvem. O Purple suporta RadSec nativamente.
iPSK
Individual Pre-Shared Key. Uma variação do WPA2-Personal que atribui uma chave pré-compartilhada exclusiva para cada dispositivo, em vez de uma única chave compartilhada para todos os dispositivos.
O iPSK é utilizado para dispositivos IoT, impressoras e outros hardwares que não oferecem suporte a 802.1X EAP-TLS. Ele fornece responsabilização por dispositivo e atribuição de VLAN sem exigir suporte a certificados.
Dynamic VLAN
Uma técnica de segmentação de rede na qual o servidor RADIUS retorna 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 equipes de TI segmentem funcionários, terceiros, dispositivos IoT e visitantes em segmentos de rede separados com base na associação de grupo do provedor de identidade, sem alterações manuais de firewall.
Exemplos práticos
Uma rede de varejo com 400 lojas precisa proteger o WiFi para funcionários em todas as unidades. Eles utilizam pontos de acesso Cisco Meraki e usam o Microsoft Entra ID com o Intune para o gerenciamento de dispositivos. Atualmente, eles usam uma chave compartilhada WPA2-Personal PSK por não possuírem Active Directory local para rodar o NPS. Uma auditoria interna recente identificou a PSK compartilhada como uma lacuna de conformidade com o PCI-DSS.
A rede implanta o RADIUS em nuvem da Purple. Primeiro, eles conectam a Purple ao Entra ID por meio do consentimento de administrador OAuth e configuram o provisionamento SCIM. No Intune, criam um Perfil de Certificado Confiável para a CA raiz da Purple e um perfil de certificado SCEP direcionado ao grupo de dispositivos 'Staff-Retail'. O Intune distribui silenciosamente os certificados para todos os terminais de ponto de venda e tablets de funcionários gerenciados. No painel do Meraki, eles atualizam o SSID de funcionários para WPA2-Enterprise, inserem os endpoints principal e secundário do RADIUS em nuvem da Purple e ativam a atribuição dinâmica de VLAN. Quando um dispositivo se conecta, apresenta seu certificado emitido pelo Intune, a Purple o valida junto à CA, verifica o grupo no Entra ID e o dispositivo é direcionado para a VLAN 10 (rede de funcionários) ou VLAN 20 (rede de gerenciamento) com base na associação ao grupo. A PSK compartilhada é desativada. A implementação nas 400 lojas leva um fim de semana, pois nenhum hardware local é implantado - apenas alterações de configuração de SSID no Meraki.
Uma universidade com 15.000 alunos utiliza o Google Workspace como seu principal provedor de identidade. A equipe de TI deseja fornecer WiFi seguro para funcionários e alunos em uma infraestrutura BYOD composta por MacBooks, Chromebooks e celulares Android. Eles não possuem Active Directory local e não têm interesse em manter servidores.
A universidade integra o RADIUS em nuvem da Purple ao Google Workspace. Para os Chromebooks gerenciados, eles usam o Google Admin para enviar um perfil de certificado WiFi via SCEP, registrando silenciosamente cada dispositivo. Para os MacBooks e celulares Android de uso pessoal (BYOD), eles implantam um aplicativo leve de integração que autentica o usuário com suas credenciais do Google e instala um certificado no dispositivo com um único toque. Conexões subsequentes usam o EAP-TLS de forma silenciosa. A Purple mapeia as Unidades Organizacionais do Google Workspace para as VLANs: os funcionários entram na VLAN 10, os alunos na VLAN 20, e os visitantes na rede de visitantes com Captive Portal SSID. Quando um aluno se forma e sua conta do Google é suspensa, o SCIM envia a alteração para a Purple e o acesso ao WiFi é revogado em poucos minutos.
Questões práticas
Q1. Sua organização migrou totalmente do Active Directory local para o Microsoft Entra ID. Seu WiFi corporativo atual usa PEAP-MSCHAPv2 em um servidor NPS que foi associado ao antigo domínio. Após desativar o controlador de domínio, a equipe relata que não consegue mais se conectar ao WiFi. Qual é a causa raiz e qual é a correção correta de longo prazo?
Dica: Considere o que o PEAP-MSCHAPv2 exige do diretório e se o Microsoft Entra ID oferece isso.
Ver resposta modelo
A causa raiz é que o PEAP-MSCHAPv2 exige que o servidor RADIUS valide a senha do usuário em relação a um hash NTLM armazenado no Active Directory. Com o controlador de domínio desativado, o NPS não tem diretório para validação. O Entra ID não armazena hashes NTLM, portanto, o NPS não pode ser redirecionado para o Entra ID. A correção correta de longo prazo é substituir o NPS por um serviço de RADIUS em nuvem, migrar de PEAP-MSCHAPv2 para EAP-TLS e usar o MDM (Intune) para emitir certificados de dispositivo via SCEP. Isso elimina a dependência de qualquer diretório local.
Q2. Você está implantando o RADIUS em nuvem para uma frota de 200 dispositivos MacBooks corporativos gerenciados pelo Jamf Pro. Seu provedor de identidade é o Okta. Qual é a maneira mais segura e operacionalmente eficiente de provisionar as credenciais de WiFi para esses dispositivos?
Dica: Procure um método que não exija interação do usuário, evite senhas e se integre ao seu MDM existente.
Ver resposta modelo
Configure o Jamf Pro para usar o SCEP para enviar silenciosamente certificados de dispositivo para os MacBooks. Crie um payload SCEP em um perfil de configuração do Jamf, apontando para a CA gerenciada pelo seu provedor de RADIUS em nuvem. Defina o escopo do perfil para o grupo de dispositivos relevante. O Jamf enviará o certificado para cada MacBook automaticamente, sem interação do usuário. Configure o perfil de WiFi no mesmo perfil de configuração para usar EAP-TLS com o certificado emitido por SCEP. Conecte o serviço de RADIUS em nuvem ao Okta via SCIM para garantir que, quando um funcionário for desativado no Okta, seu acesso ao WiFi seja revogado imediatamente.
Q3. Um funcionário é desligado às 9h de uma segunda-feira. Sua conta do Entra ID é desativada pelo RH às 9h05. Às 9h30, um alerta de segurança mostra que o laptop do funcionário ainda está conectado ao WiFi corporativo a partir do estacionamento. Qual configuração está faltando e como corrigi-la?
Dica: Como o servidor RADIUS descobre que o status do usuário mudou no provedor de identidade?
Ver resposta modelo
A implantação está dependendo de sincronizações LDAP periódicas em vez de provisionamento SCIM. A sincronização LDAP ainda não foi executada desde que a conta foi desativada, portanto, o serviço de RADIUS em nuvem ainda considera o usuário ativo. A correção é habilitar o provisionamento SCIM entre o Entra ID e o serviço de RADIUS em nuvem. O SCIM envia as alterações de status do usuário em tempo real, de modo que, quando a conta é desativada no Entra ID às 9h05, o serviço RADIUS recebe a alteração imediatamente. Na próxima vez que o dispositivo tentar se autenticar novamente (controlado pelo tempo limite da sessão no ponto de acesso), ele 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. Seu local possui 50 dispositivos IoT - reprodutores de sinalização digital, sensores ambientais e impressoras - que não oferecem suporte a 802.1X EAP-TLS. Como você protege esses dispositivos na mesma infraestrutura de WiFi que sua rede corporativa EAP-TLS?
Dica: Considere qual método de autenticação fornece responsabilidade por dispositivo sem exigir suporte a certificados.
Ver resposta modelo
Use iPSK (chaves pré-compartilhadas individuais) para os dispositivos IoT. Atribua uma chave pré-compartilhada exclusiva para cada dispositivo no painel do RADIUS em nuvem, junto com uma atribuição de VLAN. Cada dispositivo se autentica com sua chave exclusiva, que o servidor RADIUS valida e usa para colocar o dispositivo na VLAN de IoT, isolada da rede corporativa. Se um dispositivo for comprometido ou desativado, você revoga apenas a chave desse dispositivo sem afetar nenhum outro dispositivo. Essa abordagem fornece responsabilidade por dispositivo e segmentação de rede sem exigir suporte ao suplicante 802.1X no hardware de IoT.
Continue a ler esta série
Como revogar o acesso WiFi quando um funcionário sai da empresa
Este guia mostra às equipes de TI e operações de locais físicos como remover o acesso de funcionários ao WiFi quando um colaborador se desliga, sem interromper o restante da força de trabalho. Ele compara 802.1X baseado em certificados, iPSK específico por identidade e desprovisionamento direcionado por SCIM, fornecendo em seguida um roteiro de execução para o mesmo dia, método de teste e modelo de evidência de auditoria.
Secure BYOD WiFi: Integração de certificados Passpoint vs xPSK (iPSK)
Um guia técnico abrangente para equipes de TI sobre como proteger dispositivos não gerenciados de funcionários e estudantes (BYOD) usando certificados Passpoint EAP-TLS zero-touch vs xPSK específico do fornecedor (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual é a diferença e qual você deve usar?
Este guia de referência técnica fornece uma comparação autoritativa entre os padrões de segurança sem fio WPA2 Personal e WPA2 Enterprise. Ele detalha os handshakes criptográficos subjacentes, requisitos de arquitetura e metodologias de implantação necessárias para que líderes de TI protejam redes corporativas. Os leitores aprenderão como fazer a transição de senhas compartilhadas para a autenticação individualizada baseada em certificados para se alinharem com frameworks de conformidade e mitigar 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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.