Integrar o RADIUS as a Service com Diretórios Cloud (Azure AD & Google Workspace)
Este guia de referência técnica detalha como integrar o RADIUS as a Service com diretórios cloud - Microsoft Entra ID e Google Workspace - para a autenticação de WiFi empresarial. Abrange a transição arquitetónica de NPS on-premise para 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 da rede física.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
Para as empresas modernas que investem em ecossistemas de identidade na nuvem, a ligação entre diretórios na nuvem e 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 fardo - dispendiosa de manter, difícil de dimensionar e incompatível com modelos de segurança zero-trust.
O RADIUS como Serviço (RADIUSaaS) altera esta 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, apoia a conformidade com a PCI DSS e o GDPR, e proporciona uma experiência fluida para os colaboradores em todos os locais.
Este guia aborda a decisão de arquitetura entre o NPS local e o RADIUS nativo da nuvem, a implementação de EAP-TLS através do Microsoft Intune e da Consola de Administração do Google, e as melhores práticas operacionais para proteger o acesso sem fios em hotéis, superfícies comerciais, estádios e espaços do setor público. Para uma introdução mais ampla ao controlo de acessos à rede, consulte A Guide to Your Network Access Control System .
Análise Técnica Profunda: Arquitetura e Padrões
O papel do RADIUS e do IEEE 802.1X
A base de um WiFi empresarial seguro é o padrão 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 reencaminha estes pacotes para um servidor RADIUS. O servidor RADIUS valida a identidade face a um serviço de diretório e devolve uma mensagem de Access-Accept ou Access-Reject. Só então o AP concede o 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 no IEEE 802.1X. Não mudou fundamentalmente desde a sua introdução. O que mudou foi o local onde o servidor RADIUS reside e a forma como este comunica com o seu diretório.
Arquitetura RADIUS nativa da 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 nuvem. 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 arquiteturais:
| Dimensão | Híbrida local (NPS) | Cloud-native (RADIUSaaS) |
|---|---|---|
| Infraestrutura | Windows Server VM 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 + Intune Connector | Cloud PKI do fornecedor ou Microsoft |
| Alta disponibilidade | HA manual e balanceamento de carga | Autoescalável 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 esforço inicial e contínuo | Menor custo operacional |
EAP-TLS vs. PEAP-MSCHAPv2: a decisão crítica
A escolha do método EAP é a decisão de segurança mais consequente nesta implementação. O PEAP-MSCHAPv2 baseia-se na introdução das credenciais de domínio pelos utilizadores. Isto é vulnerável a 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 predefinição —, um atacante pode implementar um ponto de acesso falso com o seu SSID, intercetar 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 como o servidor provam a sua identidade criptograficamente. Não existem palavras-passe para digitar ou roubar. Num ambiente Microsoft, os certificados são implementados silenciosamente através do Microsoft Intune utilizando perfis SCEP (Simple Certificate Enrollment Protocol) ou PKCS. Este é o caminho recomendado para todas as novas implementações e é essencial para a conformidade com a norma 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 arquitetural
O Microsoft Entra ID e o Google Workspace diferem num aspeto 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. Necessitará sempre 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, fornece uma interface LDAP tradicional para o seu diretório na nuvem. O seu servidor Cloud RADIUS liga-se ao ldap.google.com na porta 636 utilizando certificados de cliente que o Google gera para si. A partir desse ponto, o servidor RADIUS consulta o diretório do 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 Google Admin Console e realiza uma pesquisa OAuth no momento da autenticação para verificar a identidade do utilizador e a filiação em grupos em tempo real.
Guia de implementação
A implementação do RADIUSaaS com EAP-TLS requer a coordenação da identidade, da gestão de dispositivos e da infraestrutura de rede. A seguinte abordagem em cinco fases aplica-se tanto a ambientes Microsoft Entra ID como a Google Workspace.
Fase 1: preparar a infraestrutura de gestão de identidade 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 Google Admin Console 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 nuvem fornecida pelo seu fornecedor de Cloud RADIUS. As alternativas incluem o Microsoft Cloud PKI (disponível com 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. Carregue o certificado da Root CA e implemente-o nos seus grupos de dispositivos de destino. Isto garante que os dispositivos de 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 Sujeito para CN={{UserPrincipalName}}. Para autenticação baseada no dispositivo, utilize CN={{DeviceName}}. Defina o Nome Alternativo do Sujeito para incluir o User Principal Name ou o ID do dispositivo.
Caminho da Google Admin Console: navegue para Dispositivos, depois Redes, e depois Certificados. Carregue a sua Root CA. 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 dos 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 Entra ID, isto requer no mínimo User.Read.All e GroupMember.Read.All via Microsoft Graph API. Alguns fornecedores também requerem Device.Read.All para verificações de conformidade de dispositivos. Para o Google Workspace via Secure LDAP, transfira o certificado e a chave do cliente a partir da Consola do Administrador do 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 empresarial: "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 simultaneamente a identidade, a pertença a grupos e a integridade do dispositivo.
Fase 4: configurar a infraestrutura sem fios
No seu controlador LAN sem fios ou painel de gestão na cloud - 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 partilhados como servidores de autenticação RADIUS. Configure servidores primários e secundários para redundância. Defina o tempo limite (timeout) do RADIUS para um mínimo de cinco segundos para acomodar a latência de ida e volta da cloud.
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 do cliente e especifique o perfil da CA de Raiz Fidedigna. 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.
Consola do Administrador do Google: navegue para Dispositivos, depois Redes e, em seguida, Wi-Fi. Crie um novo perfil de rede WiFi. Defina o SSID, selecione WPA3-Enterprise, escolha EAP-TLS e envie o certificado da CA de Raiz fidedigna 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 modernas de MDM.
Imponha uma validação rigorosa do certificado do servidor. Se tiver de utilizar 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, existe um campo para especificar a CA fidedigna para a validação do servidor. Não deixe este campo em branco. Esta única decisão de configuração é 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 filiação em grupos do utilizador no Entra ID ou no 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 no caso de uma quebra de segurança e suporta os requisitos de segmentação de rede PCI DSS.
Separe a autenticação corporativa da 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 de Guest WiFi da Purple lida com a integração de convidados separadamente, mantendo uma separação limpa entre o tráfego de funcionários e o 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 ida e volta na rede que o NPS local não introduz. Defina o timeout do RADIUS nos 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.
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 monitorização de acessos (accounting) RADIUS requer a porta UDP 1813. Verifique se estas portas estão abertas antes de qualquer outra resolução de problemas.
Falhas na validação de certificados 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 hora (clock skew) entre o dispositivo cliente e o servidor RADIUS (o EAP-TLS depende de uma marcação de hora precisa); e se o certificado de CA Raiz foi implementado com sucesso no dispositivo via MDM.
Não aplicação da filiação em grupos é um problema comum quando as políticas de RADIUS referenciam grupos do Entra ID ou do Google Workspace. Verifique se o fornecedor de Cloud RADIUS tem as permissões de API corretas para ler as filiações em grupos. No 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 informações de grupo.
A atribuição de VLAN não está a funcionar indica tipicamente uma incompatibilidade entre os valores dos atributos RADIUS e os IDs de VLAN configurados na infraestrutura sem fios. 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 controlador.
Os dispositivos BYOD a falhar no EAP-TLS indicam habitualmente que o certificado de cliente não foi implementado com sucesso. Para dispositivos geridos pelo Intune, verifique o repositório 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 sincronizou recentemente.
Retorno do Investimento (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, atualizações contínuas de segurança do SO, gestão de certificados e tempo de engenharia especializada. O tempo de um único engenheiro dedicado à manutenção do RADIUS ao longo de um ano excede tipicamente o custo anual de uma subscrição de Cloud RADIUS.
O caso de negócio vai além da redução de custos. Ao associar o acesso à rede a identidades na cloud verificadas, obtém:
Desativação imediata de acessos. Desativar um utilizador no Entra ID ou Google Workspace revoga imediatamente o seu acesso à rede em todos os locais. Não há atrasos, processos manuais ou riscos de um ex-colaborador manter o acesso ao WiFi. Isto apoia diretamente as obrigações do GDPR relativas aos direitos de acesso a dados.
Análise de dados mais rica. Plataformas como a da Purple WiFi Analytics fornecem dados mais detalhados 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 nomeados e autenticados, o que transforma a qualidade dos dados analíticos disponíveis para as equipas de operações e marketing.
Prova 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 horas. 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 multi-site. Um único serviço Cloud RADIUS autentica todos os seus locais com políticas consistentes, geridas a partir de um único painel. Adicionar um novo hotel, loja ou espaço significa apenas 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 de propriedades, esta é uma vantagem operacional significativa.
Para operadores de Transportes e espaços de Saúde onde a disponibilidade da rede é operacionalmente crítica, os fornecedores de Cloud RADIUS oferecem tipicamente SLAs de 99,999% de tempo de atividade com redundância multi-região integrada. 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 leituras adicionais 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 Contabilização (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 identidade.
Todas as redes WiFi empresariais WPA2-Enterprise ou WPA3-Enterprise dependem de um servidor RADIUS. Sem ele, a autenticação IEEE 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. O cliente configura as políticas de autenticação e aponta 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 do sistema operativo e os custos de manutenção especializada.
IEEE 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 requerente (dispositivo do 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. O WPA2-Enterprise e o WPA3-Enterprise dependem ambos 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 do 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 com o 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 de dados de titulares de cartões.
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
Um método de autenticação que cria um túnel TLS encriptado e depois envia o nome de utilizador e a palavra-passe do utilizador através do mesmo. Vulnerável a ataques Evil Twin se o cliente não validar estritamente o certificado do servidor RADIUS.
A predefinição herdada para WiFi empresarial. Ainda é amplamente implementada, mas deve ser migrada 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 identidades e acessos 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 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 de 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 pela Google Admin Console para implementar certificados de cliente em dispositivos geridos sem a 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.
Dynamic VLAN assignment
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 pertença a grupos de diretório do utilizador autenticado. O AP coloca o cliente na VLAN especificada de forma automática.
Permite uma segmentação de rede granular sem configuração manual de VLAN por dispositivo. Os colaboradores com diferentes funções ou departamentos ficam em segmentos de rede distintos, limitando a movimentação lateral e apoiando os requisitos de segmentação do PCI DSS.
Exemplos Práticos
Um hotel de 200 quartos está a migrar a rede de funcionários do back-of-house de um servidor NPS on-premise antigo para uma solução cloud-native. O hotel mudou recentemente para o Microsoft Entra ID e Microsoft 365 E5. Os dispositivos dos funcionários são portáteis Windows geridos pelo Intune. A infraestrutura wireless é 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 sai da empresa.
Implementar uma solução Cloud RADIUS com integração Entra ID. Passo 1: conceder permissões de Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) ao fornecedor de Cloud RADIUS no inquilino do Entra ID. Passo 2: no Intune, criar um perfil de Certificado Fidedigno com a Root CA do Cloud RADIUS e implementá-lo no grupo 'All Corporate Devices'. Passo 3: criar um perfil de Certificado SCEP com o Subject Name 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 pela [Trusted CA] E o utilizador for membro do grupo do 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 de back-of-house. Definir o timeout do RADIUS para 5 segundos. Passo 6: no Intune, criar um perfil de WiFi WPA3-Enterprise para o SSID de back-of-house, especificando EAP-TLS e associando o perfil de certificado SCEP. Implementar no grupo 'All Corporate Devices'. Os dispositivos recebem silenciosamente o certificado e o perfil de WiFi na próxima sincronização do Intune e ligam-se automaticamente. Quando um funcionário sai, a desativação da sua conta do Entra ID revoga imediatamente o acesso à rede em todos os locais.
Uma cadeia de lojas de retalho com 50 estabelecimentos utiliza o Google Workspace e gere uma frota de 500 Chromebooks utilizados pelos colaboradores de loja para operações de inventário e ponto de venda. Atualmente, utilizam uma chave partilhada WPA2 PSK para a rede de operações de loja, 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 infraestrutura wireless é HPE Aruba.
Implementar uma solução Cloud RADIUS com integração Google Workspace através do Google Secure LDAP. Passo 1: na Consola de Administração Google, navegar até Apps, depois LDAP, e adicionar um novo cliente LDAP para o serviço Cloud RADIUS. Configurar permissões de leitura para informações de utilizador e pertença a grupos. Descarregar o certificado de cliente e a chave gerados. Passo 2: configurar o serviço Cloud RADIUS com as credenciais do Google Secure LDAP. Passo 3: configurar uma PKI na cloud para emitir certificados para os Chromebooks. Na Consola de Administração Google, navegar até Dispositivos, depois Redes, depois Certificados, e carregar a Root CA. Configurar o perfil de emissão de certificados e aplicá-lo à Unidade Organizativa Store-Associates. Passo 4: na Consola de Administração Google, criar um perfil de WiFi WPA3-Enterprise para o SSID de operações de loja. Definir EAP-TLS, associar a Root CA e aplicar à OU Store-Associates. Os Chromebooks recebem o certificado e o perfil de WiFi na sincronização seguinte com a Consola de Administração. Passo 5: no HPE Aruba Central, configurar o SSID de operações de loja com WPA3-Enterprise e adicionar os IPs primário e secundário do Cloud RADIUS. Definir o timeout do RADIUS para 5 segundos. Configurar a atribuição dinâmica de VLAN para colocar os colaboradores de loja na VLAN 20 (operações de 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 on-premise para o Microsoft Entra ID. Atualmente, utiliza PEAP-MSCHAPv2 para autenticação WiFi em 300 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 cloud-native?
Dica: Considere as vulnerabilidades da autenticação baseada em credenciais, as capacidades do Microsoft Intune para a implementação de certificados e a necessidade de evitar dependências de infraestrutura on-premise.
Ver resposta modelo
Implemente uma solução Cloud RADIUS com integração com o Entra ID. Utilize o Microsoft Intune para implementar um perfil de Certificado Fidedigno (Root CA) e um perfil de Certificado SCEP nos 300 portáteis. Configure a política de autenticação do Cloud RADIUS para exigir um certificado válido da CA fidedigna 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 associe-o ao perfil de certificado SCEP. Os dispositivos recebem silenciosamente o certificado e a configuração de WiFi na sincronização seguinte do Intune. Isto elimina o risco de roubo de credenciais PEAP-MSCHAPv2, remove a dependência de NPS on-premise e oferece revogação instantânea quando uma conta do Entra ID é desativada.
Q2. Um utilizador do seu hotel relata que não consegue ligar-se ao WiFi da equipa de back-of-house após regressar de duas semanas de férias. Outros membros da equipa estão a ligar-se sem problemas. A rede utiliza EAP-TLS com certificados implementados via Intune. Quais são as três causas mais prováveis, por 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.
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 poderá 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 desfasado (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 desfasado em mais de cinco minutos causará falhas de autenticação. 3. A conta do Entra ID do utilizador foi colocada num grupo diferente durante a sua ausência (por exemplo, movida de pessoal ativo para uma OU diferente), e a política de autenticação RADIUS já não corresponde à sua associação de grupo. Verifique as associações de grupo do utilizador no Entra ID face à 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 o atual WPA2 PSK partilhado na rede de operações das lojas por autenticação 802.1X. Não tem servidores on-premise em nenhuma localização de loja. Que arquitetura deve implementar 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 do Google Secure LDAP. 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 Store-Associates. Crie um perfil de WiFi WPA3-Enterprise especificando EAP-TLS e implemente-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 o atual PSK partilhado, um Chromebook perdido ou roubado mantém o acesso ao WiFi até que o PSK seja alterado em todas as 80 lojas - um processo disruptivo e demorado. Com o EAP-TLS, a remoção do dispositivo da OU Store-Associates na Google Admin Console revoga imediatamente o seu certificado e 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 consegue ligar-se. O estado do dispositivo no Intune mostra o certificado e o perfil de WiFi como implementados com sucesso. Qual é a primeira coisa que deve verificar?
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 de cloud Meraki) para os endereços IP do servidor Cloud RADIUS. As portas de firewall bloqueadas são a principal causa de falhas na implementação inicial. O facto de os certificados e perfis de WiFi estarem implementados com sucesso descarta problemas de configuração do Intune. As verificações seguintes são: incompatibilidade do segredo partilhado do RADIUS entre o Meraki e o serviço Cloud RADIUS; timeout do RADIUS definido com um valor demasiado baixo (aumentar para pelo menos 5 segundos); e se os IPs do servidor Cloud RADIUS estão introduzidos corretamente na configuração do SSID do Meraki.
Continue a ler esta série
Os Benefícios de Segurança do RADIUS as a Service para Equipas de Trabalho Híbridas
Este guia de referência técnica explica como o RADIUS as a Service protege o acesso à rede para equipas de trabalho híbridas em locais distribuídos. Abrange a arquitetura, os benefícios de segurança e as etapas de implementação para substituir a infraestrutura RADIUS local por um serviço de autenticação gerido na nuvem. Para gestores de TI e arquitetos de rede em hotéis, cadeias de retalho, estádios e organizações do setor público, este guia fornece as provas necessárias para avaliar e agir sobre uma migração para RADIUS na nuvem este trimestre.
Como Implementar a Autenticação 802.1X com 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 propriedades 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 simultaneamente os custos operacionais da infraestrutura local.
O que é o Cloud RADIUS? Um Guia Completo sobre 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 informações práticas sobre a migração de servidores locais para um modelo de autenticação baseado na nuvem, escalável, seguro e em conformidade.