Autenticación WiFi de Google Workspace: integración de Chromebook y LDAP
Una referencia técnica definitiva para administradores de TI que despliegan WiFi seguro en entornos de Google Workspace. Esta guía abarca el despliegue de certificados 802.1X en Chromebooks gestionados a través de Google Admin Console, la integración de Google Secure LDAP como backend de RADIUS y las decisiones de arquitectura para centros educativos, medios de comunicación y entornos empresariales. Proporciona pasos de implementación prácticos, casos de estudio reales y una comparación directa de los métodos EAP para ayudar a los equipos a pasar de claves PSK compartidas y vulnerables a un control de acceso a la red robusto y basado en la identidad.
Video overview
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad WiFi para empresas →
Resumen ejecutivo
Para los centros corporativos, las instituciones educativas y los proveedores de hostelería estandarizados en Google Workspace, la implementación de una autenticación WiFi segura y fluida ha planteado históricamente un desafío en comparación con los entornos de Microsoft Active Directory. Esta guía detalla la arquitectura y el despliegue de la autenticación WiFi de Google Workspace, centrándose específicamente en el despliegue de certificados Chromebook 802.1X y en la integración de Google Secure LDAP para backends RADIUS.
Los administradores de TI y los arquitectos de red deben equilibrar la seguridad (WPA3-Enterprise, IEEE 802.1X) con las fricciones para el usuario. Mientras que las claves precompartidas (PSK) se ven comprometidas fácilmente y son difíciles de rotar, la autenticación basada en certificados (EAP-TLS) o la autenticación basada en credenciales (PEAP-MSCHAPv2) vinculada directamente a la identidad de Google Workspace del usuario proporciona un control de acceso robusto, una aplicación de políticas granular y un roaming fluido en redes de Guest WiFi y redes corporativas.
Esta referencia técnica describe los pasos exactos para configurar Google Admin Console para la distribución automatizada de certificados, desplegar Google Secure LDAP e integrar estos orígenes de identidad con servidores RADIUS corporativos. Siguiendo estas buenas prácticas independientes del proveedor, las organizaciones pueden mitigar el robo de credenciales, reducir los tiques de soporte y garantizar el cumplimiento de GDPR y PCI-DSS.
Análisis técnico detallado
La arquitectura de la autenticación WiFi de Google Workspace
Autenticar clientes inalámbricos en Google Workspace requiere salvar la distancia entre la identidad nativa de la nube (SAML/OAuth) y los protocolos de red heredados (RADIUS/802.1X). A diferencia de Active Directory, que habla de forma nativa LDAP y se integra a la perfección con Network Policy Server (NPS), Google Workspace requiere una capa intermediaria deliberada.
Existen dos arquitecturas principales para lograr esto:
Arquitectura 1 - Google Secure LDAP (Cloud Identity Premium / Google Workspace Enterprise): Google proporciona una interfaz LDAP gestionada para su directorio en la nube. Su servidor RADIUS (por ejemplo, FreeRADIUS, Cisco ISE, Aruba ClearPass) se conecta de forma segura a ldap.google.com mediante certificados de cliente. Cuando un usuario intenta conectarse a la WiFi, el servidor RADIUS valida sus credenciales frente al servicio LDAP de Google.
Arquitectura 2 - Captive Portals basados en SAML / RadSec: Para escenarios de BYOD (Trae tu propio dispositivo) o de invitados, los usuarios se conectan a una red abierta o PSK, que los redirige a un Captive Portal. El portal autentica al usuario a través del SSO de Google (SAML/OAuth). Una vez autenticado, el sistema puede proporcionar dinámicamente una credencial única (por ejemplo, una PSK dinámica o un certificado temporal) para conexiones posteriores.
Figura 1: El flujo de autenticación 802.1X para entornos de Google Workspace, que muestra el servidor RADIUS como intermediario entre el punto de acceso y Google Secure LDAP.
Tipos de EAP y compatibilidad con Chromebook
Los Chromebooks admiten de forma nativa varios tipos de Protocolo de Autenticación Extensible (EAP) para 802.1X. La elección del tipo de EAP determina el nivel de seguridad y la complejidad del despliegue. Para obtener una visión completa de los fundamentos de 802.1X, consulte 802.1X Authentication: Securing Network Access on Modern Devices.
Figura 2: Una comparación directa de los métodos EAP compatibles con los Chromebooks, que destaca las compensaciones entre seguridad y complejidad.
| Método EAP | Tipo de autenticación | Requiere certificado de cliente | Riesgo de phishing | Recomendado para |
|---|---|---|---|---|
| EAP-TLS | Certificado | Sí | Ninguno | Chromebooks gestionados |
| PEAP-MSCHAPv2 | Contraseña | No | Medio | Despliegues de BYOD / PYME |
| EAP-TTLS | Contraseña | No | Medio | Entornos mixtos |
EAP-TLS (Transport Layer Security): El estándar de oro para WiFi empresarial. Requiere tanto un certificado de servidor (en el servidor RADIUS) como un certificado de cliente (en el Chromebook). Esto elimina la necesidad de contraseñas, mitigando los riesgos de phishing. Google Admin Console puede enviar automáticamente certificados de cliente a Chromebooks gestionados a través de Google Cloud Certificate Connector o integraciones SCEP/EST de terceros.
PEAP-MSCHAPv2 / EAP-TTLS: Estos protocolos utilizan un certificado de servidor para establecer un túnel seguro, dentro del cual se intercambian el nombre de usuario y la contraseña del usuario. Aunque son más fáciles de implementar para dispositivos no gestionados, son vulnerables al robo de credenciales si el dispositivo cliente no valida estrictamente el certificado del servidor.
Al diseñar la red, considere cómo se correlacionan estos eventos de autenticación con sistemas descendentes como las plataformas de WiFi Analytics, que dependen de direcciones MAC estables o nombres de usuario autenticados para rastrear los recorridos de los usuarios y la afluencia.
Google Workspace frente a Microsoft y Okta: una evaluación comparativa
Las organizaciones que evalúan las plataformas de identidad para la autenticación WiFi empresarial deben comprender las ventajas y desventajas inherentes. Microsoft Active Directory sigue siendo la opción integrada de forma más fluida, dada su compatibilidad nativa con LDAP y su estrecha integración con NPS. Okta proporciona una sólida capacidad de RADIUS-as-a-Service a través de su agente RADIUS, lo que elimina la necesidad de una infraestructura RADIUS autogestionada. Google Workspace, a través de Secure LDAP, es una opción sólida pero requiere una arquitectura más deliberada - siempre se necesita un servidor RADIUS intermediario, y el servicio Secure LDAP solo está disponible en las licencias de nivel superior.
| Capacidad | Google Workspace | Microsoft AD/Entra | Okta |
|---|---|---|---|
| Soporte RADIUS Nativo | No (requiere servidor RADIUS) | A través de NPS | A través de agente RADIUS |
| Interfaz LDAP | Google Secure LDAP | LDAP AD Nativo | Agente de interfaz LDAP |
| Soporte EAP-TLS | Sí (a través de integración PKI) | Sí (nativo) | Sí |
| Envío de Certificados a Dispositivos Gestionados | Google Admin Console | Intune / GPO | Integración MDM |
| Requisito de Licencia | Enterprise / Cloud Identity Premium | Incluido en AD | Workforce Identity |
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Guía de implementación
Despliegue de 802.1X en Chromebooks gestionados
El despliegue de WiFi seguro en Chromebooks gestionados implica configurar Google Admin Console para enviar los perfiles de red y certificados necesarios. Esto garantiza que los dispositivos se conecten automáticamente sin la intervención del usuario.
Paso 1: Configurar el servidor RADIUS
Despliegue un servidor RADIUS (por ejemplo, FreeRADIUS) con capacidad para EAP-TLS o PEAP. Instale un certificado de servidor de confianza en el servidor RADIUS. Si utiliza una CA privada, asegúrese de exportar el certificado de la CA raíz para su despliegue en los clientes. Configure el servidor RADIUS para realizar consultas en Google Secure LDAP (si utiliza autenticación basada en credenciales) o validar certificados de cliente contra su CA (si utiliza EAP-TLS).
Paso 2: Configurar Google Secure LDAP (para PEAP/EAP-TTLS)
En Google Admin Console, navegue a Aplicaciones > LDAP. Añada un nuevo cliente LDAP (por ejemplo, "Enterprise RADIUS"). Configure los permisos de acceso (leer información de usuario, verificar contraseñas). Descargue el certificado y la clave de cliente generados. Instale estas credenciales en su servidor RADIUS y configúrelo para conectarse a ldap.google.com:636.
Paso 3: Desplegar certificados en Chromebooks (para EAP-TLS)
En Google Admin Console, navegue a Dispositivos > Redes > Certificados. Suba su certificado de CA raíz y márquelo como una "Autoridad de certificación de confianza". Configure un mecanismo para emitir certificados de cliente a los dispositivos a través de Google Cloud Certificate Connector o un proveedor de PKI basado en la nube que admita la integración SCEP/EST.
Paso 4: Crear el perfil de WiFi en Google Admin Console
Navegue a Dispositivos > Redes > WiFi. Cree un nuevo perfil de red WiFi. Establezca el SSID y seleccione WPA/WPA2/WPA3-Enterprise como tipo de seguridad. Seleccione el tipo de EAP adecuado. Si utiliza EAP-TLS, seleccione el certificado de cliente desplegado. Si utiliza PEAP, configúrelo para que use las credenciales de inicio de sesión del usuario. De manera fundamental, seleccione el certificado de CA raíz de confianza para garantizar que el Chromebook valide el servidor RADIUS. Aplique el perfil a las unidades organizativas (OU) correspondientes.
Buenas prácticas
Validación estricta del certificado del servidor: Obligue siempre a realizar la validación del certificado del servidor en los dispositivos de los clientes. No hacerlo expone a los usuarios a ataques de tipo Evil Twin, en los que un atacante emite el mismo SSID y captura las credenciales. Esta única decisión de configuración marca la diferencia entre un despliegue seguro y uno vulnerable. Para un análisis más detallado de la arquitectura de seguridad 802.1X, consulte Autenticación 802.1X: Asegurar el acceso a la red en dispositivos modernos.
Segmentar redes por rol: Utilice los atributos RADIUS (por ejemplo, Filter-Id, Tunnel-Private-Group-Id) devueltos por Google LDAP para asignar dinámicamente a los usuarios a diferentes VLANs en función de su pertenencia a grupos de Google Workspace (por ejemplo, Personal frente a Estudiantes). Esto limita el movimiento lateral y mejora significativamente la postura de seguridad.
Supervisar y auditar: Revise periódicamente los registros de autenticación de RADIUS y los registros de auditoría de Google Workspace. Integre estos registros en un sistema SIEM para detectar patrones de autenticación anómalos o intentos de fuerza bruta. Considere cómo se alimentan estos datos en plataformas de inteligencia de red más amplias.
Planificar para BYOD: Mientras que los Chromebooks gestionados pueden utilizar EAP-TLS, los dispositivos no gestionados (teléfonos personales del personal, dispositivos de invitados) necesitan un enfoque diferente. Implemente un portal de incorporación seguro o utilice PSKs dinámicas para estos dispositivos. Para las zonas de acceso público en entornos de Hostelería o Comercio minorista, considere soluciones estándar de Guest WiFi con portales cautivos que recojan el consentimiento y garanticen el cumplimiento de la normativa GDPR.
Redundancia de la infraestructura: implemente múltiples servidores RADIUS y configure los puntos de acceso para que realicen una conmutación por error de forma automática. Un único servidor RADIUS representa un punto único de fallo crítico: si se cae, ningún dispositivo gestionado podrá conectarse a la red.
Resolución de problemas y mitigación de riesgos
Modos de fallo comunes
La expiración del certificado es la causa más común de fallo de EAP-TLS en entornos de producción. Implemente una monitorización y alertas automatizadas para los periodos de validez de los certificados a los 90, 30 y 7 días antes de su expiración. Esto se aplica tanto al certificado del servidor RADIUS como a cualquier certificado de CA intermedia.
La desviación del reloj es una causa de fallos de autenticación intermitentes que se suele pasar por alto. EAP-TLS depende de un cronometraje preciso para la validación de certificados. Asegúrese de que el servidor RADIUS, la entidad de certificación y los Chromebooks se sincronicen mediante NTP. Una desviación de más de unos pocos minutos puede provocar el rechazo de certificados válidos.
Problemas de conectividad LDAP: si utiliza Google Secure LDAP, asegúrese de que el servidor RADIUS pueda comunicarse con ldap.google.com en el puerto TCP 636 y de que el certificado de cliente utilizado para la autenticación no haya expirado ni haya sido revocado en la consola de administración de Google.
Aplicación incorrecta de las OU: asegúrese de que el perfil de WiFi y los certificados se apliquen a las unidades organizativas correctas en la consola de administración de Google. Un error común es aplicar un perfil de certificado de dispositivo a una OU de usuario, lo que significa que el certificado nunca se envía al dispositivo.
Estrategias de mitigación de riesgos
Es fundamental realizar un despliegue progresivo. Nunca despliegue una nueva configuración de 802.1X en toda la organización a la vez. Comience con un pequeño grupo piloto (por ejemplo, el equipo de TI), luego amplíelo a un solo departamento o ubicación antes de realizar un despliegue global. Mantenga un SSID de respaldo oculto y altamente restringido que el personal de TI pueda utilizar para solucionar problemas de los dispositivos que no logren autenticarse a través de 802.1X.
Para las organizaciones de sectores regulados, asegúrese de que su despliegue de 802.1X se alinee con los marcos de cumplimiento pertinentes. En entornos de salud, la segmentación de red mediante la asignación dinámica de VLAN respalda directamente los requisitos de HIPAA para aislar los sistemas clínicos. En el sector minorista, PCI-DSS exige la separación de red entre los entornos de datos de los titulares de tarjetas y las redes corporativas generales, un requisito que la asignación dinámica de VLAN satisface de manera elegante.
Retorno de la inversión e impacto empresarial
La transición de redes basadas en PSK a 802.1X integrado con Google Workspace ofrece beneficios significativos y mensurables que justifican la inversión en la implementación.
Reducción de la carga de trabajo del servicio de asistencia: el despliegue automatizado de certificados a través de la consola de administración de Google elimina la configuración manual de WiFi en los dispositivos gestionados. Las organizaciones suelen reportar una reducción del 40 al 60 % en los tickets de soporte relacionados con WiFi tras el despliegue de EAP-TLS, ya que no hay contraseñas que olvidar o renovar.
Postura de seguridad mejorada: EAP-TLS elimina la autenticación basada en contraseñas, neutralizando los ataques de phishing y de relleno de credenciales. Esto reduce el riesgo de brechas de datos y los costes financieros y de reputación asociados. El coste medio de una brecha de datos en 2024 superó los 4,8 millones de dólares - una cifra que hace que la inversión en una arquitectura de autenticación adecuada sea fácil de justificar.
Bajas de empleados optimizadas: Cuando un empleado deja la empresa, al desactivar su cuenta de Google Workspace se revoca inmediatamente su acceso a la WiFi. No es necesario cambiar una PSK compartida en toda la organización, lo que elimina el periodo de vulnerabilidad que existe entre la salida de un empleado y el cambio de la PSK.
Análisis e inteligencia mejorados: Al vincular la autenticación de red a una identidad única, los establecimientos pueden aprovechar plataformas como Wayfinding y WiFi Analytics para comprender la utilización del espacio y el comportamiento del usuario con mayor precisión. Estos datos pueden orientar las inversiones en infraestructura y optimizar el uso del espacio físico en entornos complejos como los centros de Transport o los grandes centros de conferencias. Para las organizaciones que deseen explorar cómo la inteligencia de red respalda unos objetivos operativos más amplios, el artículo Modern Hospitality WiFi Solutions Your Guests Deserve ofrece un contexto relevante.
Para las organizaciones que estén considerando el contexto más amplio de la arquitectura de red, las guías Wireless Access Points Definition Your Ultimate 2026 Guide y The Core SD WAN Benefits for Modern Businesses proporcionan información complementaria sobre las decisiones de infraestructura que sustentan un despliegue de 802.1X exitoso.
Definiciones clave
802.1X
Un estándar de IEEE para el Control de Acceso a Redes Basado en Puertos (PNAC). Proporciona un mecanismo de autenticación para los dispositivos que desean conectarse a una LAN o WLAN, requiriendo que cada dispositivo se autentique antes de que se le conceda acceso a la red.
El protocolo fundamental para la seguridad WiFi empresarial, que sustituye las contraseñas compartidas (PSK) por una autenticación individual basada en la identidad. Es compatible de forma nativa con Chromebooks y con todos los puntos de acceso WiFi modernos.
EAP-TLS (Protocolo de Autenticación Extensible - Seguridad de la Capa de Transporte)
Un método EAP que utiliza PKI (Infraestructura de Clave Pública) para autenticar tanto al cliente como al servidor mediante certificados digitales. No se intercambian contraseñas durante la autenticación.
El estándar de oro para la autenticación WiFi de dispositivos gestionados. Requiere un certificado de cliente en el Chromebook (desplegado a través de Google Admin Console) y un certificado de servidor en el servidor RADIUS.
Google Secure LDAP
Un servicio gestionado de Google que expone una interfaz LDAP tradicional al directorio en la nube de Google Workspace, lo que permite a los sistemas heredados como los servidores RADIUS autenticar a los usuarios frente a la plataforma de identidad de Google.
Esencial para organizaciones que desean utilizar sus credenciales de Google para la autenticación WiFi 802.1X. Disponible en las licencias Cloud Identity Premium y Google Workspace Enterprise.
RADIUS (Servicio de Autenticación de Marcación Telefónica de Usuario Único)
Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan a un servicio de red. El punto de acceso se comunica con un servidor RADIUS para verificar las credenciales del usuario o del dispositivo.
El servidor intermediario que salva la distancia entre los puntos de acceso WiFi y los proveedores de identidad como Google Workspace. Las implementaciones habituales incluyen FreeRADIUS, Cisco ISE y Aruba ClearPass.
PEAP-MSCHAPv2 (Protocolo de Autenticación Extensible Protegido)
Un método EAP que utiliza un certificado de servidor para crear un túnel TLS seguro, dentro del cual se validan el nombre de usuario y la contraseña del usuario utilizando el protocolo MSCHAPv2.
Una alternativa común a EAP-TLS para entornos BYOD o pymes donde resulta inviable desplegar certificados de cliente en cada dispositivo. Requiere una validación estricta del certificado del servidor para evitar el robo de credenciales.
Asignación dinámica de VLAN
El proceso de ubicar a un usuario o dispositivo en una red de área local virtual (VLAN) específica en función de su identidad o pertenencia a un grupo, determinado durante el proceso de autenticación 802.1X mediante atributos de RADIUS.
Permite a los administradores de red segmentar el tráfico (por ejemplo, manteniendo a alumnos y personal en subredes diferentes) utilizando un único SSID, basándose en la pertenencia a grupos de Google Workspace devuelta a través de Secure LDAP.
SCEP (Protocolo de Inscripción de Certificados Simple)
Un protocolo diseñado para automatizar la emisión y revocación de certificados digitales a gran escala, utilizado comúnmente en plataformas MDM y de gestión de dispositivos.
Se utiliza junto con Google Admin Console para distribuir automáticamente certificados de cliente a Chromebooks gestionados para la autenticación EAP-TLS, sin necesidad de realizar una instalación manual de certificados.
Ataque de gemelo malvado
Un punto de acceso WiFi fraudulento que parece legítimo al transmitir el mismo SSID que una red de confianza, diseñado para interceptar las credenciales de usuario o el tráfico.
La principal amenaza que se mitiga al exigir una validación estricta del certificado del servidor en las configuraciones 802.1X. Sin la validación del certificado, un punto de acceso no autorizado puede capturar las credenciales de Google de un usuario de PEAP.
WPA3-Enterprise
La última generación del protocolo de seguridad WiFi Protected Access para redes empresariales, que ofrece un cifrado más sólido (mínimo de 192 bits en el modo WPA3-Enterprise de 192 bits) y una mayor protección contra los ataques de diccionario sin conexión.
El protocolo de seguridad recomendado para todas las nuevas implementaciones de 802.1X. Es totalmente compatible con los Chromebooks y puntos de acceso modernos, y se puede configurar a través del perfil WiFi de Google Admin Console.
Ejemplos prácticos
Un campus universitario de 2000 estudiantes necesita desplegar WiFi seguro tanto para los Chromebooks propiedad de la universidad (gestionados a través de Google Admin) como para los dispositivos BYOD de los estudiantes (teléfonos, portátiles). Utilizan Google Workspace for Education como su único proveedor de identidad y no disponen de Active Directory local.
Para los Chromebooks gestionados, la universidad debe desplegar EAP-TLS. Configuran una PKI basada en la nube integrada con Google Workspace mediante SCEP. La Google Admin Console envía la CA raíz, la carga útil de SCEP y el perfil de WiFi (WPA3-Enterprise, EAP-TLS) a las OU de Chromebook. Los dispositivos se autentican de forma silenciosa y segura sin ninguna interacción del usuario.
Para los dispositivos BYOD, despliegan un portal de incorporación seguro. Los estudiantes se conectan a un SSID de "Incorporación" abierto, se autentican a través de Google SAML SSO en un Captive Portal y luego se les proporciona un certificado único y específico para el dispositivo (o una PSK dinámica) para el SSID principal "Campus-Secure". Esto separa el tráfico gestionado del no gestionado al tiempo que aprovecha la misma identidad de Google. El servidor RADIUS utiliza Google Secure LDAP para validar las credenciales y asigna a los estudiantes y al personal a VLAN distintas en función de su pertenencia a grupos de Google Workspace.
Una cadena de tiendas con 50 ubicaciones utiliza Google Workspace. Quieren proporcionar WiFi para el personal en los dispositivos propiedad de la empresa y un WiFi de invitados independiente para los clientes. Actualmente utilizan una única PSK para el personal, que no se ha cambiado en tres años. Se sabe que un antiguo empleado tiene la PSK.
La cadena de tiendas debe implementar Google Secure LDAP de inmediato. Despliegan un servidor RADIUS central en la nube, configurado para autenticarse contra Google Secure LDAP. En la Google Admin Console, crean un perfil de WiFi utilizando PEAP-MSCHAPv2, aplicando una validación estricta del certificado del servidor. Los puntos de acceso de las 50 ubicaciones apuntan a este servidor RADIUS central. El personal se conecta utilizando sus credenciales de Google Workspace, sin nuevas contraseñas que distribuir.
Para los clientes, despliegan una solución de Captive Portal independiente en una VLAN segregada, que recopila el consentimiento de marketing y garantiza el cumplimiento del GDPR, completamente aislada de la red del personal. La cuenta de Google del antiguo empleado se deshabilita, lo que revoca inmediatamente su acceso a la red sin necesidad de realizar una rotación de PSK en las 50 ubicaciones.
Preguntas de práctica
Q1. Su organización está implementando 802.1X en 500 Chromebooks gestionados. Desea el nivel más alto de seguridad y quiere evitar que los usuarios tengan que escribir una contraseña para conectarse a la WiFi. ¿Qué método EAP debería configurar en la consola de administración de Google y qué componente de infraestructura adicional debe implementar?
Sugerencia: ¿Qué método depende exclusivamente de certificados en lugar de credenciales, y qué debe desplegarse en el dispositivo cliente?
Ver respuesta modelo
EAP-TLS. Requiere que se envíe un certificado de cliente al Chromebook a través de la consola de administración de Google (mediante SCEP o Google Cloud Certificate Connector) y un certificado de servidor en el servidor RADIUS. Esto elimina por completo la autenticación basada en contraseñas. La infraestructura adicional requerida es una PKI (Autoridad de Certificación) para emitir y gestionar los certificados de cliente.
Q2. Ha configurado Google Secure LDAP y un servidor FreeRADIUS. Los usuarios se autentican correctamente, pero todos se ubican en la misma VLAN predeterminada, independientemente de si son personal o estudiantes. Desea que el personal y los estudiantes estén en VLANs separadas. ¿Dónde debe aplicarse esta configuración y qué fuente de datos la habilita?
Sugerencia: ¿Qué componente tiende un puente entre los datos de identidad de Google y el equipamiento de red, y qué atributos de protocolo transportan la información de la VLAN?
Ver respuesta modelo
El servidor RADIUS debe configurarse para consultar la pertenencia al grupo del usuario desde Google Secure LDAP y luego devolver los atributos RADIUS adecuados (específicamente Tunnel-Private-Group-Id y Tunnel-Type) de vuelta al punto de acceso. El punto de acceso utiliza estos atributos para ubicar al cliente en la VLAN correcta. La fuente de datos que habilita esto es la pertenencia al grupo de Google Workspace, que se recupera mediante la consulta de Secure LDAP.
Q3. Un usuario informa que no puede conectarse a la nueva red 802.1X en su teléfono Android BYOD. Se le solicitan un nombre de usuario y una contraseña (PEAP), pero la conexión falla silenciosamente tras introducirlos. Los registros de RADIUS muestran que no se recibió ningún intento de autenticación. ¿Cuál es la causa más probable y cómo se resuelve?
Sugerencia: Piense en lo que debe hacer el dispositivo cliente antes de enviar las credenciales del usuario y qué configuración se requiere en el dispositivo.
Ver respuesta modelo
El dispositivo cliente no puede validar el certificado del servidor RADIUS. En las versiones modernas de Android, se aplica una validación estricta de certificados de forma predeterminada. Si el usuario no ha instalado el certificado de la CA raíz en su dispositivo, o si el nombre de dominio en el certificado del servidor no coincide con lo que el dispositivo espera, el cliente interrumpirá la conexión antes de enviar las credenciales. Resolución: el usuario debe instalar el certificado de la CA raíz en su dispositivo Android y configurar el perfil de WiFi para especificar la CA y el nombre de dominio del servidor esperado.
Q4. Una cadena de tiendas minoristas está considerando pasar de una PSK estática a 802.1X utilizando Google Secure LDAP. El CFO solicita el caso de negocio. ¿Cuáles son los tres argumentos financieros y operativos más convincentes que presentaría?
Sugerencia: Considere los costes asociados a la gestión de PSK, el riesgo de exposición de credenciales y la sobrecarga operativa de la gestión de sedes distribuidas.
Ver respuesta modelo
- Eliminación de los costes de rotación de PSK: con una PSK estática, cualquier salida de personal requiere una rotación de claves en todas las sedes - una operación costosa e interruptiva. Con la autenticación basada en identidad, la desactivación de una cuenta de Google revoca instantáneamente el acceso en todas las ubicaciones. 2. Menor riesgo de brechas de seguridad: una PSK comprometida otorga acceso a la red a cualquiera que tenga la clave. La autenticación basada en identidad limita la exposición a cuentas individuales, que pueden desactivarse de inmediato. El coste medio de una brecha de datos supera los 4,8 millones de dólares, lo que justifica fácilmente la inversión en infraestructura. 3. Reducción de la sobrecarga del soporte técnico: la gestión automatizada de credenciales a través de Google Workspace elimina los tiques de restablecimiento de contraseñas relacionados con la WiFi y la configuración manual de dispositivos, lo que suele reducir el volumen de soporte de WiFi entre un 40 % y un 60 %.
Preguntas frecuentes
¿Se puede utilizar Google Workspace directamente como un servidor RADIUS para la autenticación WiFi?
Google Workspace no ofrece un endpoint de servidor RADIUS nativo. Para autenticar el WiFi 802.1X de nivel empresarial con Google Workspace, las organizaciones despliegan un servicio RADIUS intermediario - como Purple Cloud RADIUS - que consulta a Google Workspace a través de Google Secure LDAP (puerto 636 LDAPS) o emite certificados de cliente 802.1X a través de SCEP/PKCS. Esto permite que los puntos de acceso y controladores inalámbricos de Cisco Meraki, HPE Aruba, Ruckus y Ubiquiti UniFi validen las credenciales con los directorios de usuarios de Google sin necesidad de servidores locales.
¿Cómo se despliegan los certificados WiFi 802.1X en Chromebooks a través de Google Admin Console?
Para desplegar certificados 802.1X en dispositivos ChromeOS, configure un perfil SCEP (Simple Certificate Enrollment Protocol) automatizado en Google Admin Console, dentro de Dispositivos > Redes > Certificados. Google Admin emite una solicitud de firma de certificado (CSR) con un par de claves generado por el chip TPM del hardware a una PKI en la nube de confianza. Una vez firmado por su CA emisora, Google Admin envía un perfil WiFi gestionado bajo Dispositivos > Redes > WiFi con EAP-TLS y el certificado de cliente desplegado a las unidades organizativas de destino.
¿Cuál es la diferencia entre EAP-TLS y Google Secure LDAP para la autenticación WiFi?
EAP-TLS es un protocolo 802.1X basado en certificados donde los dispositivos se autentican criptográficamente utilizando certificados digitales únicos almacenados en los TPM de hardware. No requiere que el usuario introduzca ninguna contraseña y elimina el robo de credenciales. Google Secure LDAP, disponible en las ediciones Enterprise y Education Plus, consulta los servicios de directorio de Google directamente a través del puerto TLS 636 utilizando certificados de cliente. Aunque Secure LDAP permite la autenticación 802.1X basada en contraseñas a través de PEAP o EAP-TTLS, EAP-TLS es el estándar de la industria para Chromebooks gestionados debido a su seguridad superior y a que no requiere fricción por parte del usuario.
¿Cómo funciona la asignación dinámica de VLAN con Google Workspace y Cloud RADIUS?
Cuando un Chromebook o un usuario se autentica, Cloud RADIUS inspecciona la Unidad Organizativa (OU) del usuario o la pertenencia al Grupo de Google a través de Secure LDAP o de la sincronización de directorios. El servidor RADIUS devuelve los atributos RFC 2868 y RFC 3580 (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) en el paquete Access-Accept. El punto de acceso inalámbrico ubica dinámicamente al usuario en su subred autorizada, como VLAN de personal 20, VLAN de estudiantes 30 o VLAN de contratistas 40, dentro de un único SSID.
¿Qué ocurre cuando se suspende a un empleado o estudiante en Google Workspace?
Dado que Cloud RADIUS consulta Google Workspace en tiempo real a través de Secure LDAP o valida los certificados contra un respondedor OCSP/CRL activo, la baja del usuario es instantánea. Tan pronto como se suspende una cuenta de usuario o se mueve a una OU deshabilitada en la consola de administración de Google, las solicitudes posteriores de autenticación 802.1X reciben un RADIUS Access-Reject. Además, el Cambio de Autorización dinámico de RADIUS (CoA, RFC 3576 / RFC 5176) puede terminar de inmediato la sesión inalámbrica activa.
¿Cómo se integra Purple con los entornos de WiFi de Google Workspace y Chromebook?
Purple Cloud RADIUS se conecta directamente a Google Workspace sin necesidad de disponer de un Active Directory local o controladores de dominio. Purple automatiza el aprovisionamiento de certificados SCEP para Chromebooks gestionados, sirve de puente con Google Secure LDAP para la autenticación BYOD y proporciona asignación dinámica de VLAN basada en Grupos de Google. Los equipos de TI obtienen visibilidad centralizada, telemetría de afluencia de las sedes y un aprovisionamiento de red sin intervención en más de 80.000 sedes de todo el mundo.
Fuentes
- 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)
Continúe leyendo esta serie
Cómo revocar el acceso WiFi cuando un empleado se va
Esta guía muestra a los equipos de TI y operaciones cómo eliminar el acceso a Staff WiFi cuando un empleado se marcha sin interrumpir al resto del personal. Compara el aprovisionamiento mediante 802.1X basado en certificados, iPSK específicos de identidad y la desprogramación basada en SCIM, para luego ofrecer un manual del mismo día, un método de prueba y un modelo de auditoría.
WiFi seguro para BYOD: Incorporación de certificados Passpoint frente a xPSK (iPSK)
Una guía técnica exhaustiva para equipos de TI sobre cómo proteger los dispositivos no gestionados de empleados y estudiantes (BYOD) mediante certificados EAP-TLS de Passpoint sin intervención frente a xPSK específico de cada fabricante (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: ¿cuál es la diferencia y cuál debería utilizar?
Esta guía de referencia técnica ofrece una comparación detallada de los protocolos de seguridad WPA2 Personal y WPA2 Enterprise en entornos de WiFi corporativos. Describe las diferencias de arquitectura, las metodologías de despliegue y las implicaciones de seguridad de cada estándar para ayudar a los arquitectos de red y responsables de TI a tomar decisiones de implantación fundamentadas.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.