Autenticação WiFi do Google Workspace: Integração de Chromebook e LDAP
Uma referência técnica definitiva para administradores de TI que implementam WiFi seguro em ambientes Google Workspace. Este guia abrange a implementação de certificados 802.1X em Chromebooks geridos através da Consola de Administração do Google, a integração do Google Secure LDAP como backend RADIUS e as decisões de arquitetura para locais de ensino, media e empresas. Fornece passos de implementação práticos, estudos de caso reais e uma comparação direta de métodos EAP para ajudar as equipas a transitar de PSKs partilhadas vulneráveis para um controlo de acesso à rede robusto e baseado na identidade.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança WiFi para Grandes Empresas →
Resumo Executivo
Para espaços empresariais, instituições de ensino e fornecedores de hotelaria padronizados no Google Workspace, a implementação de uma autenticação WiFi segura e contínua tem apresentado historicamente um desafio quando comparada com ambientes Microsoft Active Directory. Este guia detalha a arquitetura e a implementação da autenticação WiFi com Google Workspace, focando-se especificamente na distribuição de certificados Chromebook 802.1X e na integração do Google Secure LDAP para backends RADIUS.
Os gestores de TI e os arquitetos de rede devem equilibrar a segurança (WPA3-Enterprise, IEEE 802.1X) com a fricção para o utilizador. Enquanto as chaves pré-partilhadas (PSKs) são facilmente comprometidas e difíceis de rotacionar, a autenticação baseada em certificados (EAP-TLS) ou a autenticação baseada em credenciais (PEAP-MSCHAPv2) associada diretamente à identidade do utilizador no Google Workspace fornece um controlo de acesso robusto, aplicação de políticas granulares e roaming contínuo em redes de Guest WiFi e corporativas.
Esta referência técnica descreve os passos exatos para configurar a Google Admin Console para a distribuição automatizada de certificados, implementar o Google Secure LDAP e integrar estas fontes de identidade com servidores RADIUS empresariais. Ao seguir estas boas práticas independentes de fornecedor, as organizações podem mitigar o roubo de credenciais, reduzir os pedidos de suporte e garantir a conformidade com o GDPR e o PCI-DSS.
Detalhe Técnico Aprofundado
A Arquitetura da Autenticação WiFi do Google Workspace
A autenticação de clientes sem fios no Google Workspace exige a ponte entre a identidade nativa da nuvem (SAML/OAuth) e os protocolos de rede legados (RADIUS/802.1X). Ao contrário do Active Directory, que comunica nativamente em LDAP e se integra perfeitamente com o Network Policy Server (NPS), o Google Workspace requer uma camada intermediária deliberada.
Existem duas arquiteturas principais para o conseguir:
Arquitetura 1 - Google Secure LDAP (Cloud Identity Premium / Google Workspace Enterprise): O Google fornece uma interface LDAP gerida para o seu diretório na nuvem. O seu servidor RADIUS (por exemplo, FreeRADIUS, Cisco ISE, Aruba ClearPass) liga-se de forma segura a ldap.google.com utilizando certificados de cliente. Quando um utilizador tenta ligar-se ao WiFi, o servidor RADIUS valida as suas credenciais no serviço LDAP do Google.
Arquitetura 2 - Portais Cativos Baseados em SAML / RadSec: Para cenários BYOD (Bring Your Own Device) ou de convidados, os utilizadores ligam-se a uma rede aberta ou PSK, que os redireciona para um Captive Portal. O portal autentica o utilizador através do Google SSO (SAML/OAuth). Uma vez autenticado, o sistema pode aprovisionar dinamicamente uma credencial única (por exemplo, uma PSK dinâmica ou um certificado temporário) para ligações subsequentes.
Figura 1: O fluxo de autenticação 802.1X para ambientes Google Workspace, mostrando o servidor RADIUS como o intermediário entre o ponto de acesso e o Google Secure LDAP.
Tipos de EAP e Suporte para Chromebook
Os Chromebooks suportam nativamente vários tipos de Extensible Authentication Protocol (EAP) para 802.1X. A escolha do tipo de EAP dita a postura de segurança e a complexidade de implementação. Para uma visão geral abrangente dos fundamentos do 802.1X, consulte 802.1X Authentication: Securing Network Access on Modern Devices.
Figura 2: Uma comparação direta dos métodos EAP suportados por Chromebooks, destacando os compromissos de segurança e complexidade.
| Método EAP | Tipo de Autenticação | Certificado de Cliente Obrigatório | Risco de Phishing | Recomendado Para |
|---|---|---|---|---|
| EAP-TLS | Certificado | Sim | Nenhum | Chromebooks Geridos |
| PEAP-MSCHAPv2 | Palavra-passe | Não | Médio | Implementações BYOD / PME |
| EAP-TTLS | Palavra-passe | Não | Médio | Ambientes mistos |
EAP-TLS (Transport Layer Security): O padrão de excelência para WiFi empresarial. Requer tanto um certificado de servidor (no servidor RADIUS) como um certificado de cliente (no Chromebook). Isto elimina a necessidade de palavras-passe, mitigando riscos de phishing. A consola Google Admin Console pode enviar automaticamente certificados de cliente para Chromebooks geridos através do Google Cloud Certificate Connector ou de integrações SCEP/EST de terceiros.
PEAP-MSCHAPv2 / EAP-TTLS: Estes protocolos utilizam um certificado de servidor para estabelecer um túnel seguro, dentro do qual o nome de utilizador e a palavra-passe do utilizador são trocados. Embora sejam mais fáceis de implementar para dispositivos não geridos, são vulneráveis a roubo de credenciais se o dispositivo do cliente não validar estritamente o certificado do servidor.
Ao desenhar a rede, considere como estes eventos de autenticação se correlacionam com sistemas a jusante como plataformas de WiFi Analytics, que dependem de endereços MAC estáveis ou nomes de utilizador autenticados para monitorizar as jornadas dos utilizadores e a afluência de público.
Google Workspace vs. Microsoft e Okta: Uma Avaliação Comparativa
As organizações que avaliam plataformas de identidade para autenticação WiFi empresarial devem compreender os compromissos inerentes. O Microsoft Active Directory continua a ser a opção mais perfeitamente integrada, devido ao seu suporte nativo LDAP e integração estreita com o NPS. A Okta fornece uma capacidade robusta de RADIUS-as-a-Service através do seu RADIUS Agent, eliminando a necessidade de infraestrutura RADIUS autogerida. O Google Workspace, através de Secure LDAP, é uma opção sólida mas requer uma arquitetura mais deliberada - necessita sempre de um servidor RADIUS intermediário, e o serviço Secure LDAP só está disponível em licenças de nível superior.
| Capacidade | Google Workspace | Microsoft AD/Entra | Okta |
|---|---|---|---|
| Suporte RADIUS Nativo | Não (requer servidor RADIUS) | Via NPS | Via RADIUS Agent |
| Interface LDAP | Google Secure LDAP | Native AD LDAP | LDAP Interface Agent |
| Suporte EAP-TLS | Sim (via integração PKI) | Sim (nativo) | Sim |
| Envio de Cert. para Dispositivo Gerido | Google Admin Console | Intune / GPO | Integração MDM |
| Requisito de Licença | Enterprise / Cloud Identity Premium | Incluído no AD | Workforce Identity |
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
Implementação de 802.1X em Chromebooks Geridos
A implementação de WiFi seguro em Chromebooks geridos envolve a configuração da consola Google Admin Console para enviar os perfis de rede e certificados necessários. Isto garante que os dispositivos se ligam automaticamente sem intervenção do utilizador.
Passo 1: Configurar o Servidor RADIUS
Implemente um servidor RADIUS (por exemplo, FreeRADIUS) capaz de EAP-TLS ou PEAP. Instale um certificado de servidor fidedigno no servidor RADIUS. Se utilizar uma CA privada, certifique-se de que o certificado Root CA é exportado para implementação nos clientes. Configure o servidor RADIUS para consultar o Google Secure LDAP (se utilizar autenticação baseada em credenciais) ou para validar certificados de cliente contra a sua CA (se utilizar EAP-TLS).
Passo 2: Configurar o Google Secure LDAP (Para PEAP/EAP-TTLS)
Na Consola de Administração do Google, navegue para Aplicações > LDAP. Adicione um novo cliente LDAP (ex. "Enterprise RADIUS"). Configure as permissões de acesso (ler informações do utilizador, verificar palavra-passe). Transfira o certificado e a chave do cliente gerados. Instale estas credenciais no seu servidor RADIUS e configure-o para se ligar a ldap.google.com:636.
Passo 3: Implementar Certificados nos Chromebooks (Para EAP-TLS)
Na Consola de Administração do Google, navegue para Dispositivos > Redes > Certificados. Faça o upload do seu certificado Root CA e marque-o como "Autoridade de Certificação Fidedigna". Configure um mecanismo para emitir certificados de cliente para dispositivos através do Google Cloud Certificate Connector ou de um fornecedor de PKI baseado na nuvem que suporte integração SCEP/EST.
Passo 4: Criar o Perfil de WiFi na Consola de Administração do Google
Navegue para Dispositivos > Redes > WiFi. Crie um novo perfil de rede WiFi. Defina o SSID e selecione WPA/WPA2/WPA3-Enterprise como o Tipo de Segurança. Selecione o tipo de EAP adequado. Se estiver a utilizar EAP-TLS, selecione o certificado de cliente implementado. Se estiver a utilizar PEAP, configure-o para utilizar as credenciais de início de sessão do utilizador. Crucialmente, selecione o certificado Root CA fidedigno para garantir que o Chromebook valida o servidor RADIUS. Aplique o perfil às Unidades Organizacionais (OUs) apropriadas.
Melhores Práticas
Validação Estrita de Certificado do Servidor: Force sempre a validação do certificado do servidor nos dispositivos clientes. A falha neste processo expõe os utilizadores a ataques de Evil Twin, onde um atacante emite o mesmo SSID e captura credenciais. Esta única decisão de configuração é a diferença entre uma implementação segura e uma vulnerável. Para uma exploração mais detalhada da arquitetura de segurança 802.1X, consulte 802.1X Authentication: Securing Network Access on Modern Devices.
Segmentar Redes por Função: Utilize atributos RADIUS (ex. Filter-Id, Tunnel-Private-Group-Id) devolvidos pelo Google LDAP para atribuir utilizadores dinamicamente a diferentes VLANs com base na sua adesão a grupos do Google Workspace (ex. Funcionários vs. Alunos). Isto limita o movimento lateral e melhora significativamente a postura de segurança.
Monitorizar e Auditar: Reveja regularmente os registos de autenticação RADIUS e os registos de auditoria do Google Workspace. Integre estes registos num sistema SIEM para detetar padrões de autenticação anómalos ou tentativas de força bruta. Considere como estes dados alimentam plataformas mais amplas de inteligência de rede.
Planeamento para BYOD: Embora os Chromebooks geridos possam utilizar EAP-TLS, os dispositivos não geridos (telemóveis pessoais de funcionários, dispositivos de convidados) necessitam de uma abordagem diferente. Implemente um portal de integração seguro ou utilize PSKs dinâmicas para estes dispositivos. Para áreas de acesso público em ambientes de Hospitality ou Retail, considere soluções padrão de Guest WiFi com portais cativos que capturem o consentimento e garantam a conformidade com o GDPR.Redundância de Infraestrutura: Implemente múltiplos servidores RADIUS e configure os pontos de acesso para efetuar failover de forma automática. Um único servidor RADIUS é um ponto único de falha crítico - se ficar inoperacional, nenhum dispositivo gerido conseguirá ligar-se à rede.
Resolução de Problemas e Mitigação de Riscos
Modos de Falha Comuns
Expiração de Certificados é a causa mais comum de falhas de EAP-TLS em ambientes de produção. Implemente monitorização e alertas automatizados para os períodos de validade dos certificados a 90, 30 e 7 dias antes da expiração. Isto aplica-se tanto ao certificado do servidor RADIUS como a quaisquer certificados de CA intermédios.
Desvio de Relógio (Clock Skew) é uma causa frequentemente negligenciada de falhas de autenticação intermitentes. O EAP-TLS depende de uma marcação temporal precisa para a validação de certificados. Certifique-se de que o servidor RADIUS, a Autoridade de Certificação e os Chromebooks sincronizam todos via NTP. Um desvio de mais de alguns minutos pode fazer com que certificados válidos sejam rejeitados.
Problemas de Conetividade LDAP: Se estiver a utilizar o Google Secure LDAP, certifique-se de que o servidor RADIUS consegue aceder a ldap.google.com na porta TCP 636 e que o certificado de cliente utilizado para autenticação não expirou nem foi revogado na Google Admin Console.
Aplicação Incorreta de OU: Certifique-se de que o perfil de WiFi e os certificados são aplicados às Unidades Organizacionais corretas na Google Admin Console. Um erro comum é aplicar um perfil de certificado de dispositivo a uma OU de utilizador, o que significa que o certificado nunca é enviado para o dispositivo.
Estratégias de Mitigação de Riscos
Uma implementação faseada é essencial. Nunca implemente uma nova configuração 802.1X para toda a organização de uma só vez. Comece com um pequeno grupo piloto (por exemplo, a equipa de TI) e, em seguida, expanda para um único departamento ou localização antes de uma implementação global. Mantenha um SSID de recurso oculto e fortemente restrito que a equipa de TI possa utilizar para resolver problemas em dispositivos que não consigam autenticar-se via 802.1X.
Para organizações em setores regulados, certifique-se de que a sua implementação 802.1X está alinhada com as estruturas de conformidade relevantes. Em ambientes de Saúde, a segmentação de rede através de atribuição dinâmica de VLAN apoia diretamente os requisitos do HIPAA para isolar sistemas clínicos. No retalho, o PCI DSS exige a separação de rede entre os ambientes de dados de titulares de cartões e as redes corporativas gerais - um requisito que a atribuição dinâmica de VLAN satisfaz de forma elegante.
ROI e Impacto no Negócio
A transição de redes baseadas em PSK para 802.1X integrado com o Google Workspace proporciona benefícios significativos e mensuráveis que justificam o investimento na implementação.
Redução de Custos de Helpdesk: A implementação automatizada de certificados através da Google Admin Console elimina a configuração manual de WiFi em dispositivos geridos. As organizações reportam normalmente uma redução de 40 a 60% nos pedidos de suporte de helpdesk relacionados com WiFi após uma implementação de EAP-TLS, uma vez que não existem palavras-passe para esquecer ou renovar. Postura de Segurança Reforçada: O EAP-TLS elimina a autenticação baseada em palavra-passe, neutralizando ataques de phishing e credential-stuffing. Isto reduz o risco de violações de dados e os custos financeiros e de reputação associados. O custo médio de uma violação de dados em 2024 ultrapassou os 4,8 milhões de dólares - um valor que torna fácil de justificar o investimento numa arquitetura de autenticação adequada.
Processo de Saída Simplificado: Quando um colaborador sai, a desativação da sua conta do Google Workspace revoga imediatamente o seu acesso à WiFi. Não há necessidade de alterar uma PSK partilhada em toda a organização, eliminando a janela de vulnerabilidade que existe entre a saída de um colaborador e a alteração da PSK.
Análise e Informação Melhoradas: Ao associar a autenticação de rede a uma identidade única, os espaços podem tirar partido de plataformas como o Wayfinding e o WiFi Analytics para compreender a utilização do espaço e o comportamento do utilizador com maior precisão. Estes dados podem fundamentar investimentos em infraestruturas e otimizar a utilização do espaço físico em ambientes complexos, como interfaces de Transport ou grandes centros de conferências. Para organizações que procuram compreender como a inteligência de rede apoia objetivos operacionais mais amplos, o artigo Modern Hospitality WiFi Solutions Your Guests Deserve fornece um contexto relevante.
Para as organizações que consideram o contexto mais amplo da arquitetura de rede, o Wireless Access Points Definition Your Ultimate 2026 Guide e o The Core SD WAN Benefits for Modern Businesses oferecem orientações complementares sobre decisões de infraestrutura que sustentam uma implementação de 802.1X bem-sucedida.
Definições Principais
802.1X
Um padrão IEEE para Controle de Acesso à Rede baseado em porta (PNAC). Fornece um mecanismo de autenticação para dispositivos que desejam ligar-se a uma LAN ou WLAN, exigindo que cada dispositivo se autentique antes de lhe ser concedido acesso à rede.
O protocolo fundamental para a segurança de WiFi empresarial, substituindo palavras-passe partilhadas (PSKs) por autenticação individual baseada na identidade. Suportado nativamente por Chromebooks e por todos os pontos de acesso WiFi modernos.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Um método EAP que utiliza PKI (Public Key Infrastructure) para autenticar tanto o cliente como o servidor através de certificados digitais. Não são trocadas palavras-passe durante a autenticação.
O padrão de excelência para a autenticação WiFi de dispositivos geridos. Requer um certificado de cliente no Chromebook (implementado através da Google Admin Console) e um certificado de servidor no servidor RADIUS.
Google Secure LDAP
Um serviço gerido da Google que expõe uma interface LDAP tradicional ao diretório na nuvem do Google Workspace, permitindo que sistemas legados como servidores RADIUS autentiquem utilizadores na plataforma de identidade da Google.
Essencial para organizações que pretendem utilizar as suas credenciais Google para autenticação WiFi 802.1X. Disponível nas licenças Cloud Identity Premium e Google Workspace Enterprise.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Auditoria (AAA) para utilizadores que se ligam a um serviço de rede. Os pontos de acesso comunicam com um servidor RADIUS para verificar as credenciais do utilizador ou dispositivo.
O servidor intermediário que faz a ponte entre os pontos de acesso WiFi e os fornecedores de identidade como o Google Workspace. As implementações comuns incluem o FreeRADIUS, Cisco ISE e Aruba ClearPass.
PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol)
Um método EAP que utiliza um certificado de servidor para criar um túnel TLS seguro, dentro do qual o nome de utilizador e a palavra-passe do utilizador são validados utilizando o protocolo MSCHAPv2.
Uma alternativa comum ao EAP-TLS para ambientes BYOD ou PME onde a implementação de certificados de cliente em cada dispositivo é impraticável. Requer uma validação rigorosa do certificado do servidor para evitar o roubo de credenciais.
Dynamic VLAN Assignment
O processo de colocar um utilizador ou dispositivo numa Virtual Local Area Network (VLAN) específica com base na sua identidade ou pertença a um grupo, determinado durante o processo de autenticação 802.1X através de atributos RADIUS.
Permite aos administradores de rede segmentar o tráfego (por exemplo, mantendo alunos e funcionários em sub-redes diferentes) utilizando um único SSID, com base na pertença a grupos do Google Workspace devolvida através de Secure LDAP.
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo concebido para automatizar a emissão e revogação de certificados digitais em grande escala, commumente utilizado em plataformas MDM e de gestão de dispositivos.
Utilizado em conjunto com a Google Admin Console para enviar automaticamente certificados de cliente para Chromebooks geridos para autenticação EAP-TLS, sem necessidade de instalação manual de certificados.
Evil Twin Attack
Um ponto de acesso WiFi fraudulento que parece ser legítimo ao transmitir o mesmo SSID de uma rede confiável, concebido para intercetar credenciais de utilizador ou tráfego.
A principal ameaça mitigada ao impor uma validação rigorosa do certificado do servidor em configurações 802.1X. Sem a validação do certificado, as credenciais Google de um utilizador PEAP podem ser capturadas por um ponto de acesso nocivo.
WPA3-Enterprise
A mais recente geração do protocolo de segurança WiFi Protected Access para redes empresariais, fornecendo uma encriptação mais forte (mínimo de 192 bits no modo WPA3-Enterprise de 192 bits) e melhor proteção contra ataques de dicionário offline.
O protocolo de segurança recomendado para todas as novas implementações 802.1X. Totalmente suportado por Chromebooks e pontos de acesso modernos, e configurável através do perfil de WiFi da Google Admin Console.
Exemplos Práticos
Um campus universitário com 2000 estudantes precisa de implementar WiFi seguro tanto para Chromebooks de propriedade da universidade (geridos através da Administração do Google) como para dispositivos BYOD de estudantes (telemóveis, computadores portáteis). Utilizam o Google Workspace for Education como o seu único fornecedor de identidade e não possuem Active Directory local.
Para os Chromebooks geridos, a universidade deve implementar EAP-TLS. Configura-se uma PKI baseada na nuvem integrada com o Google Workspace via SCEP. A Consola de Administração do Google envia a CA Raiz, o payload SCEP e o perfil de WiFi (WPA3-Enterprise, EAP-TLS) para as OUs dos Chromebooks. Os dispositivos autenticam-se de forma silenciosa e segura sem qualquer interação do utilizador.
Para os dispositivos BYOD, implementam um portal de integração seguro. Os estudantes ligam-se a um SSID "Onboarding" aberto, autenticam-se através de SSO SAML do Google num captive portal e, em seguida, é-lhes fornecido um certificado exclusivo e específico do dispositivo (ou PSK dinâmica) para o SSID "Campus-Secure" principal. Isto separa o tráfego gerido do não gerido, tirando partido da mesma identidade do Google. O servidor RADIUS utiliza o Google Secure LDAP para validar as credenciais e atribui estudantes e funcionários a VLANs separadas com base na sua pertença a grupos do Google Workspace.
Uma cadeia de retalho com 50 localizações utiliza o Google Workspace. Pretendem fornecer WiFi para funcionários em dispositivos da empresa e um WiFi para convidados separado para os clientes. Atualmente utilizam uma única PSK para os funcionários, que não é alterada há três anos. Sabe-se que um ex-funcionário tem essa PSK.
A cadeia de retalho deve implementar o Google Secure LDAP imediatamente. Implementam um servidor RADIUS central na nuvem, configurado para autenticar no Google Secure LDAP. Na Consola de Administração do Google, criam um perfil de WiFi utilizando PEAP-MSCHAPv2, impondo uma validação rigorosa do certificado do servidor. Os pontos de acesso em todas as 50 localizações apontam para este servidor RADIUS central. Os funcionários ligam-se utilizando as suas credenciais do Google Workspace - sem novas palavras-passe para distribuir.
Para os clientes, implementam uma solução de captive portal separada numa VLAN segregada, que recolhe o consentimento de marketing e garante a conformidade com o GDPR, completamente isolada da rede de funcionários. A conta do Google do ex-funcionário é desativada, revogando imediatamente o seu acesso à rede sem exigir uma rotação de PSK em 50 locais.
Perguntas de Prática
Q1. A sua organização está a implementar o 802.1X em 500 Chromebooks geridos. Pretende o nível mais elevado de segurança e quer evitar que os utilizadores tenham de introduzir uma palavra-passe para se ligarem ao WiFi. Qual o método EAP que deve configurar na Google Admin Console e que componente de infraestrutura adicional deve implementar?
Dica: Qual o método que depende inteiramente de certificados em vez de credenciais, e o que deve ser implementado no dispositivo do cliente?
Ver resposta modelo
EAP-TLS. Requer que um certificado de cliente seja enviado para o Chromebook através da Google Admin Console (utilizando SCEP ou o Google Cloud Certificate Connector) e um certificado de servidor no servidor RADIUS. Isto elimina completamente a autenticação baseada em palavra-passe. A infraestrutura adicional necessária é uma PKI (Autoridade de Certificação) para emitir e gerir os certificados de cliente.
Q2. Configurou o Google Secure LDAP e um servidor FreeRADIUS. Os utilizadores conseguem autenticar-se com sucesso, mas estão todos a ser colocados na mesma VLAN predefinida, quer sejam funcionários ou alunos. Pretende que os funcionários e os alunos fiquem em VLANs separadas. Onde deve ser aplicada esta configuração e que fonte de dados a viabiliza?
Dica: Que componente faz a ponte entre os dados de identidade da Google e o equipamento de rede, e que atributos de protocolo transportam a informação de VLAN?
Ver resposta modelo
O servidor RADIUS deve ser configurado para consultar a pertença a grupos do utilizador a partir do Google Secure LDAP e, em seguida, devolver os atributos RADIUS adequados (especificamente Tunnel-Private-Group-Id e Tunnel-Type) de volta ao Access Point. O Access Point utiliza estes atributos para colocar o cliente na VLAN correta. A fonte de dados que viabiliza isto é a pertença a grupos do Google Workspace, obtida através da consulta ao Secure LDAP.
Q3. Um utilizador reporta que não se consegue ligar à nova rede 802.1X no seu telemóvel Android pessoal (BYOD). É-lhe solicitado um nome de utilizador e palavra-passe (PEAP), mas a ligação falha silenciosamente após a introdução dos mesmos. Os registos do RADIUS mostram que nenhuma tentativa de autenticação foi recebida. Qual é a causa mais provável e como a resolve?
Dica: Pense no que o dispositivo do cliente deve fazer antes de enviar as credenciais do utilizador e que configuração é necessária no dispositivo.
Ver resposta modelo
O dispositivo do cliente está a falhar na validação do certificado do servidor RADIUS. Nas versões modernas do Android, a validação estrita de certificados é obrigatória por predefinição. Se o utilizador não tiver instalado o certificado da Root CA no seu dispositivo, ou se o nome de domínio no certificado do servidor não corresponder ao que o dispositivo espera, o cliente terminará a ligação antes de enviar as credenciais. Resolução: o utilizador deve instalar o certificado da Root CA no seu dispositivo Android e configurar o perfil de WiFi para especificar a CA e o nome de domínio esperado do servidor.
Q4. Uma cadeia de retalho está a ponderar migrar de uma PSK estática para o 802.1X utilizando o Google Secure LDAP. O CFO pede o caso de negócio. Quais são os três argumentos financeiros e operacionais mais convincentes que apresentaria?
Dica: Considere os custos associados à gestão de PSK, o risco de exposição de credenciais e a sobrecarga operacional da gestão de locais distribuídos.
Ver resposta modelo
- Eliminação dos custos de rotação de PSK: Com uma PSK estática, qualquer saída de funcionário exige a rotação da chave em todos os locais - uma operação dispendiosa e disruptiva. Com a autenticação baseada em identidade, a desativação de uma conta Google revoga instantaneamente o acesso em todos os locais. 2. Redução do risco de violação de dados: Uma PSK comprometida concede acesso à rede a qualquer pessoa com a chave. A autenticação baseada em identidade limita a exposição a contas individuais, que podem ser desativadas imediatamente. O custo médio de uma violação de dados ultrapassa os 4,8 milhões de dólares, tornando o investimento na infraestrutura fácil de justificar. 3. Redução da sobrecarga do helpdesk: A gestão automatizada de credenciais através do Google Workspace elimina os pedidos de suporte para reposição de palavras-passe de WiFi e a configuração manual de dispositivos, reduzindo normalmente o volume de helpdesk relacionado com WiFi em 40-60%.
Perguntas frequentes
O Google Workspace pode ser utilizado diretamente como um servidor RADIUS para autenticação WiFi?
O Google Workspace não oferece um endpoint de servidor RADIUS nativo. Para autenticar o WiFi empresarial 802.1X no Google Workspace, as organizações implementam um serviço RADIUS intermediário - como o Purple Cloud RADIUS - que consulta o Google Workspace através do Google Secure LDAP (porta 636 LDAPS) ou emite certificados de cliente 802.1X via SCEP/PKCS. Isto permite que os pontos de acesso e controladores sem fios da Cisco Meraki, HPE Aruba, Ruckus e Ubiquiti UniFi validem credenciais nos diretórios de utilizadores da Google sem necessidade de servidores locais.
Como implementar certificados WiFi 802.1X em Chromebooks através da Google Admin Console?
Para implementar certificados 802.1X em dispositivos ChromeOS, configure um perfil SCEP (Simple Certificate Enrollment Protocol) automatizado na Google Admin Console em Dispositivos > Redes > Certificados. O Google Admin emite um Pedido de Assinatura de Certificado (CSR) com um par de chaves gerado por hardware TPM para uma PKI na Cloud fidedigna. Uma vez assinado pela sua CA emissora, o Google Admin envia um perfil de WiFi gerido em Dispositivos > Redes > WiFi com EAP-TLS e o certificado de cliente implementado para as Unidades Organizacionais de destino.
Qual é a diferença entre EAP-TLS e Google Secure LDAP para autenticação WiFi?
O EAP-TLS é um protocolo 802.1X baseado em certificados, onde os dispositivos se autenticam criptograficamente através de certificados digitais exclusivos armazenados em TPMs de hardware. Não requer a introdução de palavras-passe pelo utilizador e elimina o roubo de credenciais. O Google Secure LDAP, disponível nas edições Enterprise e Education Plus, consulta os serviços de diretório do Google diretamente através da porta TLS 636 utilizando certificados de cliente. Embora o Secure LDAP permita o 802.1X baseado em palavra-passe via PEAP ou EAP-TTLS, o EAP-TLS é o padrão da indústria para Chromebooks geridos devido à segurança superior e ausência de atrito para o utilizador.
Como funciona a atribuição dinâmica de VLAN com o Google Workspace e o Cloud RADIUS?
Quando um Chromebook ou utilizador se autentica, o Cloud RADIUS inspeciona a Unidade Organizacional (OU) do utilizador ou a pertença a um Google Group através de Secure LDAP ou sincronização de diretório. O servidor RADIUS devolve os atributos RFC 2868 e RFC 3580 (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) no pacote Access-Accept. O ponto de acesso sem fios coloca dinamicamente o utilizador na sua sub-rede autorizada - como a VLAN 20 para Funcionários, VLAN 30 para Alunos ou VLAN 40 para Empreiteiros - num único SSID.
O que acontece quando um funcionário ou aluno é suspenso no Google Workspace?
Como o Cloud RADIUS consulta o Google Workspace em tempo real via Secure LDAP ou valida os certificados num respondente OCSP/CRL ativo, a desativação é instantânea. Assim que uma conta de utilizador é suspensa ou movida para uma OU desativada na Consola de Administração do Google, os pedidos subsequentes de nova autenticação 802.1X recebem um RADIUS Access-Reject. Além disso, a Alteração de Autorização dinâmica do RADIUS (CoA, RFC 3576 / RFC 5176) pode terminar imediatamente a sessão sem fios ativa.
Como é que a Purple se integra com ambientes WiFi do Google Workspace e Chromebook?
O Purple Cloud RADIUS liga-se diretamente ao Google Workspace sem necessitar de Active Directory local ou controladores de domínio. A Purple automatiza o fornecimento de certificados SCEP para Chromebooks geridos, faz a ponte com o Google Secure LDAP para autenticação BYOD e fornece atribuição dinâmica de VLAN com base em Google Groups. As equipas de TI ganham visibilidade centralizada, telemetria de afluência de espaços e ativação de rede sem intervenção manual em mais de 80.000 locais em todo o mundo.
Fontes
- Google Workspace Admin Help - Set up Secure LDAP service
- Google Chrome Enterprise Help - Manage certificates on ChromeOS devices
- IETF RFC 5216 - The EAP-TLS Authentication Protocol
- IETF RFC 3580 - IEEE 802.1X RADIUS Usage Guidelines & Dynamic VLANs
- IETF RFC 8894 - Simple Certificate Enrolment Protocol (SCEP)
Continue a ler esta série
Como revogar o acesso WiFi quando um funcionário sai
Este guia mostra às equipas de TI e de operações de locais como remover o acesso WiFi da equipa quando um funcionário sai, sem perturbar o resto da força de trabalho. Compara 802.1X baseado em certificados, iPSK específico de identidade e desprovisionamento gerido por SCIM, fornecendo de seguida um manual para o próprio dia, um método de teste e um modelo de evidência de auditoria.
Secure BYOD WiFi: Integração de certificados Passpoint vs xPSK (iPSK)
Um guia técnico abrangente para equipas de TI sobre como proteger dispositivos não geridos de funcionários e estudantes (BYOD) utilizando certificados Passpoint EAP-TLS com configuração automática (zero-touch) vs xPSK específicos do fabricante (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual é a diferença e qual deve utilizar?
Este guia de referência técnica fornece uma comparação abrangente dos protocolos de segurança WPA2 Personal e WPA2 Enterprise em ambientes de WiFi corporativo. Apresenta as diferenças arquitetónicas, metodologias de implementação e implicações de segurança de cada norma para ajudar os arquitetos de rede e líderes de TI a tomar decisões de implementação informadas.
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.