Autenticação WiFi corporativa sem Active Directory ou servidor local
Este guia explica como implantar a autenticação WiFi WPA2/3-Enterprise segura sem um Active Directory local, Windows NPS ou servidor RADIUS. Ele aborda a incompatibilidade de protocolo entre provedores de identidade em nuvem e 802.1X, os argumentos a favor do EAP-TLS em relação ao PEAP-MSCHAPv2 e como implantar o cloud RADIUS com certificados emitidos por MDM em relação ao Microsoft Entra ID, Okta ou Google Workspace. Escrito para líderes de TI em organizações cloud-first e com forte presença de Mac/Chromebook que estão prontas para aposentar a infraestrutura local.
Ouça este guia
Ver transcrição do podcast
📚 Part of our core series: Segurança e autenticação WiFi corporativa: o guia completo →
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 corporativo não acompanhou esse ritmo. Os pontos de acesso ainda esperam um servidor RADIUS, e esse servidor RADIUS historicamente tem sido o Windows Network Policy Server (NPS) conectado a um controlador de domínio Active Directory local.
Essa incompatibilidade força as equipes de TI a manter uma infraestrutura local redundante puramente 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 patches de sistema operacional e com revogação instantânea de acesso vinculada diretamente ao seu diretório na nuvem.
A Purple opera o 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.
Análise técnica detalhada
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 linguagens totalmente diferentes. O Microsoft Entra ID (antigo 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 disponibilizou 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.
Este é o obstáculo que toda equipe de TI focada em nuvem encontra ao tentar proteger o WiFi da equipe com WPA2-Enterprise ou WPA3-Enterprise. Algo precisa preencher a lacuna 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 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.
O 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, patches 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 orientações da CISA sobre autenticação multifator resistente a phishing e se alinha aos requisitos do PCI DSS para autenticação forte em redes que lidam com dados de portadores 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 RADIUS em nuvem da Purple, que valida os certificados e aplica políticas baseadas em grupo do 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 esse papel usando 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 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 é renovado automaticamente antes do vencimento. Quando o dispositivo se conecta ao WiFi, ele apresenta o certificado ao servidor RADIUS em nuvem, 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 de Mac e iOS gerenciadas pelo Jamf, a CA integrada do Jamf ou uma CA em nuvem de terceiros serve ao mesmo propósito.
SCIM e revogação de acesso instantânea
Um dos aspectos operacionalmente mais importantes do cloud RADIUS é o provisionamento SCIM (System for Cross-domain Identity Management). O SCIM é um padrão aberto que envia alterações de identidade da fonte de verdade - seu provedor de identidade em nuvem - para 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 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 poucos minutos após a conta ser desativada.
Isso representa 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 de mensagem básica. Quando seu servidor RADIUS está no mesmo data center que seus pontos de acesso, isso é aceitável. Quando seu servidor RADIUS é um serviço em 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. A Purple oferece suporte nativo ao RadSec, com fallback de IPsec para pontos de acesso que ainda não suportam RadSec.
Guia de implementação
A implantação do cloud RADIUS 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 cloud RADIUS ao seu provedor de identidade
Conecte a Purple ao seu provedor de identidade via consentimento do administrador OAuth2 (para Entra ID) ou token de API (para Okta e Google Workspace). Isso autoriza a 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 a Purple em tempo real. Nenhuma credencial de entidade de serviço é armazenada em disco. As alterações de grupo se propagam 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 pela Purple. Defina o escopo de ambos os perfis para os grupos de dispositivos que exigem acesso Wi-Fi. Para o Jamf, configure um payload SCEP em um perfil de configuração. O MDM envia os certificados silenciosamente. Verifique a entrega do certificado no painel de conformidade do MDM antes de prosseguir.
Passo 3: Defina as políticas de rede no painel do cloud RADIUS
Crie políticas de 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 por tempo limitado 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 hostnames ou endereços IP primários e secundários do endpoint do cloud RADIUS 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 implantar em toda a propriedade.
Cloud RADIUS vs RADIUS local: uma comparação direta entre tempo de implantação, dependência do 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
Essas recomendações refletem os padrões IEEE 802.1X, os requisitos do PCI DSS v4.0 e a experiência operacional em 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 (credential stuffing). Os certificados fornecem prova criptográfica de identidade e conformidade do dispositivo. O EAP-TLS é o único método 802.1X que é 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 desligado 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 multirregião. Configure seus pontos de acesso com pelo menos dois endpoints RADIUS em regiões geográficas diferentes. A Purple oferece failover multirregião ativo-ativo por padrão, com o failover sendo concluído em segundos.
Segmente o tráfego com VLANs dinâmicas. Use as associações de grupo do provedor 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 o RadSec. Se os seus pontos de acesso suportarem RadSec, habilite-o para criptografar o tráfego de autenticação entre o ponto de acesso e o servidor cloud RADIUS. 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 dos certificados. Defina 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 conseguirem renovar antes que o certificado expire. Para uma abordagem mais ampla sobre padrões e frameworks 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 em 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, a autenticação do dispositivo falhará 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 saia da conformidade do MDM ou falhe ao se conectar 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 pelo firewall. Os pontos de acesso devem alcançar os endpoints do RADIUS em nuvem na porta UDP 1812 (autenticação) e porta UDP 1813 (accounting), ou porta TCP 2083 para RadSec. 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 a 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 da Purple. Configure alertas para falhas de sincronização.
Dispositivos legados sem suporte a certificados. Dispositivos IoT, impressoras e hardwares mais antigos podem não suportar EAP-TLS. Para esses dispositivos, use iPSK (chaves pré-compartilhadas individuais) em vez de uma PSK compartilhada. A Purple suporta iPSK nativamente, atribuindo uma chave exclusiva por dispositivo e posicionando cada dispositivo na VLAN correta sem exigir suporte ao suplicante 802.1X.
ROI e impacto nos negócios
A migração do RADIUS local para o RADIUS em nuvem entrega valor mensurável em infraestrutura, operações e segurança.
| Dimensão | NPS local | Cloud RADIUS (Purple) |
|---|---|---|
| Custo de infraestrutura | Licenças de Windows Server, computação de 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 |
| Atualização de SO | Mensal, por sua equipe | Gerenciado pelo fornecedor |
| Chamados de suporte de WiFi | Alto - redefinições de senha, integração manual | Redução 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 observam uma queda de 80% nos chamados de suporte de WiFi (dados internos da Purple, 2024), impulsionada pela eliminação de redefinições de senha e do onboarding manual de dispositivos. A autenticação baseada em certificados também atende ao requisito 8.3 do PCI DSS para autenticação forte e ao controle A.9.4 da ISO 27001 para controle de acesso a sistemas e aplicações, reduzindo a carga de auditoria sobre sua equipe de segurança. |
Para organizações nos setores de varejo e hospitalidade , 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 múltiplos locais. Para operadoras 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 a necessidade de 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: Segurança de WiFi Corporativo: Um Guia Completo para 2026 - Integração de Firmware Personalizado OpenWrt com 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, usando uma troca EAP mediada por um servidor RADIUS.
As equipes de TI usam o 802.1X para garantir que apenas usuários e dispositivos autorizados se conectem à rede corporativa. Ele fornece 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 Contabilidade (AAA) para acesso à rede.
Os pontos de acesso encaminham cada solicitação de conexão para o servidor RADIUS, que decide se permite o dispositivo e qual VLAN atribuir a ele. 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 usa 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 requer 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 Entra ID não armazena hashes NTLM. As organizações que estão migrando do AD local devem substituir o PEAP pelo EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Um protocolo usado por plataformas MDM para solicitar e instalar certificados digitais em dispositivos de forma automática, sem a interação do usuário.
As equipes de TI usam o SCEP com o Intune ou Jamf para provisionar silenciosamente certificados de WiFi para os dispositivos dos funcionários. O SCEP substitui o servidor NDES (Network Device Enrollment Service) local 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 Entra ID ou Okta, essa alteração seja enviada ao serviço de nuvem RADIUS imediatamente, revogando o acesso ao WiFi em segundos, em vez de horas.
NPS
Network Policy Server. A implementação de RADIUS da Microsoft, normalmente executada no Windows Server como parte de um ambiente Active Directory local.
Organizações voltadas primeiro para a nuvem estão desativando o NPS para eliminar VMs do Windows Server, patches 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 criptografa o tráfego de autenticação RADIUS usando TLS, substituindo o transporte em texto simples baseado em UDP usado pelo RADIUS tradicional.
O RadSec é essencial ao usar o cloud RADIUS, pois 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 oferece suporte nativo ao RadSec.
iPSK
Individual Pre-Shared Key. Uma variante 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 é usado para dispositivos IoT, impressoras e outros hardwares que não suportam 802.1X EAP-TLS. Ele fornece responsabilidade por dispositivo e atribuição de VLAN sem exigir suporte a certificados.
Dynamic VLAN
Uma técnica de segmentação de rede onde 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, prestadores de serviços, dispositivos IoT e convidados 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 da equipe em todas as unidades. Eles utilizam pontos de acesso Cisco Meraki e usam o Microsoft Entra ID com o Intune para gerenciamento de dispositivos. Atualmente, eles usam uma PSK WPA2-Personal compartilhada porque não possuem Active Directory local para executar o NPS. Uma auditoria interna recente apontou 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 do administrador OAuth e configuram o provisionamento SCIM. No Intune, eles 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 envia silenciosamente os certificados para todos os terminais de ponto de venda gerenciados e tablets da equipe. No painel do Meraki, eles atualizam o SSID da equipe para WPA2-Enterprise, inserem os endpoints primário e secundário do RADIUS em nuvem da Purple e ativam a atribuição dinâmica de VLAN. Quando um dispositivo se conecta, ele apresenta seu certificado emitido pelo Intune, a Purple o valida em relação à CA e verifica o grupo do Entra ID, e o dispositivo é colocado na VLAN 10 (rede da equipe) ou na VLAN 20 (rede de gerenciamento) com base na associação ao grupo. A PSK compartilhada é desativada. A implantação em 400 lojas leva um único fim de semana, pois nenhum hardware local é implantado - apenas alterações de configuração de SSID no Meraki.
Uma universidade de 15.000 alunos usa o Google Workspace como seu provedor de identidade principal. A equipe de TI deseja fornecer WiFi seguro para funcionários e alunos em um parque de dispositivos BYOD composto por MacBooks, Chromebooks e telefones Android. Eles não têm Active Directory local e nenhum interesse em gerenciar servidores.
A universidade integra o RADIUS em nuvem da Purple com o Google Workspace. Para Chromebooks gerenciados, eles usam o Google Admin para enviar um perfil de certificado WiFi via SCEP, registrando silenciosamente cada dispositivo. Para MacBooks e telefones Android BYOD, eles implantam um aplicativo de integração leve que autentica o usuário com suas credenciais do Google e instala um certificado no dispositivo com um único toque. As conexões subsequentes usam EAP-TLS de forma silenciosa. A Purple mapeia as Unidades Organizacionais do Google Workspace para VLANs: funcionários entram na VLAN 10, alunos na VLAN 20 e visitantes convidados em um SSID de Captive Portal. Quando um aluno se forma e sua conta do Google é suspensa, o SCIM envia a alteração para a Purple e seu acesso ao WiFi é revogado em minutos.
Questões práticas
Q1. Sua organização migrou totalmente do Active Directory local para o Microsoft Entra ID. Seu WiFi de funcionários atual usa PEAP-MSCHAPv2 contra um servidor NPS que estava associado ao antigo domínio. Após a desativação do controlador de domínio, os funcionários relatam que não conseguem 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 Entra ID fornece 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 validar. 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 do PEAP-MSCHAPv2 para o 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 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 você resolve isso?
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 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 timeout de sessão no ponto de acesso), ele receberá um Access-Reject. Definir um timeout 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 - players de sinalização digital, sensores ambientais e impressoras - que não suportam 802.1X EAP-TLS. Como você protege esses dispositivos na mesma infraestrutura de WiFi que a rede de funcionários 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 de funcionários. Se um dispositivo for comprometido ou desativado, você revoga apenas a chave desse dispositivo, sem afetar nenhum outro. Essa 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, equipe e IoT
Este guia de referência técnica autoritativo fornece um modelo passo a passo para a implementação de uma arquitetura de três SSIDs de WiFi. Ele explica como segmentar o tráfego de convidados, equipe e IoT usando captive portals, RADIUS 802.1X e PSK por dispositivo (xPSK) para otimizar o desempenho e garantir a conformidade com o PCI DSS.
Como revogar o acesso WiFi quando um funcionário sai
Este guia detalha como revogar o acesso WiFi quando um funcionário sai, substituindo senhas compartilhadas inseguras por certificados 802.1X por usuário ou iPSK. Ele aborda o desprovisionamento automatizado via SCIM para atender aos 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 implantam WiFi seguro em ambientes Google Workspace. Este guia aborda a implantação de certificados 802.1X em Chromebooks gerenciados por meio do Google Admin Console, a integração do Google Secure LDAP como um backend RADIUS e decisões de arquitetura para ambientes de educação, mídia e corporativos. Ele fornece etapas práticas de implementação, estudos de caso reais e uma comparação direta de métodos EAP para ajudar as equipes a migrar de PSKs compartilhadas vulneráveis para um controle de acesso à rede robusto e baseado em identidade.