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 de NPS local para RADIUS nativo em 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 da rede física.
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança de WiFi Corporativo →
Resumo executivo
Para empresas modernas que investem em ecossistemas de identidade em nuvem, a integração de 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 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 problema - cara para 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 em 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 atualizações e sem ponto único de falha. Combinada com a autenticação baseada em certificados EAP-TLS, essa arquitetura elimina o roubo de credenciais, oferece suporte à conformidade com PCI-DSS e GDPR, e proporciona uma experiência integrada para a equipe em todos os locais.
Este guia aborda a decisão arquitetônica entre o NPS local e o RADIUS nativo da nuvem, a implantação de 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 suplicante) 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 um serviço de diretório e retorna uma mensagem Access-Accept ou Access-Reject. Somente então o AP concede o acesso à rede.
Este modelo de três partes - suplicante, autenticador, servidor de autenticação - é a base da segurança sem fio corporativa e está definido no IEEE 802.1X. Ele não mudou fundamentalmente desde a sua introdução. O que mudou foi o local onde o servidor RADIUS reside e como ele se comunica com o 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 Cloud RADIUS terceirizado 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 de confiança zero (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 | Necessário VM Windows Server ou bare metal | Sem servidores locais |
| Fonte de identidade | AD DS via LDAP/Kerberos | Entra ID ou Google Workspace via API |
| Autoridade de certificação | ADCS local + Intune Connector | PKI em nuvem do fornecedor ou Microsoft |
| Alta disponibilidade | HA manual e balanceamento de carga | Dimensionamento automático pelo provedor |
| Tempo de configuração | Dias a semanas | Horas |
| Melhor para | AD híbrido, dispositivos legados | Organizações que priorizam a nuvem e gerenciadas por MDM |
| Complexidade operacional | Maior no início 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 importante nesta implantação. O PEAP-MSCHAPv2 depende de os usuários inserirem suas credenciais de domínio. Isso o torna vulnerável ao roubo de credenciais e a ataques de interceptação (man-in-the-middle). Se um dispositivo cliente não validar rigorosamente o certificado do servidor RADIUS - e muitos não o fazem por padrão - um invasor pode implantar um ponto de acesso falso com o seu SSID, interceptar o handshake EAP e capturar credenciais. Trata-se de um ataque Evil Twin, amplamente documentado.
O EAP-TLS (Transport Layer Security) utiliza certificados digitais instalados no dispositivo cliente para autenticação mútua. Tanto o cliente quanto o servidor comprovam suas identidades 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 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 ponto importante para a integração com RADIUS. O Microsoft NPS se integra nativamente ao Active Directory, e os provedores 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 precisará de um intermediário.
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 na nuvem. O seu servidor Cloud RADIUS conecta-se a ldap.google.com na porta 636 usando certificados de cliente que o Google gera 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 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.
-
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 implementação do RADIUS-as-a-Service com EAP-TLS requer 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 identidade e gerenciamento de 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 Conditional Access. 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 você planeja usar EAP-TLS em Chromebooks gerenciados, certifique-se de que o Google Admin Console está configurado para gerenciar certificados de dispositivos.
Estabeleça a sua Infraestrutura de Chaves Públicas (PKI). Para novas implantações, uma PKI nativa da nuvem fornecida pelo seu fornecedor de Cloud RADIUS é fortemente recomendada. As alternativas incluem o Microsoft Cloud PKI (disponível com licenciamento Intune Suite) ou uma implantação de ADCS local existente conectada via 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 seus 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 a sua CA Raiz. Configure um mecanismo de emissão de certificado - seja uma PKI em nuvem que ofereça suporte à integração SCEP com o Google Workspace ou o Google Cloud Certificate Connector, que serve como proxy para as 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 com Cloud RADIUS
Conceda ao seu provedor de Cloud RADIUS as permissões de API necessárias no seu locatário de diretório. Para o Microsoft Entra ID, isso requer no mínimo User.Read.All e GroupMember.Read.All por meio da Microsoft Graph API. Alguns provedores também exigem Device.Read.All para verificações de conformidade do dispositivo. Para o Google Workspace via Secure LDAP, baixe o certificado do cliente e a chave do 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 [CA confiável] 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 ao grupo e integridade do dispositivo simultaneamente.
Fase 4: configurar a infraestrutura sem fio
No seu controlador de LAN sem fio ou painel de gerenciamento em 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 no mínimo 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 Hotelaria, 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 de back-of-house.
Fase 5: implantar 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 da 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 com o Intune.
Google Admin Console: navegue até Dispositivos, depois Redes e, em seguida, WiFi. Crie um novo perfil de rede WiFi. Defina o SSID, selecione WPA3-Enterprise, escolha EAP-TLS e envie o certificado da CA raiz confiável para os dispositivos. Aplique este perfil às suas Unidades Organizacionais. Os Chromebooks se conectam de forma silenciosa e segura.
-
Boas práticas
Exija 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 é direto com as ferramentas modernas de MDM.
Exija validação estrita de certificado de 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. Esta decisão única 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 atributo Tunnel-Private-Group-Id para o ponto de acesso, que coloca o cliente na VLAN correta. Isso limita o movimento lateral no caso de uma invasão e atende aos requisitos de segmentação de rede PCI DSS.
Separe a autenticação corporativa e de visitantes. Use EAP-TLS para dispositivos gerenciados pela empresa. Use um Captive Portal com SSO para dispositivos BYOD e de visitantes. Tentar configurar manualmente o EAP-TLS em dispositivos não gerenciados cria uma sobrecarga de suporte excessiva. A plataforma de Guest WiFi da Purple lida com o onboarding de visitantes separadamente, mantendo uma separação limpa entre o tráfego de funcionários e de visitantes.
Monitore a expiração de certificados proativamente. 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 for compatível.
Teste as configurações de timeout do RADIUS. O Cloud RADIUS introduz uma latência de ida e volta na rede que o NPS local não possui. 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 de autenticação intermitentes.
-
Solução de problemas e mitigação de riscos
Portas de firewall bloqueadas são a principal causa de falha na implantação inicial. A autenticação RADIUS exige a porta UDP 1812 de saída da sua infraestrutura sem fio para o serviço Cloud RADIUS. A tarifação RADIUS exige 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; diferença de fuso horário entre o dispositivo cliente e o servidor RADIUS (o EAP-TLS depende de uma marcação de tempo precisa); e se o certificado da CA Raiz foi implantado com sucesso no dispositivo via MDM.
A não aplicação da associação de grupo é um problema comum quando as políticas RADIUS fazem referência a grupos do Entra ID ou Google Workspace. Verifique se o provedor Cloud RADIUS possui as permissões de API corretas para ler as associações de grupo. No Entra ID, confirme se a entidade de serviço possui 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 está funcionando normalmente indica uma incompatibilidade entre os valores dos atributos RADIUS e os IDs de VLAN configurados na infraestrutura sem fio. Confirme se o Tunnel-Type está definido como VLAN (valor 13), o Tunnel-Medium-Type está definido como 802 (valor 6) e o Tunnel-Private-Group-Id corresponde ao ID de VLAN configurado no switch ou controladora.
Dispositivos BYOD falhando no EAP-TLS geralmente indica 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.
-
Retorno sobre o investimento e impacto nos negócios
A migração para o Cloud RADIUS proporciona economias operacionais mensuráveis. O RADIUS local 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 dedicado à 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 Microsoft 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 WiFi. Isso apoia diretamente as obrigações da GDPR em relação aos direitos de acesso a dados.
Análises mais ricas. Plataformas como o WiFi Analytics da Purple oferecem 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 nomeados 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 prestação de contas da 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 espaço 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 Transport e estabelecimentos de Healthcare onde o tempo de atividade da rede é operacionalmente crítico, os provedores de Cloud RADIUS normalmente oferecem SLAs de 99,999% de tempo de atividade com failover multirregião integrado. A Purple opera com 99,999% de tempo de atividade em mais de 80.000 estabelecimentos ativos, com 440 milhões de logins processados em 2024 (dados internos da Purple, 2024).Para ler mais sobre tópicos relacionados, consulte WAN Computer Definition: A Practical Guide for 2026 e World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide.
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 Contabilidade (AAA) para usuários que se conectam a um serviço de rede. O servidor RADIUS funciona 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 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 direciona seus pontos de acesso para os IPs do RADIUS na nuvem.
O RADIUSaaS elimina a necessidade de servidores locais NPS ou FreeRADIUS, removendo os custos associados de hardware, atualizações de 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 suplicante (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 utiliza 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 tempo real em relação ao diretório.
O padrão de ouro para segurança de WiFi corporativo. Elimina o roubo de credenciais, phishing e custos de helpdesk relacionados a senhas. Obrigatório para conformidade com 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 Evil Twin se o cliente não validar estritamente o certificado do servidor RADIUS.
O padrão legado para redes WiFi corporativas. Ainda amplamente implantado, mas deve ser migrado para EAP-TLS em todas as implantações novas e existentes, sempre que possível.
Microsoft Entra ID
Serviço de gerenciamento de identidades e acessos baseado em nuvem da Microsoft, anteriormente conhecido como Azure Active Directory (Azure AD). Gerencia identidades de usuários, associações de grupos, conformidade de dispositivos e políticas de Acesso Condicional.
A principal fonte de identidade para Cloud RADIUS em ambientes focados em 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 RADIUS na nuvem ao Google Workspace. O Google não oferece um serviço RADIUS nativo, portanto, o Secure LDAP funciona 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.
Opções de PKI nativas da nuvem de fornecedores RADIUS ou da Microsoft (Cloud PKI) eliminam a necessidade de Active Directory Certificate Services (ADCS) locais.
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo que permite que 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 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 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 de grupo de diretório do usuário autenticado. O AP coloca o cliente na VLAN especificada automaticamente.
Permite segmentação de rede granular sem configuração manual de VLAN por dispositivo. Funcionários em diferentes funções ou departamentos entram em diferentes segmentos de rede, limitando o movimento lateral e apoiando os requisitos de segmentação do PCI-DSS.
Exemplos práticos
Um hotel de 200 quartos está migrando sua rede de funcionários administrativos de um servidor NPS local antigo para uma solução nativa em nuvem. O hotel mudou recentemente para o Microsoft Entra ID e o Microsoft 365 E5. Os dispositivos dos funcionários são laptops Windows gerenciados pelo Intune. A infraestrutura sem fio é Cisco Meraki. O hotel precisa que os funcionários se conectem automaticamente sem solicitações de senha e precisa de revogação instantânea quando um funcionário se desliga.
Implante uma solução de 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 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 'Todos os Dispositivos Corporativos'. 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 por [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 administrativo. Defina o tempo limite do RADIUS para 5 segundos. Passo 6: no Intune, crie um perfil de WiFi WPA3-Enterprise para o SSID administrativo, especificando EAP-TLS e vinculando o perfil de certificado SCEP. Implante no grupo 'Todos os Dispositivos Corporativos'. 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, desativar 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 por associados de loja para operações de inventário e ponto de venda. Atualmente, eles usam uma chave compartilhada WPA2 PSK para a rede de operações das lojas, o que cria um risco de segurança quando 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 de usuários e associação a grupos. Baixe o certificado do 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 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 timeout do RADIUS para 5 segundos. Configure a atribuição dinâmica de VLAN para colocar os funcionários da loja na VLAN 20 (operações da loja) com base em sua associação ao grupo do Google Workspace. Quando um Chromebook for perdido ou roubado, removê-lo da OU Store-Associates revoga imediatamente o 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 notebooks 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 de Cloud RADIUS com integração ao Entra ID. Use o Microsoft Intune para implantar um perfil de Certificado Confiável (Root CA) e um perfil de Certificado SCEP nos 300 notebooks. Configure a política de autenticação do Cloud RADIUS para exigir um certificado válido da CA confiável e 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 utiliza 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 de consultas de diretório em tempo real-time.
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 estivesse 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 armazenamento de certificados do dispositivo no Intune. 2. O relógio do sistema do dispositivo está significativamente fora de sincronia (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 usuário no Entra ID foi colocada em um grupo diferente durante sua ausência (por exemplo, movida da equipe ativa para uma OU diferente) e a política de autenticação RADIUS não corresponde mais à sua associação de grupo. Verifique as associações de grupo do usuário no Entra ID em relação à política RADIUS.
Q3. Você é o gerente de TI de uma rede varejista com 80 lojas. Você usa o Google Workspace e gerencia 400 Chromebooks por meio do Google Admin Console. Você deseja substituir a WPA2 PSK compartilhada atual na rede de operações das lojas por autenticação 802.1X. Você não possui servidores locais em nenhuma das lojas. 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 sob cada modelo de autenticação.
Ver resposta modelo
Implante um serviço Cloud RADIUS com integração ao Google Secure LDAP. Configure uma PKI na nuvem para emitir certificados para os Chromebooks. No Google Admin Console, implante a CA Raiz e um perfil de certificado de cliente SCEP para a 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 equivalente) 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 EAP-TLS, remover o dispositivo da OU Store-Associates no Google Admin Console revoga imediatamente seu certificado e acesso à rede, sem qualquer impacto em outros dispositivos.
Q4. Durante uma implantação de Cloud RADIUS, você configura o SSID nos pontos de acesso Cisco Meraki e implanta o perfil de WiFi do Intune para 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ê deve verificar?
Dica: A causa mais comum de falha na implantação inicial não é um erro de configuração na política RADIUS ou no certificado.
Ver resposta modelo
Verifique se as portas UDP 1812 e 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 serem implantados com sucesso elimina problemas de configuração do Intune. As próximas verificações são: divergência de segredo compartilhado RADIUS entre Meraki e o serviço Cloud RADIUS; tempo limite RADIUS configurado muito baixo (aumente para pelo menos 5 segundos); e se os IPs do servidor Cloud RADIUS estão inseridos corretamente na configuração do SSID Meraki.
Continue a ler esta série
Como implementar a autenticação 802.1X com Cloud RADIUS
Este guia de referência técnica fornece uma estrutura abrangente para implementar a autenticação 802.1X com Cloud RADIUS em propriedades empresariais distribuídas. Ele detalha a arquitetura, a seleção do método EAP, o sequenciamento de implantação e as estratégias de mitigação de riscos necessárias para garantir o acesso seguro à rede, eliminando a sobrecarga operacional da infraestrutura local.
O que é Cloud RADIUS? Um Guia Completo para RADIUS-as-a-Service
Este guia completo explora o Cloud RADIUS (RADIUS-as-a-Service), detalhando sua arquitetura, métodos EAP e estratégias de implementação. Ele fornece aos líderes de TI insights práticos sobre a migração de servidores locais para um modelo de autenticação baseado em nuvem escalável, seguro e em conformidade.
Migrando de RADIUS On-Premises (NPS) para RADIUS-as-a-Service
Este guia de autoridade detalha a arquitetura técnica, a metodologia de implementação e o impacto nos negócios da migração do Microsoft Network Policy Server (NPS) on-premises para um modelo RADIUS-as-a-Service nativo em nuvem. Ele fornece aos líderes de TI e arquitetos de rede estruturas práticas para reduzir os custos operacionais, eliminar pontos únicos de falha e proteger a autenticação corporativa em locais distribuídos.
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.