Integrating RADIUS as a Service with Cloud Directories (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 autenticação WiFi empresarial. Abrange a transição arquitetural de NPS local para RADIUS nativo na cloud, 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 cloud, este guia faz a ponte entre a gestão de diretórios e a segurança física da rede.

📖 10 min de leitura📝 2,373 palavras🔧 2 exemplos práticos❓ 4 perguntas de prática📚 10 definições principais

Ouça este guia

Ver transcrição do podcast

Welcome to the Purple Technical Briefing. Today, we are covering a topic that sits at the intersection of cloud identity management and physical network security: integrating RADIUS as a Service with cloud directories, specifically Microsoft Entra ID and Google Workspace.

If you are managing enterprise WiFi across a hotel, a retail estate, a stadium, or a public-sector estate, this briefing is directly relevant to your next infrastructure decision.

Let us start with context. For the past two decades, WiFi authentication in enterprise environments relied on a fairly predictable stack. You had on-premise Active Directory, Windows Network Policy Server acting as the RADIUS server, and WPA2-Enterprise on the access points. It worked. But it required on-premise servers, manual certificate management, and a team with specialist knowledge to keep it running.

The problem is that most organisations are no longer on-premise first. They are cloud-first. Microsoft Entra ID and Google Workspace are now the directories of record for millions of organisations. And here is the gap: your wireless access points still speak RADIUS. They do not understand SAML. They do not understand OAuth. They speak RADIUS, and they always will.

So the question is: how do you bridge your cloud identity platform to your physical network infrastructure, without dragging an on-premise server back into the picture?

The answer is RADIUS as a Service. A cloud-hosted RADIUS server that integrates directly with your cloud directory, validates authentication requests in real time, and returns an access decision to your access point. No on-premise servers. No patching. No 2am certificate renewal emergencies.

The foundation is IEEE 802.1X. When a device tries to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point acts as an authenticator. It intercepts the connection attempt and forwards EAP packets to the RADIUS server. The RADIUS server validates the identity and returns either an Access-Accept or an Access-Reject. Only then does the access point grant network access.

Now, the most consequential technical decision in this entire deployment is your choice of EAP method.

PEAP-MSCHAPv2 is the old way. It uses usernames and passwords. It sounds secure. It is not. If a device does not strictly validate the RADIUS server certificate, an attacker can set up a rogue access point with your SSID, intercept the handshake, and capture the credentials. This is called an Evil Twin attack, and it is happening.

EAP-TLS is the right answer. It uses digital certificates on both the server and the client device for mutual authentication. There are no passwords involved. The device presents its certificate. The RADIUS server validates it against your cloud directory in real time. No credential theft possible. No phishing vector. No helpdesk tickets when someone changes their password.

Let us walk through a Microsoft Entra ID deployment.

Step one: licensing and PKI. You need Microsoft 365 E3 or E5 to access Intune and Conditional Access. Establish a cloud PKI using your Cloud RADIUS vendor's managed PKI or Microsoft's own Cloud PKI.

Step two: certificate deployment via Intune. Create a Trusted Certificate profile with your Root CA and deploy it to device groups. Then create a SCEP certificate profile. For user-based authentication, the subject name uses the User Principal Name.

Step three: Cloud RADIUS configuration. Grant the RADIUS service Microsoft Graph API permissions: User.Read.All and GroupMember.Read.All. Define your authentication policies: allow access if the certificate is issued by our trusted CA, the user is a member of the Corporate-WiFi-Users group in Entra ID, and the device is marked compliant in Intune.

Step four: wireless infrastructure. In your controller, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, add the Cloud RADIUS IP addresses and shared secrets. Set the RADIUS timeout to at least five seconds. Create your WPA3-Enterprise SSID.

Step five: WiFi profile deployment. Create a WiFi configuration profile in Intune. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, link the SCEP certificate profile. Devices silently receive the certificate and WiFi profile on their next sync. They connect automatically. No user interaction required.

Now let us look at the Google Workspace path, because it is architecturally different in one important way.

Google does not offer a native RADIUS service. There is no Google equivalent of Windows NPS. So you always need an intermediary: a Cloud RADIUS provider that connects to Google Workspace via Google Secure LDAP or via a SAML and OAuth integration.

Google Secure LDAP is available on Cloud Identity Premium and Google Workspace Enterprise editions. It provides a traditional LDAP interface to your cloud directory. Your Cloud RADIUS server connects to ldap.google.com on port 636 using client certificates that Google generates for you. From that point, the RADIUS server can query Google's directory to validate credentials or group memberships.

For managed Chromebooks, the deployment path uses the Google Admin Console. You configure a cloud PKI to issue certificates, push the Root CA and client certificates to the Chromebooks, and deploy a WiFi profile specifying EAP-TLS. The Chromebooks connect silently. For BYOD devices and guest access, you use a captive portal tied to Google Single Sign-On. That is the right separation: EAP-TLS for managed devices, captive portal for everything else.

Let us talk about pitfalls, because this is where deployments go wrong.

The first and most common is blocked firewall ports. RADIUS authentication uses UDP port 1812. RADIUS accounting uses UDP port 1813. If those ports are not open outbound from your wireless infrastructure to the Cloud RADIUS service, nothing works. Check this first, every time.

The second pitfall is certificate expiry. If your RADIUS server certificate expires, every device on the network loses connectivity simultaneously. Set monitoring alerts at 90 days, 30 days, and 7 days before expiry. Automate renewal where possible.

The third is clock skew. EAP-TLS relies on accurate timekeeping for certificate validation. If a device's system clock is significantly out of sync, certificate validation fails. Ensure NTP is configured correctly across all devices and infrastructure.

The fourth, specific to PEAP deployments, is failing to enforce strict server certificate validation on client devices. Without it, devices will accept any certificate presented by any access point claiming to be yours. This is the single configuration decision that separates a secure deployment from a vulnerable one.

Now for a rapid-fire question and answer.

Can I use Cloud RADIUS for both staff and guest WiFi? Staff WiFi, yes, using EAP-TLS. Guest WiFi should use a separate captive portal. Mixing the two on a single SSID creates unnecessary complexity and security risk.

Does this work with WPA3? Yes. WPA3-Enterprise is fully supported and recommended for all new deployments.

What about compliance? EAP-TLS with Cloud RADIUS supports PCI DSS requirements for strong authentication on cardholder data networks. It also supports GDPR obligations by enabling precise access logging and instant revocation when an employee leaves.

How does this affect our analytics capabilities? Positively. By tying network access to a verified cloud identity, platforms like Purple's WiFi Analytics provide richer data on space utilisation. You move from anonymous MAC addresses to authenticated, named users, which transforms the quality of your insight.

To summarise the key takeaways.

One: Cloud RADIUS eliminates on-premise server dependencies. Your access points authenticate against a cloud-hosted service that integrates directly with Entra ID or Google Workspace.

Two: EAP-TLS is the right authentication method. Certificates replace passwords. No phishing vector, no credential theft, no helpdesk overhead from password resets.

Three: Microsoft Intune and Google Admin Console automate certificate deployment. Devices receive certificates and WiFi profiles silently, with no user interaction.

Four: Dynamic VLAN assignment via RADIUS attributes enables granular network segmentation based on directory group membership. This limits lateral movement and supports compliance.

Five: Always verify ports 1812 and 1813 are open, monitor certificate expiry, and enforce strict server certificate validation.

If you are planning a deployment this quarter, start with a pilot group of 20 to 50 devices. Validate the certificate deployment, the RADIUS authentication, and the VLAN assignment before rolling out globally. The investment in getting this right pays dividends in reduced helpdesk overhead, a stronger security posture, and the ability to use your network data for genuine business intelligence.

Thank you for listening to the Purple Technical Briefing. For detailed deployment steps, configuration examples, and worked scenarios, see the full technical reference guide at purple.ai.

Principais Conclusões

✓Cloud RADIUS eliminates on-premise NPS and FreeRADIUS servers. Your access points authenticate against a cloud-hosted service that integrates directly with Microsoft Entra ID or Google Workspace.
✓EAP-TLS is the correct authentication method for enterprise WiFi. It uses digital certificates instead of passwords, eliminating credential theft, phishing, and password-related helpdesk overhead.
✓Microsoft Intune and Google Admin Console automate certificate deployment to managed devices via SCEP profiles. Devices receive certificates and WiFi profiles silently, with no user interaction.
✓Google Workspace requires an intermediary for RADIUS integration. Google Secure LDAP (available on Cloud Identity Premium and Enterprise editions) provides the LDAP interface that Cloud RADIUS servers use to query the Google directory.
✓Dynamic VLAN assignment via RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) enables granular network segmentation based on directory group membership, supporting PCI DSS requirements.
✓Check UDP ports 1812 and 1813 first. Blocked firewall ports are the leading cause of initial deployment failure. Monitor certificate expiry at 90, 30, and 7 days. Enforce strict server certificate validation on all PEAP deployments.
✓Disabling a user in Entra ID or Google Workspace immediately revokes their WiFi access at all sites. This is the primary offboarding advantage over PSK-based networks and directly supports GDPR obligations.

Resumo executivo

Para as empresas modernas que investem em ecossistemas de identidade cloud, a ligação de diretórios cloud 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 fardo - dispendiosa de manter, difícil de dimensionar e incompatível com modelos de segurança zero-trust.

RADIUS as a Service (RADIUSaaS) muda a equação. Um servidor RADIUS alojado na cloud integra-se diretamente com o seu diretório cloud, 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 (patching) 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 o PCI DSS e GDPR, e proporciona uma experiência fluida para os colaboradores em todos os locais.

Este guia abrange a decisão arquitetural entre o NPS local e o RADIUS nativo na cloud, a implementação de EAP-TLS através do Microsoft Intune e da Google Admin Console, e as melhores práticas operacionais para proteger o acesso sem fios em hotéis, superfícies comerciais, estádios e recintos do setor público. Para uma introdução mais ampla ao controlo de acesso à rede, consulte Um Guia para o Seu Sistema de Controlo de Acesso à Rede .

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 supplicant) tenta ligar-se a uma rede WPA2-Enterprise ou WPA3-Enterprise, o Ponto de Acesso Sem Fios (o authenticator) 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 - supplicant, authenticator, 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 o servidor RADIUS reside e a forma como comunica com o seu diretório.

Arquitetura RADIUS nativa na cloud

Uma arquitetura RADIUS nativa na cloud 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 API Microsoft Graph, 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 acesso à rede zero-trust e reduz significativamente os custos operacionais.

La tabela abaixo compara as duas principais abordagens arquiteturais:

Dimensão	Híbrido local (NPS)	Nativo na cloud (RADIUSaaS)
Infraestrutura	Necessária 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	Cloud PKI do fornecedor ou Microsoft
Alta disponibilidade	HA manual e balanceamento de carga	Dimensionamento automático 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 inicial 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 com maior impacto 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 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 existem palavras-passe para introduzir 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 o PCI DSS v4.0 (Requisito 8.3 sobre autenticação forte) e com as obrigações de proteção de dados do GDPR.

Google Workspace: a diferença arquitetural

O Microsoft Entra ID e o Google Workspace diferem num aspeto importante para a integração do 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 API Microsoft Graph. A Google, no entanto, não oferece um serviço RADIUS nativo. É sempre necessário um intermediário.

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 cloud. O seu servidor Cloud RADIUS liga-se a ldap.google.com na porta 636 utilizando certificados de cliente que a Google gerates para si. A partir desse ponto, o servidor RADIUS consulta o diretório da Google para validar credenciais ou associações a grupos, tal como consultaria um Active Directory local.

An alternative path uses SAML-based integration, 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 as associações a grupos em tempo real.

Guia de implementação

A implementação do RADIUSaaS com EAP-TLS requer a coordenação de identidade, gestão de dispositivos e infraestrutura de rede. A seguinte abordagem em cinco fases 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 possui 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 na nuvem 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 (Trusted Certificate). Carregue o certificado da Root CA e implemente-o nos seus grupos de dispositivos de destino. Isto garante que os dispositivos clientes 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 Subject Name para CN={{UserPrincipalName}}. Para autenticação baseada no dispositivo, utilize CN={{DeviceName}}. Defina o Subject Alternative Name para incluir o User Principal Name ou o ID do dispositivo.

Caminho da Google Admin Console: navegue para Dispositivos, depois Redes e, em seguida, Certificados. Carregue a sua Root CA. Configure um mecanismo de emissão de certificados - uma PKI na nuvem que suporte a integração SCEP com o Google Workspace, ou o Google Cloud Certificate Connector que serve de proxy para os 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 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 Google Admin Console 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 o 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 associação a grupos e a integridade 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 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 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 WiFi de Convidados . Para ambientes de Retalho , considere a implementação do SSID corporativo apenas em áreas de bastidores (back-of-house).

Fase 5: implementar o perfil de WiFi via MDM

Microsoft Intune: crie um perfil de configuração de WiFi. Defina o SSID para corresponder exatamente à configuração da sua infraestrutura. Selecione WPA2-Enterprise ou WPA3-Enterprise. Nas definições de EAP, selecione EAP-TLS. Associe o perfil de certificado SCEP como o certificado de cliente e especifique o perfil de Trusted Root CA. 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 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 Root CA fidedigno para os dispositivos. Aplique este perfil às suas Unidades Organizacionais. Os Chromebooks ligam-se de forma silenciosa e segura.

Boas práticas

Exija o 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 da Google Admin Console, existe um campo para especificar a CA fidedigna para 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 associação a grupos do utilizador no Entra ID ou Google Workspace e atribuí-los dinamicamente a diferentes VLANs. O servidor RADIUS devolve o Tunnel-Private-Group-Id ao ponto de acesso, o que coloca o cliente na VLAN correta. Isto limita o movimento lateral em caso de comprometimento e apoia 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 lida com 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 de forma proativa. Configure a monitorização 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 perdem a conectividade em simultâneo. Automatize a renovação onde a sua PKI o permitir.

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 (on-premise) 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 monitorização (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 relógio (clock skew) entre o dispositivo cliente e o servidor RADIUS (o EAP-TLS depende de uma cronometragem precisa); e se o certificado Root CA foi implementado com sucesso no dispositivo via MDM.

A não aplicação da pertença a grupos é um problema comum quando as políticas 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 pertenças aos 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 funciona 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.

Dispositivos BYOD a falhar no EAP-TLS normalmente indica 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.

ROI e impacto comercial

A transição para o Cloud RADIUS proporciona poupanças operacionais mensuráveis. O RADIUS local (on-premise) 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 que um único engenheiro despende na 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 nuvem verificadas, obtém:

Desativação instantânea (offboarding). Desativar um utilizador no Entra ID ou no Google Workspace revoga imediatamente o seu acesso à rede em todos os locais. Não há atrasos, processos manuais, nem o risco de um ex-funcionário manter o acesso WiFi. Isto apoia diretamente as obrigações do GDPR relativas aos direitos de acesso aos dados.

Análises mais ricas. Plataformas como a WiFi Analytics da Purple fornecem dados mais ricos sobre a utilização do espaço e as jornadas dos visitantes quando o acesso à rede está associado a identidades autenticadas. Passa de endereços MAC anónimos para utilizadores identificados e autenticados, o que transforma a qualidade dos dados analíticos disponíveis para as equipas de operações e marketing.

Evidência 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 responsabilidade 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 de controlo. Adicionar um novo hotel, loja ou espaço significa adicionar os seus pontos de acesso à configuração 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 o tempo de atividade da rede é operacionalmente crítico, os fornecedores de Cloud RADIUS oferecem tipicamente SLAs de 99,999% de tempo de atividade com failover multi-regiã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 ler mais sobre tópicos relacionados, consulte Definição de Computador WAN: Um Guia Prático para 2026 and Dia Mundial do WiFi 2026: Como o Seu Espaço Pode Ajudar a Superar a Fenda Digital .

Definições Principais

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service. The RADIUS server acts as the decision engine between your access points and your identity directory.

Every enterprise WPA2-Enterprise or WPA3-Enterprise WiFi network depends on a RADIUS server. Without it, IEEE 802.1X authentication does not function.

RADIUS as a Service (RADIUSaaS)

A cloud-hosted RADIUS implementation delivered as a managed service. The provider maintains the infrastructure, patching, high availability, and identity provider integrations. You configure authentication policies and point your access points to the cloud RADIUS IPs.

RADIUSaaS eliminates the need for on-premise NPS or FreeRADIUS servers, removing the associated hardware, OS patching, and specialist maintenance overhead.

IEEE 802.1X

An IEEE standard for port-based Network Access Control. It defines the three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS server). The authenticator blocks all traffic until the RADIUS server grants access.

The foundational standard for enterprise WiFi authentication. WPA2-Enterprise and WPA3-Enterprise both rely on 802.1X.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

An authentication method defined in RFC 5216 that uses digital certificates on both the RADIUS server and the client device for mutual authentication. Neither party sends a password. The client presents its certificate; the server validates it against the directory in real time.

The gold standard for enterprise WiFi security. Eliminates credential theft, phishing, and password-related helpdesk overhead. Required for PCI DSS compliance on cardholder data networks.

PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)

An authentication method that creates an encrypted TLS tunnel and then sends the user's username and password through it. Vulnerable to Evil Twin attacks if the client does not strictly validate the RADIUS server certificate.

The legacy default for enterprise WiFi. Still widely deployed but should be migrated to EAP-TLS in all new and existing deployments where possible.

Microsoft Entra ID

Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory (Azure AD). Manages user identities, group memberships, device compliance, and Conditional Access policies.

The primary identity source for Cloud RADIUS in Microsoft-centric environments. Cloud RADIUS providers connect to Entra ID via Microsoft Graph API.

Google Secure LDAP

A managed service available on Cloud Identity Premium and Google Workspace Enterprise editions that provides a traditional LDAP interface to Google's cloud directory. RADIUS servers connect to ldap.google.com on port 636 using client certificates.

The primary integration path for connecting a Cloud RADIUS server to Google Workspace. Google does not offer a native RADIUS service, so Secure LDAP acts as the bridge.

PKI (Public Key Infrastructure)

The set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. A PKI is required to issue the client and server certificates used in EAP-TLS authentication.

Cloud-native PKI options from RADIUS vendors or Microsoft (Cloud PKI) eliminate the need for on-premise Active Directory Certificate Services (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

A protocol that enables devices to request and receive digital certificates from a Certificate Authority automatically. Used by Microsoft Intune and Google Admin Console to deploy client certificates to managed devices without user interaction.

SCEP profiles in Intune are the mechanism by which corporate devices silently receive the client certificates needed for EAP-TLS authentication.

Dynamic VLAN assignment

A RADIUS feature that returns VLAN assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) to the access point based on the authenticated user's directory group membership. The AP places the client on the specified VLAN automatically.

Enables granular network segmentation without manual VLAN configuration per device. Staff in different roles or departments land on different network segments, limiting lateral movement and supporting PCI DSS segmentation requirements.

Exemplos Práticos

A 200-room hotel is migrating its back-of-house staff network from an ageing on-premise NPS server to a cloud-native solution. The hotel has recently moved to Microsoft Entra ID and Microsoft 365 E5. Staff devices are Windows laptops managed by Intune. The wireless infrastructure is Cisco Meraki. The hotel needs staff to connect automatically without password prompts, and needs instant revocation when a member of staff leaves.

Deploy a Cloud RADIUS solution with Entra ID integration. Step 1: grant the Cloud RADIUS provider Microsoft Graph API permissions (User.Read.All, GroupMember.Read.All, Device.Read.All) in the Entra ID tenant. Step 2: in Intune, create a Trusted Certificate profile with the Cloud RADIUS Root CA and deploy it to the 'All Corporate Devices' group. Step 3: create a SCEP Certificate profile with Subject Name CN={{UserPrincipalName}} and deploy it to the same group. Step 4: configure the Cloud RADIUS authentication policy: allow access if certificate is issued by [Trusted CA] AND user is member of [Hotel-Staff-WiFi] Entra ID group AND device is Intune-compliant. Step 5: in Cisco Meraki dashboard, add the Cloud RADIUS primary and secondary IPs as RADIUS servers on the back-of-house SSID. Set RADIUS timeout to 5 seconds. Step 6: in Intune, create a WPA3-Enterprise WiFi profile for the back-of-house SSID, specifying EAP-TLS and linking the SCEP certificate profile. Deploy to the 'All Corporate Devices' group. Devices silently receive the certificate and WiFi profile on next Intune sync and connect automatically. When a staff member leaves, disabling their Entra ID account immediately revokes network access at all sites.

Comentário do Examinador: This approach eliminates the on-premise NPS dependency entirely. EAP-TLS removes the phishing vector of credential-based authentication. Intune automates certificate lifecycle management, removing the manual overhead that caused the previous NPS deployment to fall behind on certificate renewals. The Entra ID group policy means that when HR disables an account, network access is revoked in real time - no manual RADIUS policy update required. The Cisco Meraki integration is straightforward: Cloud RADIUS is hardware-agnostic and works with any 802.1X-capable infrastructure.

A retail chain with 50 stores uses Google Workspace and manages a fleet of 500 Chromebooks used by store associates for inventory and point-of-sale operations. They currently use a shared WPA2 PSK for the store operations network, which creates a security risk when devices are lost or stolen. They want to move to 802.1X authentication without deploying local servers at each store. Their wireless infrastructure is HPE Aruba.

Deploy a Cloud RADIUS solution with Google Workspace integration via Google Secure LDAP. Step 1: in Google Admin Console, navigate to Apps, then LDAP, and add a new LDAP client for the Cloud RADIUS service. Configure read permissions for user information and group membership. Download the generated client certificate and key. Step 2: configure the Cloud RADIUS service with the Google Secure LDAP credentials. Step 3: configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, navigate to Devices, then Networks, then Certificates, and upload the Root CA. Configure the certificate issuance profile and apply it to the Store-Associates Organisational Unit. Step 4: in Google Admin Console, create a WPA3-Enterprise WiFi profile for the store operations SSID. Set EAP-TLS, link the Root CA, and apply to the Store-Associates OU. Chromebooks receive the certificate and WiFi profile on next Admin Console sync. Step 5: in HPE Aruba Central, configure the store operations SSID with WPA3-Enterprise and add the Cloud RADIUS primary and secondary IPs. Set RADIUS timeout to 5 seconds. Configure dynamic VLAN assignment to place store associates on VLAN 20 (store operations) based on their Google Workspace group membership. When a Chromebook is lost or stolen, removing it from the Store-Associates OU immediately revokes its network access.

Comentário do Examinador: This deployment eliminates the shared PSK risk. A lost or stolen Chromebook with a shared PSK gives an attacker persistent network access until the PSK is rotated across all 50 stores. With EAP-TLS, the certificate on the lost device can be revoked immediately. The Google Secure LDAP integration is the correct path for Google Workspace environments - it provides a stable, standards-based interface that the Cloud RADIUS service can query without requiring a custom API integration. Dynamic VLAN assignment ensures store associates land on the correct network segment, supporting PCI DSS network segmentation requirements for retail environments.

Perguntas de Prática

Q1. Your organisation is migrating from on-premise Active Directory to Microsoft Entra ID. You currently use PEAP-MSCHAPv2 for WiFi authentication on 300 corporate laptops managed by Intune. You have Microsoft 365 E5 licensing. What is the most secure and operationally efficient path to migrate WiFi authentication to a cloud-native architecture?

Dica: Consider the vulnerabilities of credential-based authentication, the capabilities of Microsoft Intune for certificate deployment, and the need to avoid on-premise infrastructure dependencies.

Ver resposta modelo

Deploy a Cloud RADIUS solution with Entra ID integration. Use Microsoft Intune to deploy a Trusted Certificate profile (Root CA) and a SCEP Certificate profile to the 300 laptops. Configure the Cloud RADIUS authentication policy to require a valid certificate from the trusted CA and membership of the Corporate-WiFi-Users Entra ID group. Create a WPA3-Enterprise WiFi profile in Intune specifying EAP-TLS and link the SCEP certificate profile. Devices silently receive the certificate and WiFi configuration on next Intune sync. This eliminates PEAP-MSCHAPv2 credential theft risk, removes the on-premise NPS dependency, and provides instant revocation when an Entra ID account is disabled.

Q2. A user at your hotel reports they cannot connect to the back-of-house staff WiFi after returning from a two-week holiday. Other staff are connecting without issue. The network uses EAP-TLS with certificates deployed via Intune. What are the three most likely causes, in order of likelihood?

Dica: EAP-TLS relies on time-sensitive cryptographic assets and real-time directory lookups.

Ver resposta modelo

The user's client certificate has expired. Certificates have a defined validity period, and if the device was offline during the renewal window, the SCEP profile may not have renewed it. Check the certificate expiry date in the Intune device certificate store. 2. The device's system clock is significantly out of sync (clock skew), causing certificate validation to fail. EAP-TLS validates certificate timestamps; a clock more than five minutes out of sync will cause authentication failures. 3. The user's Entra ID account was placed in a different group during their absence (for example, moved from active staff to a different OU), and the RADIUS authentication policy no longer matches their group membership. Check the user's group memberships in Entra ID against the RADIUS policy.

Q3. You are the IT manager for a retail chain with 80 stores. You use Google Workspace and manage 400 Chromebooks via Google Admin Console. You want to replace the current shared WPA2 PSK on the store operations network with 802.1X authentication. You have no on-premise servers at any store location. What architecture do you deploy, and what is the primary security benefit over the current PSK approach?

Dica: Consider what happens when a Chromebook is lost or stolen under each authentication model.

Ver resposta modelo

Deploy a Cloud RADIUS service with Google Secure LDAP integration. Configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, deploy the Root CA and a SCEP client certificate profile to the Store-Associates Organisational Unit. Create a WPA3-Enterprise WiFi profile specifying EAP-TLS and deploy it to the same OU. Configure HPE Aruba (or equivalent) access points at each store to point to the Cloud RADIUS service. The primary security benefit: under the current shared PSK, a lost or stolen Chromebook retains WiFi access until the PSK is rotated across all 80 stores - a disruptive, time-consuming process. With EAP-TLS, removing the device from the Store-Associates OU in Google Admin Console immediately revokes its certificate and network access, with no impact on any other device.

Q4. During a Cloud RADIUS deployment, you configure the SSID on Cisco Meraki access points and deploy the Intune WiFi profile to a pilot group of 20 devices. None of the devices can connect. The Intune device status shows the certificate and WiFi profile as successfully deployed. What is the first thing you check?

Dica: The most common cause of initial deployment failure is not a configuration error in the RADIUS policy or the certificate.

Ver resposta modelo

Check that UDP ports 1812 and 1813 are open outbound from the Cisco Meraki access points (or the Meraki cloud infrastructure) to the Cloud RADIUS server IP addresses. Blocked firewall ports are the leading cause of initial deployment failure. The fact that certificates and WiFi profiles are successfully deployed rules out Intune configuration issues. The next checks are: RADIUS shared secret mismatch between Meraki and the Cloud RADIUS service; RADIUS timeout set too low (increase to at least 5 seconds); and whether the Cloud RADIUS server IPs are correctly entered in the Meraki SSID configuration.

Continue a ler esta série

The Security Benefits of RADIUS as a Service for Hybrid Workforces

Este guia de referência técnica explica como o RADIUS as a Service protege o acesso à rede para equipas 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 numa migração para RADIUS na nuvem este trimestre.

How to Implement 802.1X Authentication with Cloud RADIUS

Este guia de referência técnica fornece uma estrutura abrangente para a implementação da autenticação 802.1X com Cloud RADIUS em propriedades empresariais distribuídas. Detalha a arquitetura, a seleção do método EAP, o sequenciamento da implementação e as estratégias de mitigação de riscos necessárias para proteger o acesso à rede, eliminando a sobrecarga operacional da infraestrutura no local.

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Este guia abrangente 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 acionáveis sobre a migração de servidores no local para um modelo de autenticação baseado na nuvem, escalável, seguro e em conformidade.