Integrar RADIUS-as-a-Service com Diretórios na Nuvem (Azure AD e Google Workspace)
Este guia de referência técnica detalha como integrar o RADIUS-as-a-Service com diretórios na nuvem - Microsoft Entra ID e Google Workspace - para autenticação WiFi empresarial. Aborda a transição de arquitetura do NPS local para o RADIUS nativo na nuvem, a implementação de autenticação EAP-TLS baseada em certificados e as melhores práticas operacionais para proteger o acesso sem fios em ambientes de hotelaria, retalho e setor público. Para gestores de TI e arquitetos de rede que já investem em identidade na nuvem, este guia preenche a lacuna entre a gestão de diretórios e a segurança de rede física.
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança WiFi Empresarial →
Resumo executivo
Para as empresas modernas que investem em ecossistemas de identidade na nuvem, a ligação de diretórios na nuvem a redes sem fios 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 Google Workspace, essa pilha de autenticação local torna-se um passivo - dispendiosa de manter, difícil de dimensionar e incompatível com modelos de segurança zero-trust.
A RADIUS-as-a-Service (RADIUSaaS) altera a equação. Um servidor RADIUS alojado na nuvem integra-se diretamente com o seu diretório na nuvem, valida pedidos de autenticação em tempo real e devolve decisões de acesso aos seus pontos de acesso - sem servidores locais, sem ciclos de atualização e sem pontos únicos de falha. Combinada com a autenticação baseada em certificados EAP-TLS, esta arquitetura elimina o roubo de credenciais, suporta a conformidade com PCI-DSS e GDPR, e proporciona uma experiência fluida para os colaboradores em todos os locais.
Este guia aborda a decisão arquitetónica entre o NPS local e o RADIUS nativo na nuvem, a implementação de EAP-TLS através do Microsoft Intune e Google Admin Console, e as melhores práticas operacionais para proteger o acesso sem fios em hotéis, propriedades de retalho, estádios e recintos do setor público. Para uma introdução mais ampla ao controlo de acesso à rede, consulte o nosso artigo A Guide to Your Network Access Control System.
Análise técnica aprofundada: arquitetura e normas
O papel do RADIUS e do IEEE 802.1X
A base do WiFi empresarial seguro é a norma IEEE 802.1X, que fornece controlo de acesso à rede baseado em portas. Quando um dispositivo cliente (o suplicante) tenta ligar-se a uma rede WPA2-Enterprise ou WPA3-Enterprise, o Ponto de Acesso Sem Fios (o autenticador) bloqueia todo o tráfego exceto os pacotes EAP (Extensible Authentication Protocol). O AP encaminha estes pacotes para um servidor RADIUS. O servidor RADIUS valida a identidade num serviço de diretório e devolve uma mensagem Access-Accept ou Access-Reject. Só então o AP concede acesso à rede.
Este modelo de três partes - suplicante, autenticador, servidor de autenticação - é a pedra angular da segurança sem fios empresarial e está definido na norma IEEE 802.1X. Não mudou fundamentalmente desde a sua introdução. O que mudou foi o local onde reside o servidor RADIUS e a forma como este comunica com o seu diretório.
Arquitetura RADIUS nativa na nuvem
Uma arquitetura RADIUS cloud-native elimina a necessidade de servidores NPS ou FreeRADIUS locais. Um fornecedor de Cloud RADIUS de terceiros integra-se diretamente com o Microsoft Entra ID através da Microsoft Graph API, ou com o Google Workspace através do Google Secure LDAP ou SAML/OAuth. A autenticação ocorre inteiramente na cloud. Isto alinha-se com os princípios de zero-trust network access e reduz significativamente os custos operacionais.
A tabela abaixo compara as duas principais abordagens arquitetónicas:
| Dimensão | Híbrida local (NPS) | Cloud-native (RADIUSaaS) |
|---|---|---|
| Infraestrutura | Necessita de Windows Server VM 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 | Cloud PKI do fornecedor ou Microsoft |
| Alta disponibilidade | HA manual e balanceamento de carga | Escalado automaticamente pelo fornecedor |
| Tempo de configuração | Dias a semanas | Horas |
| Ideal para | AD híbrido, dispositivos legados | Organizações cloud-first, geridas por MDM |
| Complexidade operacional | Maior no início e contínua | Menores custos operacionais |
EAP-TLS vs. PEAP-MSCHAPv2: a escolha crítica
A escolha do método EAP é a decisão de segurança mais consequente nesta implementação. O PEAP-MSCHAPv2 depende da introdução de credenciais de domínio por parte dos utilizadores. Isto é vulnerável a roubo de credenciais e ataques man-in-the-middle. Se um dispositivo cliente não validar rigorosamente o certificado do servidor RADIUS - e muitos não o fazem por predefinição - um atacante pode implementar um ponto de acesso falso com o seu SSID, intercetar o handshake EAP e capturar credenciais. Isto é um ataque Evil Twin e está amplamente documentado.
EAP-TLS (Transport Layer Security) utiliza certificados digitais instalados no dispositivo cliente para autenticação mútua. Tanto o cliente como o servidor provam a sua identidade de forma criptográfica. Não há palavra-passe para digitar ou roubar. Num ambiente Microsoft, os certificados são implementados silenciosamente através do Microsoft Intune utilizando SCEP (Simple Certificate Enrollment Protocol) ou perfis PKCS. Este é o caminho recomendado para todas as novas implementações e é essencial para a conformidade com a 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 numa questão importante para a integração RADIUS. O Microsoft NPS integra-se nativamente com o Active Directory, e os fornecedores de Cloud RADIUS ligam-se ao Entra ID através da Microsoft Graph API. O Google, no entanto, não oferece um serviço RADIUS nativo. Necessita sempre de um intermediário.
Google Secure LDAP é o caminho de integração principal. Disponível nas edições Cloud Identity Premium e Google Workspace Enterprise, fornece uma interface LDAP tradicional para o seu diretório na cloud. O seu servidor Cloud RADIUS liga-se a ldap.google.com na porta 636 utilizando certificados de cliente que a Google gera para si. A partir desse ponto, o servidor RADIUS consulta o diretório da Google para validar credenciais ou membros de grupos, tal como consultaria um Active Directory local.
Um caminho alternativo utiliza a integração baseada em SAML, onde o fornecedor de Cloud RADIUS se regista como uma aplicação SAML na Consola de Administração Google e realiza uma consulta OAuth no momento da autenticação para verificar a identidade e a filiação de grupos do utilizador 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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.
Guia de implementação
A implementação do RADIUS-as-a-Service com EAP-TLS requer a coordenação de identidade, gestão de dispositivos e infraestrutura de rede. A abordagem de cinco fases a seguir aplica-se tanto a ambientes Microsoft Entra ID como Google Workspace.
Fase 1: preparar a infraestrutura de gestão de identidades e dispositivos
Para o Microsoft Entra ID: verifique se o seu inquilino tem licenciamento Microsoft 365 E3/E5 ou Enterprise Mobility + Security (EMS) E3/E5. Isto inclui o Microsoft Intune e o Acesso Condicional. Sem o Intune, a implementação automatizada de certificados não é possível.
Para o Google Workspace: confirme que possui o Cloud Identity Premium ou o Google Workspace Enterprise para aceder ao Google Secure LDAP. Se planeia utilizar EAP-TLS em Chromebooks geridos, certifique-se de que a Consola de Administração Google está configurada para gerir certificados de dispositivos.
Estabeleça a sua Infraestrutura de Chaves Públicas (PKI). Para novas implementações, recomenda-se vivamente uma PKI nativa da cloud fornecida pelo seu fornecedor de Cloud RADIUS. As alternativas incluem a Microsoft Cloud PKI (disponível com o licenciamento Intune Suite) ou uma implementação ADCS local existente ligada através do Microsoft Intune Certificate Connector.
Fase 2: configurar a implementação de certificados
Caminho do Microsoft Intune: no centro de administração do Intune, crie um perfil de configuração de Certificado Fidedigno. Transfira o certificado Root CA e implemente-o nos grupos de dispositivos de destino. Isto garante que os dispositivos cliente confiam no certificado apresentado pelo servidor RADIUS durante o handshake TLS. Em seguida, crie um perfil de Certificado SCEP. Para autenticação baseada no utilizador, defina o Nome do Requisito para CN={{UserPrincipalName}}. Para autenticação baseada no dispositivo, utilize CN={{DeviceName}}. Configure o Nome Alternativo do Requisito para incluir o User Principal Name ou o ID do dispositivo.
Caminho da Consola de Administração Google: navegue para Dispositivos, depois Redes e, em seguida, Certificados. Transfira a sua Root CA. Configure um mecanismo de emissão de certificados - seja uma PKI na cloud que suporte a integração SCEP com o Google Workspace, ou o Google Cloud Certificate Connector que faz o proxy de pedidos para uma Autoridade de Certificação Microsoft local. Implemente a Root CA e os perfis de certificado de cliente nas Unidades Organizacionais apropriadas.
Fase 3: configurar a integração do Cloud RADIUS
Conceda ao seu fornecedor de Cloud RADIUS as permissões de API necessárias no seu inquilino de diretório. Para o Microsoft Entra ID, isto requer no mínimo User.Read.All e GroupMember.Read.All através da Microsoft Graph API. Alguns fornecedores também exigem Device.Read.All para verificações de conformidade do dispositivo. Para o Google Workspace via Secure LDAP, transfira o certificado de cliente e a chave da Consola do Administrador da Google e instale-os no serviço RADIUS.
Defina as suas políticas de autenticação no portal de gestão do Cloud RADIUS. Uma política bem estruturada para um ambiente corporativo: "Permitir acesso se o certificado for emitido por [Trusted CA] E o utilizador for membro do grupo [Corporate-WiFi-Users] E o dispositivo estiver marcado como Conforme no Intune." Isto impõe a identidade, a pertença a grupos e o estado do dispositivo em simultâneo.
Fase 4: configurar a infraestrutura sem fios
No seu controlador de LAN sem fios ou painel de gestão na nuvem - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks ou Fortinet - adicione os endereços IP e os segredos partilhados do servidor Cloud RADIUS 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 implementações em Hotelaria, certifique-se de que o SSID corporativo está numa VLAN separada de qualquer rede de Guest WiFi. Para ambientes de Retalho, considere a implementação do SSID corporativo apenas em áreas reservadas.
Fase 5: implementar 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 definições de EAP, selecione EAP-TLS. Associe o perfil de certificado SCEP como o certificado de cliente e especifique o perfil da Autoridade de Certificação (CA) de 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.
Consola do Administrador da Google: navegue para 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 de CA de Raiz confiável para os dispositivos. Aplique este perfil às suas Unidades Organizacionais. Os Chromebooks ligam-se de forma silenciosa e segura.
-
Melhores práticas
Exija EAP-TLS em todas as novas implementações. Não implemente novas redes utilizando PEAP-MSCHAPv2. Os riscos de segurança estão bem documentados e o caminho de migração é simples com as ferramentas de MDM modernas.
Imponha uma validação rigorosa do certificado do servidor. Se tiver de utilizar PEAP para dispositivos antigos, configure os dispositivos para validar o certificado do servidor RADIUS. No perfil de WiFi do Intune e no perfil de WiFi da Google Admin Console, existe um campo para especificar a CA fidedigna para a validação do servidor. Não deixe este campo em branco. Esta decisão de configuração única é a diferença entre uma implementação segura e uma vulnerável.
Segmente a sua rede com atribuição dinâmica de VLAN. Utilize o seu servidor RADIUS para inspecionar a pertença a grupos do utilizador no Microsoft Entra ID ou Google Workspace e atribua-os dinamicamente a diferentes VLANs. O servidor RADIUS devolve o atributo Tunnel-Private-Group-Id ao ponto de acesso, que coloca o cliente na VLAN correta. Isto limita o movimento lateral em caso de comprometimento e suporta os requisitos de segmentação de rede PCI-DSS.
Separe a autenticação corporativa e de convidados. Utilize EAP-TLS para dispositivos geridos pela empresa. Utilize um Captive Portal com SSO para dispositivos BYOD e de convidados. Tentar configurar manualmente o EAP-TLS em dispositivos não geridos cria uma sobrecarga de suporte excessiva. A plataforma Guest WiFi da Purple gere a integração de convidados separadamente, mantendo uma separação clara entre o tráfego de funcionários e de visitantes.
Monitorize a expiração de certificados proativamente. Configure a monitorização e os 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 perdem a conectividade em simultâneo. Automatize a renovação sempre que a sua PKI o suporte.
Teste as definições de timeout do RADIUS. O Cloud RADIUS introduz uma latência de rede de ida e volta que o NPS local não apresenta. Defina o timeout do RADIUS nos seus pontos de acesso para, pelo menos, cinco segundos. Um timeout de dois segundos - comum nas configurações predefinidas - causará falhas de autenticação intermitentes.
Resolução de problemas e mitigação de riscos
Portas de firewall bloqueadas são a principal causa de falhas na implementação inicial. A autenticação RADIUS requer a porta UDP 1812 de saída da sua infraestrutura sem fios para o serviço Cloud RADIUS. A contabilidade RADIUS requer a porta UDP 1813. Verifique se estas estão abertas antes de qualquer outra resolução de problemas.
Falhas na validação do certificado apresentam-se como rejeições de autenticação sem causa óbvia. Verifique o seguinte por ordem: expiração do certificado tanto no cliente como no servidor RADIUS; desvio de relógio entre o dispositivo cliente e o servidor RADIUS (o EAP-TLS depende de uma cronometragem precisa); e se o certificado Root CA foi implementado com sucesso no dispositivo via MDM.
A não imposição de pertença a grupos é um problema comum quando as políticas de RADIUS referenciam grupos do Microsoft Entra ID ou Google Workspace. Verifique se o fornecedor de Cloud RADIUS tem as permissões de API corretas para ler as pertenças a grupos. No Microsoft Entra ID, confirme que o principal de serviço tem GroupMember.Read.All. No Google Workspace, confirme que o cliente Secure LDAP tem permissão para ler as informações do grupo.
A atribuição de VLAN não está a funcionar normalmente indica uma incompatibilidade entre os valores dos atributos RADIUS e os IDs de VLAN configurados na infraestrutura sem fios. Confirme que o Tunnel-Type está definido para VLAN (valor 13), o Tunnel-Medium-Type está definido para 802 (valor 6) e o Tunnel-Private-Group-Id corresponde ao ID de VLAN configurado no switch ou controlador.
Os dispositivos BYOD que falham no EAP-TLS indicam normalmente que o certificado de cliente não foi implementado com sucesso. Para dispositivos geridos pelo Intune, verifique o armazenamento de certificados do dispositivo no centro de administração do Intune. Para Chromebooks geridos pela Google, verifique se o perfil de certificado está atribuído à Unidade Organizacional correta e se o dispositivo foi sincronizado recentemente.
-
ROI e impacto empresarial
A transição para o Cloud RADIUS proporciona poupanças operacionais mensuráveis. O RADIUS local requer, no mínimo, dois servidores para alta disponibilidade, aplicação contínua de patches de SO, gestão de certificados e tempo de engenharia especializada. O tempo de um único engenheiro despendido na manutenção do RADIUS ao longo de um ano excede normalmente o custo anual de uma subscrição Cloud RADIUS.
Os argumentos comerciais vão além da redução de custos. Ao associar o acesso à rede a identidades na nuvem verificadas, obtém:
Desativação instantânea. A desativação de um utilizador no Microsoft Entra ID ou Google Workspace revoga imediatamente o seu acesso à rede em todos os locais. Não há atrasos, não há processos manuais e não há risco de um antigo funcionário manter o acesso WiFi. Isto apoia diretamente as obrigações do GDPR em matéria de direitos de acesso a dados.
Análises mais ricas. Plataformas como a WiFi Analytics da Purple fornecem dados mais ricos sobre a utilização do espaço e os percursos dos visitantes quando o acesso à rede está associado a identidades autenticadas. Passa de endereços MAC anónimos para utilizadores identificados e autenticados, o que transforma a qualidade das informações disponíveis para as equipas de operações e marketing.
Provas de conformidade. A autenticação EAP-TLS gera registos de acesso detalhados - quem se ligou, a partir de que dispositivo, em que local e a que hora. Este registo de auditoria apoia o Requisito 10 do PCI-DSS (registo e monitorização) e as obrigações de prestação de contas do GDPR.
Consistência multilocatário. Um único serviço Cloud RADIUS autentica todos os seus locais com políticas consistentes, geridas a partir de um único painel de controlo. Adicionar um novo hotel, loja ou espaço significa adicionar os seus pontos de acesso à configuração do RADIUS - e não enviar e configurar outro servidor. Para organizações que gerem grandes portfólios, esta é uma vantagem operacional significativa.
Para operadores de Transportes e estabelecimentos de Saúde onde o tempo de atividade da rede é operacionalmente crítico, os fornecedores de Cloud RADIUS oferecem normalmente 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 espaços ativos, com 440 milhões de inícios de sessão processados em 2024 (dados internos da Purple, 2024).
Para saber 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 no RFC 2865 que fornece gestão centralizada de Autenticação, Autorização e Auditoria (AAA) para utilizadores que se ligam a um serviço de rede. O servidor RADIUS atua como o motor de decisão entre os seus pontos de acesso e o seu diretório de identidades.
Todas as redes WiFi empresariais WPA2-Enterprise ou WPA3-Enterprise dependem de um servidor RADIUS. Sem ele, a autenticação 802.1X não funciona.
RADIUS-as-a-Service (RADIUSaaS)
Uma implementação RADIUS alojada na nuvem e fornecida como um serviço gerido. O fornecedor mantém a infraestrutura, a aplicação de patches, a alta disponibilidade e as integrações com fornecedores de identidade. Só precisa de configurar as políticas de autenticação e apontar os seus pontos de acesso para os IPs do RADIUS na nuvem.
O RADIUSaaS elimina a necessidade de servidores NPS ou FreeRADIUS locais, removendo o hardware associado, a aplicação de patches no SO e os custos de manutenção especializada.
802.1X
Um padrão IEEE para controlo de acesso à rede baseado em portas. 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 a autenticação WiFi empresarial. Tanto o WPA2-Enterprise como o WPA3-Enterprise dependem do 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Um método de autenticação definido no RFC 5216 que utiliza certificados digitais tanto no servidor RADIUS como no dispositivo cliente para autenticação mútua. Nenhuma das partes envia uma palavra-passe. O cliente apresenta o seu certificado; o servidor valida-o em tempo real face ao diretório.
O padrão de excelência para a segurança WiFi empresarial. Elimina o roubo de credenciais, o phishing e os custos de suporte técnico relacionados com palavras-passe. Necessário para a conformidade com o PCI-DSS em redes com dados de titulares de cartões.
PEAP-MSCHAPv2 (Protected PEAP - Microsoft Challenge Handshake Authentication Protocol v2)
Um método de autenticação que cria um túnel TLS encriptado e, em seguida, envia o nome de utilizador e a palavra-passe do utilizador através dele. Vulnerável a ataques Evil Twin se o cliente não validar estritamente o certificado do servidor RADIUS.
O padrão legado para WiFi empresarial. Ainda é amplamente implementado, mas deve ser migrado para EAP-TLS em todas as novas e existentes implementações sempre que possível.
Microsoft Entra ID
O serviço de gestão de acessos e identidades baseado na nuvem da Microsoft, anteriormente conhecido como Azure Active Directory (Azure AD). Gere identidades de utilizadores, associações a grupos, conformidade de dispositivos e políticas de Acesso Condicional.
A principal fonte de identidade para Cloud RADIUS em ambientes centrados na Microsoft. Os fornecedores de Cloud RADIUS ligam-se ao Microsoft Entra ID através da Microsoft Graph API.
Google Secure LDAP
Um serviço gerido disponível nas edições Cloud Identity Premium e Google Workspace Enterprise que fornece uma interface LDAP tradicional para o diretório na nuvem da Google. Os servidores RADIUS ligam-se a ldap.google.com na porta 636 utilizando certificados de cliente.
O principal caminho de integração para ligar um servidor Cloud RADIUS ao Google Workspace. A Google não oferece um serviço RADIUS nativo, pelo que o Secure LDAP funciona como ponte.
PKI (Public Key Infrastructure)
O conjunto de funções, políticas, hardware, software e procedimentos necessários para criar, gerir, distribuir, utilizar, armazenar e revogar certificados digitais. É necessária uma PKI para emitir os certificados de cliente e servidor utilizados na autenticação EAP-TLS.
As 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 aos dispositivos solicitar e receber certificados digitais de uma Autoridade de Certificação de forma automática. Utilizado pelo Microsoft Intune e pelo Google Admin Console para implementar certificados de cliente em dispositivos geridos sem interação do utilizador.
Os perfis SCEP no Intune são o mecanismo através do qual os dispositivos corporativos recebem silenciosamente os certificados de cliente necessários para a autenticação EAP-TLS.
Atribuição dinâmica de VLAN
Uma funcionalidade RADIUS que devolve atributos de atribuição de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) ao ponto de acesso com base na associação do utilizador autenticado a grupos de diretório. O AP coloca o cliente na VLAN especificada de forma automática.
Permite a segmentação granular da rede sem configuração manual de VLAN por dispositivo. Os colaboradores com diferentes funções ou departamentos ficam em segmentos de rede diferentes, limitando o movimento lateral e apoiando os requisitos de segmentação PCI DSS.
Exemplos Práticos
Um hotel de 200 quartos está a migrar a rede do seu pessoal administrativo de um servidor NPS local obsoleto para uma solução nativa na nuvem. O hotel mudou recentemente para o Microsoft Entra ID e o Microsoft 365 E5. Os dispositivos dos funcionários são portáteis Windows geridos pelo Intune. A infraestrutura sem fios é Cisco Meraki. O hotel necessita que os funcionários se liguem automaticamente sem pedidos de palavra-passe e exige a revogação instantânea quando um funcionário deixa a empresa.
Implementar uma solução de Cloud RADIUS com integração com o Entra ID. Passo 1: conceder ao fornecedor de Cloud RADIUS permissões da Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) no inquilino do Entra ID. Passo 2: no Intune, criar um perfil de Certificado Fidedigno com a CA Raiz do Cloud RADIUS e implementá-lo no grupo 'Todos os Dispositivos Corporativos'. Passo 3: criar um perfil de Certificado SCEP com o Nome do Requerente CN={{UserPrincipalName}} e implementá-lo no mesmo grupo. Passo 4: configurar a política de autenticação do Cloud RADIUS: permitir o acesso se o certificado for emitido por [CA Fidedigna] E o utilizador for membro do grupo de Entra ID [Hotel-Staff-WiFi] E o dispositivo estiver em conformidade com o Intune. Passo 5: no painel da Cisco Meraki, adicionar os IPs primário e secundário do Cloud RADIUS como servidores RADIUS no SSID administrativo. Definir o tempo limite do RADIUS para 5 segundos. Passo 6: no Intune, criar um perfil de WiFi WPA3-Enterprise para o SSID administrativo, especificando EAP-TLS e associando o perfil de certificado SCEP. Implementar no grupo 'Todos os Dispositivos Corporativos'. Os dispositivos recebem silenciosamente o certificado e o perfil de WiFi na sincronização seguinte do Intune e ligam-se automaticamente. Quando um funcionário sai, a desativação da sua conta no Entra ID revoga imediatamente o acesso à rede em todos os locais.
Uma cadeia de retalho com 50 lojas utiliza o Google Workspace e gere uma frota de 500 Chromebooks utilizados pelos funcionários das lojas para inventário e operações de ponto de venda. Atualmente, utilizam uma chave partilhada WPA2 PSK para a rede operacional das lojas, o que cria um risco de segurança em caso de perda ou roubo de dispositivos. Pretendem migrar para a autenticação 802.1X sem implementar servidores locais em cada loja. A sua infraestrutura sem fios é HPE Aruba.
Implemente uma solução Cloud RADIUS com integração ao Google Workspace através do Google Secure LDAP. Passo 1: na Google Admin Console, navegue para 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 utilizador e pertença a grupos. Transfira o certificado e a chave de cliente 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. Na Google Admin Console, navegue para Dispositivos, depois Redes, depois Certificados, e envie a CA Raiz. Configure o perfil de emissão de certificados e aplique-o à Unidade Organizacional Store-Associates. Passo 4: na Google Admin Console, crie um perfil de WiFi WPA3-Enterprise para o SSID de operações da loja. Defina o EAP-TLS, associe a CA Raiz e aplique à OU Store-Associates. Os Chromebooks recebem o certificado e o perfil de WiFi na sincronização seguinte com a 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 colaboradores da loja na VLAN 20 (operações da loja) com base na sua pertença a grupos do Google Workspace. Quando um Chromebook é perdido ou roubado, a sua remoção da OU Store-Associates revoga imediatamente o seu acesso à rede.
Perguntas de Prática
Q1. A sua organização está a migrar do Active Directory local para o Microsoft Entra ID. Atualmente, utiliza PEAP-MSCHAPv2 para autenticação WiFi em 300 computadores portáteis corporativos geridos pelo Intune. Possui licenciamento Microsoft 365 E5. Qual é o caminho mais seguro e operacionalmente eficiente para migrar a autenticação WiFi para uma arquitetura nativa na nuvem?
Dica: Considere as vulnerabilidades da autenticação baseada em credenciais, as capacidades do Microsoft Intune para implementação de certificados e a necessidade de evitar dependências de infraestrutura local.
Ver resposta modelo
Implemente uma solução Cloud RADIUS com integração ao Microsoft Entra ID. Utilize o Microsoft Intune para implementar um perfil de Certificado Fidedigno (Root CA) e um perfil de Certificado SCEP nos 300 computadores portáteis. Configure a política de autenticação Cloud RADIUS para exigir um certificado válido da CA fidedigna e a associação ao grupo Corporate-WiFi-Users do Microsoft Entra ID. Crie um perfil de WiFi WPA3-Enterprise no Intune especificando EAP-TLS e associe o perfil de certificado SCEP. Os dispositivos recebem silenciosamente o certificado e a configuração de WiFi na próxima sincronização do Intune. Isto elimina o risco de roubo de credenciais PEAP-MSCHAPv2, remove a dependência do NPS local e fornece revogação instantânea quando uma conta do Microsoft Entra ID é desativada.
Q2. Um utilizador no seu hotel informa que não consegue ligar-se ao WiFi da equipa interna de apoio (back-of-house) após regressar de duas semanas de férias. Outros funcionários estão a ligar-se sem problemas. A rede utiliza EAP-TLS com certificados implementados através do Intune. Quais são as três causas mais prováveis, por ordem de probabilidade?
Dica: O EAP-TLS depende de recursos criptográficos sensíveis ao tempo e de consultas de diretório em tempo real.
Ver resposta modelo
- O certificado de cliente do utilizador expirou. Os certificados têm um período de validade definido e, se o dispositivo esteve offline durante a janela de renovação, o perfil SCEP pode não o ter renovado. Verifique a data de expiração do certificado no repositório de certificados de dispositivos do 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 as marcas temporais do certificado; um relógio com mais de cinco minutos de dessincronização causará falhas de autenticação. 3. A conta de Entra ID do utilizador foi colocada num grupo diferente durante a sua ausência (por exemplo, movida de funcionários ativos para uma OU diferente) e a política de autenticação RADIUS já não corresponde à sua pertença ao grupo. Verifique as pertenças do utilizador a grupos no Entra ID em relação à política RADIUS.
Q3. É o gestor de TI de uma cadeia de retalho com 80 lojas. Utiliza o Google Workspace e gere 400 Chromebooks através da Google Admin Console. Pretende substituir a atual WPA2 PSK partilhada na rede de operações das lojas por autenticação 802.1X. Não tem servidores locais em nenhuma localização de loja. Que arquitetura implementa 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
Implemente um serviço Cloud RADIUS com integração de LDAP seguro do Google. Configure uma PKI na cloud para emitir certificados para os Chromebooks. Na Google Admin Console, implemente a Root CA e um perfil de certificado de cliente SCEP na Unidade Organizacional (OU) de Associados de Loja. Crie um perfil de WiFi WPA3-Enterprise especificando EAP-TLS e implemente-o na mesma OU. Configure pontos de acesso HPE Aruba (ou equivalente) em cada loja para apontar para o serviço Cloud RADIUS. O principal benefício de segurança: sob a atual PSK partilhada, um Chromebook perdido ou roubado mantém o acesso ao WiFi até que a PSK seja alterada em todas as 80 lojas - um processo disruptivo e demorado. Com o EAP-TLS, a remoção do dispositivo da OU de Associados de Loja na Google Admin Console revoga imediatamente o seu certificado e o acesso à rede, sem qualquer impacto em qualquer outro dispositivo.
Q4. Durante uma implementação de Cloud RADIUS, configura o SSID nos pontos de acesso Cisco Meraki e implementa o perfil de WiFi do Intune num grupo piloto de 20 dispositivos. Nenhum dos dispositivos se consegue ligar. O estado do dispositivo no Intune mostra o certificado e o perfil de WiFi como implementados com sucesso. Qual é a primeira coisa que verifica?
Dica: A causa mais comum de falha na implementaçã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 na saída dos pontos de acesso Cisco Meraki (ou da infraestrutura cloud Meraki) para os endereços IP do servidor Cloud RADIUS. Portas de firewall bloqueadas são a principal causa de falha na implementação inicial. O facto de os certificados e perfis de WiFi estarem implementados com sucesso exclui problemas de configuração do Intune. As verificações seguintes são: incompatibilidade de segredo partilhado RADIUS entre a Meraki e o serviço Cloud RADIUS; tempo limite (timeout) de RADIUS configurado demasiado baixo (aumente para pelo menos 5 segundos); e se os IPs do servidor Cloud RADIUS estão corretamente introduzidos 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 um enquadramento abrangente para a implementação da autenticação 802.1X com Cloud RADIUS em infraestruturas empresariais distribuídas. Detalha a arquitetura, a seleção do método EAP, a sequência de implementação e as estratégias de mitigação de riscos necessárias para proteger o acesso à rede, eliminando ao mesmo tempo os custos operacionais 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 a sua arquitetura, métodos EAP e estratégias de implementação. Fornece aos líderes de TI perspetivas práticas sobre a migração de servidores locais para um modelo de autenticação baseado na nuvem escalável, seguro e em conformidade.
Migração de RADIUS On-Premises (NPS) para RADIUS as a Service
Este guia autoritário detalha a arquitetura técnica, a metodologia de implementação e o impacto comercial da migração do Microsoft Network Policy Server (NPS) on-premises para um modelo de RADIUS as a Service nativo na nuvem. 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 empresarial 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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.