Integrando RADIUS as a Service com Diretórios em Nuvem (Azure AD e Google Workspace)
Este guia de referência técnica detalha como integrar o RADIUS as a Service com diretórios em nuvem - Microsoft Entra ID e Google Workspace - para autenticação WiFi corporativa. Ele aborda a transição arquitetônica do NPS local para o RADIUS nativo da nuvem, a implantação de autenticação EAP-TLS baseada em certificados e as melhores práticas operacionais para proteger o acesso sem fio em ambientes de hotelaria, varejo e setor público. Para gerentes de TI e arquitetos de rede que já investem em identidade em nuvem, este guia preenche a lacuna entre o gerenciamento de diretórios e a segurança de rede física.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Para empresas modernas que investem em ecossistemas de identidade em nuvem, conectar diretórios em nuvem com redes sem fio físicas é um imperativo de segurança crítico. Historicamente, a autenticação WiFi dependia do Active Directory Domain Services local (on-premise) e do Windows Network Policy Server (NPS). À medida que as organizações migram para o Microsoft Entra ID e o Google Workspace, essa pilha de autenticação local se torna um passivo — cara de manter, difícil de dimensionar e incompatível com modelos de segurança zero-trust.
O RADIUS as a Service (RADIUSaaS) muda essa equação. Um servidor RADIUS hospedado na nuvem se integra diretamente ao seu diretório em nuvem, valida solicitações de autenticação em tempo real e retorna decisões de acesso aos seus pontos de acesso — sem servidores locais, sem ciclos de aplicação de patches e sem ponto único de falha. Combinada com a autenticação baseada em certificado EAP-TLS, essa arquitetura elimina o roubo de credenciais, apoia a conformidade com o PCI DSS e o GDPR e oferece uma experiência contínua para a equipe em todas as unidades.
Este guia aborda a decisão arquitetônica entre o NPS local e o RADIUS nativo da nuvem, a implantação do EAP-TLS via Microsoft Intune e Google Admin Console e as melhores práticas operacionais para proteger o acesso sem fio em hotéis, redes de varejo, estádios e locais do setor público. Para uma introdução mais ampla ao controle de acesso à rede, consulte Um Guia para o seu Sistema de Controle de Acesso à Rede .
Análise técnica detalhada: arquitetura e padrões
O papel do RADIUS e do IEEE 802.1X
A base do WiFi corporativo seguro é o padrão IEEE 802.1X, que fornece controle de acesso à rede baseado em porta. Quando um dispositivo cliente (o solicitante) tenta se conectar a uma rede WPA2-Enterprise ou WPA3-Enterprise, o Ponto de Acesso Sem Fio (o autenticador) bloqueia todo o tráfego, exceto os pacotes EAP (Extensible Authentication Protocol). O AP encaminha esses pacotes para um servidor RADIUS. O servidor RADIUS valida a identidade em relação a um serviço de diretório e retorna uma mensagem Access-Accept ou Access-Reject. Só então o AP concede o acesso à rede.
Este modelo de três partes — solicitante, autenticador, servidor de autenticação — é a pedra angular da segurança sem fio corporativa e está definido no IEEE 802.1X. Ele não mudou fundamentalmente desde sua introdução. O que mudou é onde o servidor RADIUS reside e como ele se comunica com seu diretório.
Arquitetura RADIUS nativa da nuvem
Uma arquitetura RADIUS nativa da nuvem elimina a necessidade de servidores NPS ou FreeRADIUS locais. Um provedor terceirizado de Cloud RADIUS se integra diretamente ao Microsoft Entra ID via Microsoft Graph API, ou ao Google Workspace via Google Secure LDAP ou SAML/OAuth. A autenticação ocorre inteiramente na nuvem. Isso se alinha aos princípios de acesso à rede zero-trust e reduz significativamente a sobrecarga operacional.
A tabela abaixo compara as duas principais abordagens arquitetônicas:
| Dimensão | Híbrido local (NPS) | Nativo da nuvem (RADIUSaaS) |
|---|---|---|
| Infraestrutura | VM do Windows Server ou bare metal necessário | Sem servidores locais |
| Fonte de identidade | AD DS via LDAP/Kerberos | Entra ID ou Google Workspace via API |
| Autoridade de certificação | ADCS local + Conector do Intune | Cloud PKI do fornecedor ou da Microsoft |
| Alta disponibilidade | HA manual e balanceamento de carga | Dimensionamento automático pelo provedor |
| Tempo de configuração | Dias a semanas | Horas |
| Ideal para | AD híbrido, dispositivos legados | Organizações que priorizam a nuvem e gerenciadas por MDM |
| Complexidade operacional | Maior complexidade inicial e contínua | Menor sobrecarga operacional |
EAP-TLS vs. PEAP-MSCHAPv2: a escolha crítica
A escolha do método EAP é a decisão de segurança mais consequente nesta implantação. O PEAP-MSCHAPv2 depende de os usuários inserirem suas credenciais de domínio. Isso é vulnerável ao roubo de credenciais e a ataques man-in-the-middle. Se um dispositivo cliente não validar estritamente o certificado do servidor RADIUS — e muitos não o fazem por padrão —, um invasor poderá implantar um ponto de acesso invasor com seu SSID, interceptar o handshake EAP e capturar as credenciais. Este é um ataque Evil Twin e está bem documentado.
O EAP-TLS (Transport Layer Security) usa certificados digitais instalados no dispositivo cliente para autenticação mútua. Tanto o cliente quanto o servidor provam sua identidade criptograficamente. Não há senhas para digitar ou roubar. Em um ambiente Microsoft, os certificados são implantados silenciosamente via Microsoft Intune usando perfis SCEP (Simple Certificate Enrollment Protocol) ou PKCS. Este é o caminho recomendado para todas as novas implantações e é essencial para a conformidade com o PCI DSS v4.0 (Requisito 8.3 sobre autenticação forte) e com as obrigações de proteção de dados do GDPR.
Google Workspace: a diferença arquitetônica
O Microsoft Entra ID e o Google Workspace diferem em um aspecto importante para a integração com o RADIUS. O Microsoft NPS se integra nativamente ao Active Directory, e os provedores de Cloud RADIUS se conectam ao Entra ID via Microsoft Graph API. O Google, no entanto, não oferece um serviço RADIUS nativo. Você sempre precisa de um intermediário.
O Google Secure LDAP é o principal caminho de integração. Disponível nas edições Cloud Identity Premium e Google Workspace Enterprise, ele fornece uma interface LDAP tradicional para o seu diretório em nuvem. Seu servidor Cloud RADIUS se conecta a ldap.google.com na porta 636 usando certificados de cliente que o Google gerates para você. A partir desse ponto, o servidor RADIUS consulta o diretório do Google para validar credenciais ou associações de grupo, exatamente como faria com um Active Directory local.
Um caminho alternativo usa a integração baseada em SAML, onde o provedor de Cloud RADIUS se registra como um aplicativo SAML no Google Admin Console e realiza uma busca OAuth no momento da autenticação para verificar a identidade do usuário e as associações de grupo em tempo real.
Guia de implementação
A implementação do RADIUSaaS com EAP-TLS exige a coordenação de identidade, gerenciamento de dispositivos e infraestrutura de rede. A abordagem de cinco fases a seguir se aplica aos ambientes Microsoft Entra ID e Google Workspace.
Fase 1: preparar a infraestrutura de gerenciamento de identidades e dispositivos
Para o Microsoft Entra ID: verifique se o seu locatário possui licenciamento Microsoft 365 E3/E5 ou Enterprise Mobility + Security (EMS) E3/E5. Isso inclui o Microsoft Intune e o Acesso Condicional. Sem o Intune, a implantação automatizada de certificados não é possível.
Para o Google Workspace: confirme se você possui o Cloud Identity Premium ou o Google Workspace Enterprise para acessar o Google Secure LDAP. Se planeja usar EAP-TLS em Chromebooks gerenciados, certifique-se de que o Google Admin Console esteja configurado para gerenciar certificados de dispositivos.
Estabeleça sua Infraestrutura de Chaves Públicas (PKI). Para novas implantações, uma PKI nativa da nuvem fornecida pelo seu fornecedor de Cloud RADIUS é altamente recomendada. As alternativas incluem o Microsoft Cloud PKI (disponível com o licenciamento Intune Suite) ou uma implantação ADCS local existente conectada por meio do Microsoft Intune Certificate Connector.
Fase 2: configurar a implantação de certificados
Caminho do Microsoft Intune: no centro de administração do Intune, crie um perfil de configuração de Certificado Confiável. Carregue o certificado da CA Raiz e implante-o nos grupos de dispositivos de destino. Isso garante que os dispositivos clientes confiem no certificado apresentado pelo servidor RADIUS durante o handshake TLS. Em seguida, crie um perfil de Certificado SCEP. Para autenticação baseada em usuário, defina o Nome do Assunto como CN={{UserPrincipalName}}. Para autenticação baseada em dispositivo, use CN={{DeviceName}}. Defina o Nome Alternativo do Assunto para incluir o User Principal Name ou o ID do dispositivo.
Caminho do Google Admin Console: navegue até Dispositivos, depois Redes e, em seguida, Certificados. Carregue sua CA Raiz. Configure um mecanismo de emissão de certificados — seja uma PKI na nuvem que suporte a integração SCEP com o Google Workspace ou o Google Cloud Certificate Connector, que faz o proxy de solicitações para uma Autoridade de Certificação Microsoft local. Implante a CA Raiz e os perfis de certificado de cliente nas Unidades Organizacionais apropriadas.
Fase 3: configurar a integração do Cloud RADIUS
Conceda ao seu provedor de Cloud RADIUS as permissões de API necessárias em seu locatário de diretório. Para o Entra ID, isso requer no mínimo User.Read.All e GroupMember.Read.All via Microsoft Graph API. Alguns provedores também exigem Device.Read.All para verificações de conformidade de dispositivos. Para o Google Workspace via Secure LDAP, baixe o certificado e a chave do cliente no Google Admin Console e instale-os no serviço RADIUS.
Defina suas políticas de autenticação no portal de gerenciamento do Cloud RADIUS. Uma política bem estruturada para um ambiente corporativo: "Permitir acesso se o certificado for emitido por [Trusted CA] E o usuário for membro do grupo [Corporate-WiFi-Users] E o dispositivo estiver marcado como em Conformidade no Intune." Isso impõe identidade, associação de grupo e integridade do dispositivo simultaneamente.
Fase 4: configurar a infraestrutura sem fio
No seu controlador de LAN sem fio ou painel de gerenciamento na nuvem — Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet — adicione os endereços IP do servidor Cloud RADIUS e os segredos compartilhados como servidores de autenticação RADIUS. Configure servidores primários e secundários para redundância. Defina o tempo limite do RADIUS para um mínimo de cinco segundos para acomodar a latência de ida e volta da nuvem.
Crie um novo SSID configurado para WPA2-Enterprise ou WPA3-Enterprise. Para implantações em Hospitalidade , certifique-se de que o SSID corporativo esteja em uma VLAN separada de qualquer rede de Guest WiFi . Para ambientes de Varejo , considere implantar o SSID corporativo apenas em áreas internas (back-of-house).
Fase 5: implantar o perfil de WiFi via MDM
Microsoft Intune: crie um perfil de configuração de WiFi. Defina o SSID para corresponder exatamente à configuração da sua infraestrutura. Selecione WPA2-Enterprise ou WPA3-Enterprise. Nas configurações de EAP, selecione EAP-TLS. Vincule o perfil de certificado SCEP como o certificado do cliente e especifique o perfil de CA Raiz Confiável. Atribua este perfil de WiFi aos mesmos grupos de dispositivos que receberam os perfis de certificado. Os dispositivos recebem silenciosamente o certificado e a configuração de WiFi durante a próxima sincronização do Intune.
Google Admin Console: navegue até Dispositivos, depois Redes e, em seguida, Wi-Fi. Crie um novo perfil de rede Wi-Fi. Defina o SSID, selecione WPA3-Enterprise, escolha EAP-TLS e envie o certificado de CA Raiz confiável para os dispositivos. Aplique este perfil às suas Unidades Organizacionais. Os Chromebooks se conectam de forma silenciosa e segura.
Melhores práticas
Exija o EAP-TLS em todas as novas implantações. Não implante novas redes usando PEAP-MSCHAPv2. Os riscos de segurança são bem documentados e o caminho de migração é simples com as ferramentas modernas de MDM.
Exija uma validação rigorosa do certificado do servidor. Se você precisar usar PEAP para dispositivos legados, configure os dispositivos para validar o certificado do servidor RADIUS. No perfil de WiFi do Intune e no perfil de WiFi do Google Admin Console, há um campo para especificar a CA confiável para validação do servidor. Não deixe este campo em branco. Essa única decisão de configuração é a diferença entre uma implantação segura e uma vulnerável.
Segmente sua rede com atribuição dinâmica de VLAN. Use seu servidor RADIUS para inspecionar a associação de grupo do usuário no Entra ID ou Google Workspace e atribuí-los dinamicamente a diferentes VLANs. O servidor RADIUS retorna o Tunnelatributo -Private-Group-Id` ao ponto de acesso, o que coloca o cliente na VLAN correta. Isso limita o movimento lateral em caso de comprometimento e atende aos requisitos de segmentação de rede do PCI DSS.
Separe a autenticação corporativa e de convidados. Use EAP-TLS para dispositivos gerenciados pela empresa. Use um Captive Portal com SSO para BYOD e dispositivos de convidados. Tentar configurar manualmente o EAP-TLS em dispositivos não gerenciados cria uma sobrecarga excessiva de suporte. A plataforma Guest WiFi da Purple lida com a integração de convidados separadamente, mantendo uma separação clara entre o tráfego de funcionários e de visitantes.
Monitore a expiração de certificados de forma ativa. Configure o monitoramento e alertas para 90 dias, 30 dias e sete dias antes da expiração do certificado. Se o certificado do seu servidor RADIUS expirar, todos os dispositivos perderão a conectividade simultaneamente. Automatize a renovação onde sua PKI oferecer suporte.
Teste as configurações de timeout do RADIUS. O Cloud RADIUS introduz uma latência de ida e volta (round-trip) na rede que o NPS local (on-premise) não apresenta. Defina o timeout do RADIUS em seus pontos de acesso para pelo menos cinco segundos. Um timeout de dois segundos — comum em configurações padrão — causará falhas intermitentes de autenticação.
Solução de problemas e mitigação de riscos
Portas de firewall bloqueadas são a principal causa de falhas na implantação inicial. A autenticação RADIUS requer a porta UDP 1812 de saída da sua infraestrutura sem fio para o serviço Cloud RADIUS. A bilhetagem (accounting) RADIUS requer a porta UDP 1813. Verifique se elas estão abertas antes de qualquer outra solução de problemas.
Falhas de validação de certificado se apresentam como rejeições de autenticação sem causa óbvia. Verifique o seguinte em ordem: expiração do certificado tanto no cliente quanto no servidor RADIUS; desvio de relógio (clock skew) entre o dispositivo cliente e o servidor RADIUS (o EAP-TLS depende de uma cronometragem precisa); e se o certificado Root CA foi implantado com sucesso no dispositivo via MDM.
A não imposição de associação a grupos é um problema comum quando as políticas RADIUS fazem referência a grupos do Entra ID ou do Google Workspace. Verifique se o provedor de Cloud RADIUS possui as permissões de API corretas para ler as associações de grupo. No Entra ID, confirme se o principal de serviço tem GroupMember.Read.All. No Google Workspace, confirme se o cliente Secure LDAP tem permissão para ler informações de grupo.
A atribuição de VLAN não funcionar normalmente indica uma incompatibilidade entre os valores dos atributos RADIUS e os IDs de VLAN configurados na infraestrutura sem fio. Confirme se Tunnel-Type está definido como VLAN (valor 13), Tunnel-Medium-Type está definido como 802 (valor 6) e Tunnel-Private-Group-Id corresponde ao ID da VLAN configurado no switch ou controladora.
Dispositivos BYOD falhando no EAP-TLS geralmente indicam que o certificado do cliente não foi implantado com sucesso. Para dispositivos gerenciados pelo Intune, verifique o repositório de certificados do dispositivo no centro de administração do Intune. Para Chromebooks gerenciados pelo Google, verifique se o perfil de certificado está atribuído à Unidade Organizacional correta e se o dispositivo foi sincronizado recentemente.
ROI e impacto nos negócios
A migração para o Cloud RADIUS proporciona economias operacionais mensuráveis. O RADIUS local (on-premise) exige no mínimo dois servidores para alta disponibilidade, aplicação contínua de patches de SO, gerenciamento de certificados e tempo de engenharia especializada. O tempo de um único engenheiro gasto na manutenção do RADIUS ao longo de um ano normalmente excede o custo anual de uma assinatura do Cloud RADIUS.
O caso de negócios vai além da redução de custos. Ao vincular o acesso à rede a identidades em nuvem verificadas, você obtém:
Desligamento instantâneo. Desativar um usuário no Entra ID ou Google Workspace revoga imediatamente seu acesso à rede em todos os locais. Não há atrasos, processos manuais e nenhum risco de um ex-funcionário manter o acesso ao WiFi. Isso apoia diretamente as obrigações do GDPR em relação aos direitos de acesso a dados.
Análises mais ricas. Plataformas como o WiFi Analytics da Purple fornecem dados mais ricos sobre a utilização do espaço e as jornadas dos visitantes quando o acesso à rede está vinculado a identidades autenticadas. Você passa de endereços MAC anônimos para usuários identificados e autenticados, o que transforma a qualidade dos insights disponíveis para as equipes de operações e marketing.
Evidência de conformidade. A autenticação EAP-TLS gera logs de acesso detalhados — quem se conectou, de qual dispositivo, em qual local e a que horas. Essa trilha de auditoria apoia o Requisito 10 do PCI DSS (registro e monitoramento) e as obrigações de responsabilidade do GDPR.
Consistência multilocal. Um único serviço Cloud RADIUS autentica todos os seus locais com políticas consistentes, gerenciadas a partir de um único painel. Adicionar um novo hotel, loja ou local significa adicionar seus pontos de acesso à configuração do RADIUS — e não enviar e configurar outro servidor. Para organizações que gerenciam grandes propriedades, essa é uma vantagem operacional significativa.
Para operadoras de Transporte e estabelecimentos de Saúde onde o tempo de atividade da rede é operacionalmente crítico, os provedores de Cloud RADIUS normalmente oferecem SLAs de 99,999% de disponibilidade com failover multirregião integrado. A Purple opera com 99,999% de disponibilidade em mais de 80.000 locais ativos, com 440 milhões de logins processados em 2024 (dados internos da Purple, 2024).
Para leituras adicionais sobre tópicos relacionados, consulte Definição de Computador WAN: Um Guia Prático para 2026 and Dia Mundial do WiFi 2026: Como Seu Estabelecimento Pode Ajudar a Reduzir a Exclusão Digital .
Definições principais
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede definido na RFC 2865 que fornece gerenciamento centralizado de Autenticação, Autorização e Contabilização (AAA) para usuários que se conectam a um serviço de rede. O servidor RADIUS atua como o mecanismo de decisão entre seus pontos de acesso e seu diretório de identidade.
Toda rede WiFi corporativa WPA2-Enterprise ou WPA3-Enterprise depende de um servidor RADIUS. Sem ele, a autenticação IEEE 802.1X não funciona.
RADIUS as a Service (RADIUSaaS)
Uma implementação de RADIUS hospedada na nuvem e entregue como um serviço gerenciado. O provedor mantém a infraestrutura, atualizações, alta disponibilidade e integrações com provedores de identidade. Você configura as políticas de autenticação e aponta seus pontos de acesso para os IPs do RADIUS na nuvem.
O RADIUSaaS elimina a necessidade de servidores NPS ou FreeRADIUS locais, removendo a sobrecarga associada de hardware, aplicação de patches no sistema operacional e manutenção especializada.
IEEE 802.1X
Um padrão IEEE para Controle de Acesso à Rede baseado em porta. Ele define o modelo de autenticação de três partes: o solicitante (dispositivo cliente), o autenticador (ponto de acesso ou switch) e o servidor de autenticação (servidor RADIUS). O autenticador bloqueia todo o tráfego até que o servidor RADIUS conceda o acesso.
O padrão fundamental para autenticação WiFi corporativa. Tanto o WPA2-Enterprise quanto o WPA3-Enterprise dependem do 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Um método de autenticação definido na RFC 5216 que usa certificados digitais tanto no servidor RADIUS quanto no dispositivo cliente para autenticação mútua. Nenhuma das partes envia uma senha. O cliente apresenta seu certificado; o servidor o valida em relação ao diretório em tempo real.
O padrão ouro para segurança de WiFi corporativo. Elimina o roubo de credenciais, phishing e a sobrecarga de suporte relacionada a senhas. Necessário para a conformidade com o PCI DSS em redes de dados de portadores de cartão.
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
Um método de autenticação que cria um túnel TLS criptografado e, em seguida, envia o nome de usuário e a senha do usuário por meio dele. Vulnerável a ataques do tipo Evil Twin se o cliente não validar estritamente o certificado do servidor RADIUS.
O padrão legado para WiFi corporativo. Ainda amplamente implantado, mas deve ser migrado para o EAP-TLS em todas as implantações novas e existentes, sempre que possível.
Microsoft Entra ID
O serviço de gerenciamento de identidade e acesso baseado em nuvem da Microsoft, anteriormente conhecido como Azure Active Directory (Azure AD). Gerencia identidades de usuários, associações a grupos, conformidade de dispositivos e políticas de Acesso Condicional.
A principal fonte de identidade para o Cloud RADIUS em ambientes centrados na Microsoft. Os provedores de Cloud RADIUS se conectam ao Entra ID via Microsoft Graph API.
Google Secure LDAP
Um serviço gerenciado disponível nas edições Cloud Identity Premium e Google Workspace Enterprise que fornece uma interface LDAP tradicional para o diretório em nuvem do Google. Os servidores RADIUS se conectam ao ldap.google.com na porta 636 usando certificados de cliente.
O principal caminho de integração para conectar um servidor Cloud RADIUS ao Google Workspace. O Google não oferece um serviço RADIUS nativo, portanto, o Secure LDAP atua como a ponte.
PKI (Public Key Infrastructure)
O conjunto de funções, políticas, hardware, software, e procedimentos necessários para criar, gerenciar, distribuir, usar, armazenar e revogar certificados digitais. Uma PKI é necessária para emitir os certificados de cliente e servidor usados na autenticação EAP-TLS.
As opções de PKI nativas da nuvem de fornecedores de RADIUS ou da Microsoft (Cloud PKI) eliminam a necessidade do Active Directory Certificate Services (ADCS) local.
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo que permite que os dispositivos solicitem e recebam certificados digitais de uma Autoridade Certificadora automaticamente. Usado pelo Microsoft Intune e pelo Google Admin Console para implantar certificados de cliente em dispositivos gerenciados sem a interação do usuário.
Os perfis SCEP no Intune são o mecanismo pelo qual os dispositivos corporativos recebem silenciosamente os certificados de cliente necessários para a autenticação EAP-TLS.
Dynamic VLAN assignment
Um recurso do RADIUS que retorna atributos de atribuição de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) para o ponto de acesso com base na associação ao grupo de diretório do usuário autenticado. O AP coloca o cliente na VLAN especificada automaticamente.
Permite a segmentação granular de rede sem a configuração manual de VLAN por dispositivo. Funcionários em diferentes funções ou departamentos caem em diferentes segmentos de rede, limitando o movimento lateral e atendendo aos requisitos de segmentação do PCI DSS.
Exemplos práticos
Um hotel de 200 quartos está migrando a rede de sua equipe de back-of-house de um servidor NPS local antigo para uma solução nativa da nuvem. O hotel mudou recentemente para o Microsoft Entra ID e o Microsoft 365 E5. Os dispositivos da equipe são laptops Windows gerenciados pelo Intune. A infraestrutura sem fio é Cisco Meraki. O hotel precisa que a equipe se conecte automaticamente sem solicitações de senha e exige a revogação instantânea quando um funcionário se desliga.
Implante uma solução Cloud RADIUS com integração ao Entra ID. Passo 1: conceda ao provedor de Cloud RADIUS as permissões da Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) no locatário (tenant) do Entra ID. Passo 2: no Intune, crie um perfil de Certificado Confiável com a CA Raiz do Cloud RADIUS e implante-o no grupo 'All Corporate Devices'. Passo 3: crie um perfil de Certificado SCEP com o Nome do Assunto CN={{UserPrincipalName}} e implante-o no mesmo grupo. Passo 4: configure a política de autenticação do Cloud RADIUS: permita o acesso se o certificado for emitido pela [CA Confiável] E o usuário for membro do grupo do Entra ID [Hotel-Staff-WiFi] E o dispositivo estiver em conformidade com o Intune. Passo 5: no painel do Cisco Meraki, adicione os IPs primário e secundário do Cloud RADIUS como servidores RADIUS no SSID de back-of-house. Defina o tempo limite (timeout) do RADIUS para 5 segundos. Passo 6: no Intune, crie um perfil de WiFi WPA3-Enterprise para o SSID de back-of-house, especificando EAP-TLS e vinculando o perfil de certificado SCEP. Implante no grupo 'All Corporate Devices'. Os dispositivos recebem silenciosamente o certificado e o perfil de WiFi na próxima sincronização do Intune e se conectam automaticamente. Quando um funcionário se desliga, a desativação de sua conta do Entra ID revoga imediatamente o acesso à rede em todas as unidades.
Uma rede de varejo com 50 lojas usa o Google Workspace e gerencia uma frota de 500 Chromebooks usados pelos associados da loja para operações de inventário e ponto de venda. Atualmente, eles usam uma chave WPA2 PSK compartilhada para a rede de operações da loja, o que cria um risco de segurança quando os dispositivos são perdidos ou roubados. Eles desejam migrar para a autenticação 802.1X sem implantar servidores locais em cada loja. A infraestrutura sem fio deles é HPE Aruba.
Implante uma solução Cloud RADIUS com integração ao Google Workspace via Google Secure LDAP. Passo 1: no Google Admin Console, navegue até Apps, depois LDAP e adicione um novo cliente LDAP para o serviço Cloud RADIUS. Configure as permissões de leitura para informações do usuário e associação ao grupo. Baixe o certificado de cliente e a chave gerados. Passo 2: configure o serviço Cloud RADIUS com as credenciais do Google Secure LDAP. Passo 3: configure uma PKI em nuvem para emitir certificados para os Chromebooks. No Google Admin Console, navegue até Dispositivos, depois Redes, depois Certificados e faça o upload da CA Raiz. Configure o perfil de emissão de certificado e aplique-o à Unidade Organizacional Store-Associates. Passo 4: no Google Admin Console, crie um perfil de WiFi WPA3-Enterprise para o SSID de operações da loja. Defina o EAP-TLS, vincule a CA Raiz e aplique à OU Store-Associates. Os Chromebooks recebem o certificado e o perfil de WiFi na próxima sincronização do Admin Console. Passo 5: no HPE Aruba Central, configure o SSID de operações da loja com WPA3-Enterprise e adicione os IPs primário e secundário do Cloud RADIUS. Defina o tempo limite do RADIUS para 5 segundos. Configure a atribuição dinâmica de VLAN para colocar os associados da loja na VLAN 20 (operações da loja) com base em sua associação ao grupo do Google Workspace. Quando um Chromebook é perdido ou roubado, removê-lo da OU Store-Associates revoga imediatamente seu acesso à rede.
Questões práticas
Q1. Sua organização está migrando do Active Directory local para o Microsoft Entra ID. Atualmente, você usa PEAP-MSCHAPv2 para autenticação WiFi em 300 laptops corporativos gerenciados pelo Intune. Você possui licenciamento Microsoft 365 E5. Qual é o caminho mais seguro e operacionalmente eficiente para migrar a autenticação WiFi para uma arquitetura nativa da nuvem?
Dica: Considere as vulnerabilidades da autenticação baseada em credenciais, os recursos do Microsoft Intune para implantação de certificados e a necessidade de evitar dependências de infraestrutura local.
Ver resposta modelo
Implante uma solução Cloud RADIUS com integração ao Entra ID. Use o Microsoft Intune para implantar um perfil de Certificado Confiável (CA Raiz) e um perfil de Certificado SCEP nos 300 laptops. Configure a política de autenticação do Cloud RADIUS para exigir um certificado válido da CA confiável e a associação ao grupo do Entra ID Corporate-WiFi-Users. Crie um perfil de WiFi WPA3-Enterprise no Intune especificando EAP-TLS e vincule o perfil de certificado SCEP. Os dispositivos recebem silenciosamente o certificado e a configuração de WiFi na próxima sincronização do Intune. Isso elimina o risco de roubo de credenciais do PEAP-MSCHAPv2, remove a dependência do NPS local e fornece revogação instantânea quando uma conta do Entra ID é desativada.
Q2. Um usuário em seu hotel relata que não consegue se conectar ao WiFi da equipe de back-of-house após retornar de duas semanas de férias. Outros funcionários estão se conectando sem problemas. A rede usa EAP-TLS com certificados implantados via Intune. Quais são as três causas mais prováveis, em ordem de probabilidade?
Dica: O EAP-TLS depende de ativos criptográficos sensíveis ao tempo e consultas de diretório em tempo real.
Ver resposta modelo
- O certificado de cliente do usuário expirou. Os certificados têm um período de validade definido e, se o dispositivo estava offline durante a janela de renovação, o perfil SCEP pode não tê-lo renovado. Verifique a data de expiração do certificado no repositório de certificados do dispositivo no Intune. 2. O relógio do sistema do dispositivo está significativamente dessincronizado (desvio de relógio), fazendo com que a validação do certificado falhe. O EAP-TLS valida os carimbos de data/hora do certificado; um relógio com mais de cinco minutos de dessincronização causará falhas de autenticação. 3. A conta do Entra ID do usuário foi colocada em um grupo diferente durante sua ausência (forпример, movida de equipe ativa para uma OU diferente), e a política de autenticação RADIUS não corresponde mais à sua associação ao grupo. Verifique as associações de grupo do usuário no Entra ID em relação à política do RADIUS.
Q3. Você é o gerente de TI de uma rede de varejo com 80 lojas. Você usa o Google Workspace e gerencia 400 Chromebooks via Google Admin Console. Você deseja substituir a PSK WPA2 compartilhada atual na rede de operações da loja pela autenticação 802.1X. Você não tem servidores locais em nenhuma loja. Qual arquitetura você implanta e qual é o principal benefício de segurança em relação à abordagem PSK atual?
Dica: Considere o que acontece quando um Chromebook é perdido ou roubado em cada modelo de autenticação.
Ver resposta modelo
Implante um serviço Cloud RADIUS com integração ao Google Secure LDAP. Configure uma PKI em nuvem para emitir certificados para os Chromebooks. No Google Admin Console, implante a CA Raiz e um perfil de certificado de cliente SCEP na Unidade Organizacional Store-Associates. Crie um perfil de WiFi WPA3-Enterprise especificando EAP-TLS e implante-o na mesma OU. Configure os pontos de acesso HPE Aruba (or equivalent) em cada loja para apontar para o serviço Cloud RADIUS. O principal benefício de segurança: sob a PSK compartilhada atual, um Chromebook perdido ou roubado mantém o acesso ao WiFi até que a PSK seja rotacionada em todas as 80 lojas — um processo disruptivo e demorado. Com o EAP-TLS, remover o dispositivo da OU Store-Associates no Google Admin Console revoga imediatamente seu certificado e acesso à rede, sem impacto em nenhum outro dispositivo.
Q4. Durante uma implantação do Cloud RADIUS, você configura o SSID nos pontos de acesso Cisco Meraki e implanta o perfil de WiFi do Intune em um grupo piloto de 20 dispositivos. Nenhum dos dispositivos consegue se conectar. O status do dispositivo no Intune mostra o certificado e o perfil de WiFi como implantados com sucesso. Qual é a primeira coisa que você verifica?
Dica: A causa mais comum de falha na implantação inicial não é um erro de configuração na política do RADIUS ou no certificado.
Ver resposta modelo
Verifique se as portas UDP 1812 and 1813 estão abertas para saída dos pontos de acesso Cisco Meraki (ou da infraestrutura de nuvem Meraki) para os endereços IP do servidor Cloud RADIUS. Portas de firewall bloqueadas são a principal causa de falha na implantação inicial. O fato de os certificados e perfis de WiFi terem sido implantados com sucesso descarta problemas de configuração do Intune. As próximas verificações são: incompatibilidade de segredo compartilhado (shared secret) do RADIUS entre o Meraki e o serviço Cloud RADIUS; tempo limite (timeout) do RADIUS definido como muito baixo (aumente para pelo menos 5 segundos); e se os IPs do servidor Cloud RADIUS foram inseridos corretamente na configuração do SSID do Meraki.
Continue a ler esta série
The Security Benefits of RADIUS as a Service for Hybrid Workforces
Este guia de referência técnica explica como o RADIUS as a Service protege o acesso à rede para forças de trabalho híbridas em locais distribuídos. Ele aborda a arquitetura, os benefícios de segurança e as etapas de implantação para substituir a infraestrutura RADIUS local por um serviço de autenticação gerenciado na nuvem. Para gerentes de TI e arquitetos de rede em hotéis, redes de varejo, estádios e organizações do setor público, este guia fornece as evidências necessárias para avaliar e agir em uma migração para o RADIUS na nuvem neste trimestre.
How to Implement 802.1X Authentication with Cloud RADIUS
Este guia de referência técnica fornece uma estrutura abrangente para a implementação da autenticação 802.1X com Cloud RADIUS em ambientes empresariais distribuídos. Ele detalha a arquitetura, a seleção do método EAP, o sequenciamento da implantação e as estratégias de mitigação de riscos necessárias para proteger o acesso à rede, eliminando a sobrecarga operacional da infraestrutura local.
What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service
Este guia abrangente explora o Cloud RADIUS (RADIUS como Serviço), detalhando sua arquitetura, métodos EAP e estratégias de implementação. Ele fornece aos líderes de TI insights acionáveis sobre a migração de servidores locais para um modelo de autenticação baseado em nuvem escalável, seguro e compatível.