Autenticación de WiFi con Google Workspace: Integración de Chromebook y LDAP
Una referencia técnica definitiva para administradores de TI que implementan WiFi seguro en entornos de Google Workspace. Esta guía abarca la implementación de certificados 802.1X en Chromebooks administrados a través de la consola de administración de Google, la integración de Google Secure LDAP como backend de RADIUS y las decisiones de arquitectura para entornos educativos, de medios de comunicación y empresariales. Proporciona pasos de implementación prácticos, casos de estudio del mundo real y una comparación directa de los métodos EAP para ayudar a los equipos a migrar de claves PSK compartidas vulnerables a un control de acceso a la red robusto y basado en la identidad.
Video overview
Escucha esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de Seguridad WiFi para Empresas →
Resumen ejecutivo
Para los entornos empresariales, instituciones educativas y proveedores de hospitalidad estandarizados en Google Workspace, implementar una autenticación WiFi segura y sin fricciones ha presentado 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, enfocándose específicamente en el despliegue de certificados Chromebook 802.1X y la integración de Google Secure LDAP para backends de RADIUS.
Los administradores de TI y arquitectos de red deben equilibrar la seguridad (WPA3-Enterprise, IEEE 802.1X) con la fricción del usuario. Mientras que las claves precompartidas (PSK) se comprometen 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 de un usuario proporciona un control de acceso robusto, aplicación de políticas granulares y un roaming fluido a través de redes de WiFi para invitados y 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 estas fuentes de identidad con servidores RADIUS empresariales. Al seguir estas mejores prácticas neutrales del proveedor, las organizaciones pueden mitigar el robo de credenciales, reducir los tickets de soporte técnico y garantizar el cumplimiento con GDPR y PCI-DSS.
Technical Deep-Dive
La arquitectura de la autenticación de WiFi de Google Workspace
La autenticación de clientes inalámbricos contra Google Workspace requiere cerrar la brecha 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 LDAP de forma nativa y se integra perfectamente con Network Policy Server (NPS), Google Workspace requiere una capa intermedia deliberada.
Existen dos arquitecturas principales para lograr esto:
Arquitectura 1 - Google Secure LDAP (Cloud Identity Premium / Google Workspace Enterprise): Google proporciona una interfaz LDAP administrada 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 - Portales cautivos 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 de Google SSO (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 al servidor RADIUS como el 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 la postura de seguridad y la complejidad de la implementación. Para obtener una descripción general completa de los fundamentos de 802.1X, consulte Autenticación 802.1X: Asegurando el acceso a la red en dispositivos modernos.
Figura 2: Una comparación directa de los métodos EAP compatibles con 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 administrados |
| PEAP-MSCHAPv2 | Contraseña | No | Medio | Implementaciones de BYOD / PyMEs |
| 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 la Chromebook). Esto elimina la necesidad de contraseñas, mitigando los riesgos de phishing. Google Admin Console puede enviar automáticamente certificados de cliente a las Chromebooks administradas 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 administrados, 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 estos eventos de autenticación se correlacionan con los sistemas descendentes como las plataformas de WiFi Analytics, que dependen de direcciones MAC estables o nombres de usuario autenticados para rastrear el recorrido de los usuarios y la afluencia de personas.
Google Workspace vs. 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 de integración 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 autoadministrada. 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 sólo está disponible en licencias de nivel superior.
| Capacidad | Google Workspace | Microsoft AD/Entra | Okta |
|---|---|---|---|
| Soporte nativo de RADIUS | 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 administrados | 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 gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Guía de implementación
Implementación de 802.1X en Chromebooks administradas
La implementación de WiFi seguro en Chromebooks administradas 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
Implemente un servidor RADIUS (por ejemplo, FreeRADIUS) con capacidad para EAP-TLS o PEAP. Instale un certificado de servidor confiable en el servidor RADIUS. Si utiliza una CA privada, asegúrese de exportar el certificado de la CA raíz para implementarlo en los clientes. Configure el servidor RADIUS para consultar Google Secure LDAP (si utiliza autenticación basada en credenciales) o para validar los certificados de cliente con su CA (si utiliza EAP-TLS).
Paso 2: Configurar Google Secure LDAP (Para PEAP/EAP-TTLS)
En la Consola de Administración de Google, navega a Apps > LDAP. Agrega un nuevo cliente LDAP (por ejemplo, "Enterprise RADIUS"). Configura los permisos de acceso (leer información de usuario, verificar contraseñas). Descarga el certificado y la clave de cliente generados. Instala estas credenciales en tu servidor RADIUS y configúralo para conectarse a ldap.google.com:636.
Paso 3: Desplegar Certificados en Chromebooks (Para EAP-TLS)
En la Consola de Administración de Google, navega a Dispositivos > Redes > Certificados. Sube tu certificado Root CA y márcalo como "Autoridad de Certificación de Confianza". Configura 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 sea compatible con la integración SCEP/EST.
Paso 4: Crear el Perfil de WiFi en la Consola de Administración de Google
Navega a Dispositivos > Redes > WiFi. Crea un nuevo perfil de red WiFi. Configura el SSID y selecciona WPA/WPA2/WPA3-Enterprise como el Tipo de Seguridad. Selecciona el tipo de EAP correspondiente. Si utilizas EAP-TLS, selecciona el certificado de cliente desplegado. Si utilizas PEAP, configúralo para usar las credenciales de inicio de sesión del usuario. Es fundamental que selecciones el certificado Root CA de confianza para asegurar que el Chromebook valide el servidor RADIUS. Aplica el perfil a las Unidades Organizativas (OU) correspondientes.
Mejores Prácticas
Validación Estricta del Certificado del Servidor: Exige siempre la validación del certificado del servidor en los dispositivos cliente. No hacerlo expone a los usuarios a ataques Evil Twin, donde un atacante transmite 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 profundo de la arquitectura de seguridad de 802.1X, consulta Autenticación 802.1X: Asegurando el Acceso a la Red en Dispositivos Modernos.
Segmentar Redes por Rol: Utiliza los atributos RADIUS (por ejemplo, Filter-Id, Tunnel-Private-Group-Id) devuelvos por Google LDAP para asignar dinámicamente a los usuarios a diferentes VLANs según 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.
Monitorear y Auditar: Revisa periódicamente los registros de autenticación RADIUS y los registros de auditoría de Google Workspace. Integra estos registros en un sistema SIEM para detectar patrones de autenticación anómalos o intentos de fuerza bruta. Considera cómo se alimentan estos datos en plataformas de inteligencia de red más amplias.
Planificar para BYOD: Mientras que los Chromebooks gestionados pueden usar EAP-TLS, los dispositivos no gestionados (teléfonos personales del personal, dispositivos de invitados) necesitan un enfoque diferente. Implementa un portal de incorporación seguro o utiliza PSKs dinámicas para estos dispositivos. Para áreas de acceso público en entornos de Hospitality o Retail, considera soluciones estándar de Guest WiFi con portales cautivos que capturen el consentimiento y garanticen el cumplimiento de GDPR.Redundancia de 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 crítico de falla; si se cae, ningún dispositivo gestionado podrá conectarse a la red.
Solución de problemas y mitigación de riesgos
Modos de falla comunes
La expiración de certificados es la causa más común de fallas de EAP-TLS en entornos de producción. Implemente un sistema automatizado de monitoreo y alertas para los periodos de validez de los certificados a los 90, 30 y 7 días antes de su vencimiento. Esto aplica tanto al certificado del servidor RADIUS como a cualquier certificado de CA intermedia.
El desajuste de reloj es una causa de fallas de autenticación intermitentes que se pasa por alto con frecuencia. EAP-TLS depende de un registro de tiempo preciso para la validación de certificados. Asegúrese de que el servidor RADIUS, la Autoridad de Certificación y los Chromebooks se sincronicen mediante NTP. Un desajuste de más de unos pocos minutos puede provocar que se rechacen 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 OU: Asegúrese de que el perfil de WiFi y los certificados se apliquen a las Unidades Organizacionales 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 enviará al dispositivo.
Estrategias de mitigación de riesgos
Un despliegue gradual es esencial. Nunca implemente una nueva configuración 802.1X en toda la organización a la vez. Comience con un pequeño grupo piloto (por ejemplo, el equipo de TI), luego extiéndalo a un solo departamento o ubicación antes de realizar un lanzamiento global. Mantenga un SSID de respaldo oculto y altamente restringido que el personal de TI pueda usar para solucionar problemas de dispositivos que no logren autenticarse a través de 802.1X.
Para las organizaciones en sectores regulados, asegúrese de que su implementación de 802.1X se alinee con los marcos de cumplimiento pertinentes. En entornos de atención médica, 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 comercio minorista, PCI-DSS exige la separación de red entre los entornos de datos de titulares de tarjetas y las redes corporativas generales, un requisito que la asignación dinámica de VLAN cumple de manera elegante.
ROI e impacto empresarial
La transición de redes basadas en PSK a 802.1X integrado con Google Workspace ofrece beneficios significativos y medibles que justifican la inversión en la implementación.
Reducción de la carga de trabajo de soporte técnico: 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 reportes de soporte técnico relacionados con WiFi tras el lanzamiento de EAP-TLS, ya que no hay contraseñas que olvidar o actualizar. Postura de seguridad mejorada: EAP-TLS elimina la autenticación basada en contraseñas, neutralizando los ataques de phishing y de relleno de credenciales (credential stuffing). Esto reduce el riesgo de filtraciones de datos y los costos financieros y de reputación asociados. El costo promedio de una filtración 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 personal optimizadas: Cuando un empleado se va, inhabilitar su cuenta de Google Workspace revoca inmediatamente su acceso a la WiFi. No hay necesidad de rotar una PSK compartida en toda la organización, eliminando la ventana de vulnerabilidad que existe entre la salida de un empleado y la rotación de la PSK.
Análisis e inteligencia mejorados: Al vincular la autenticación de la 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 centros de Transport o grandes centros de convenciones. Para las organizaciones que exploran cómo la inteligencia de red respalda objetivos operativos más amplios, el artículo Modern Hospitality WiFi Solutions Your Guests Deserve proporciona el contexto relevante.
Para las organizaciones que consideran 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 brindan orientación complementaria sobre las decisiones de infraestructura que sustentan una implementación exitosa de 802.1X.
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 otorgue acceso a la red.
El protocolo fundamental para la seguridad WiFi empresarial, que reemplaza 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 (Extensible Authentication Protocol - Transport Layer Security)
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.
La regla 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 contra la plataforma de identidad de Google.
Esencial para las organizaciones que desean utilizar sus credenciales de Google para la autenticación WiFi 802.1X. Está disponible en las licencias Cloud Identity Premium y Google Workspace Enterprise.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilización (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 cierra la brecha entre los puntos de acceso WiFi y los proveedores de identidad como Google Workspace. Las implementaciones comunes incluyen FreeRADIUS, Cisco ISE y Aruba ClearPass.
PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol)
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 desplegar certificados de cliente en cada dispositivo no es práctico. Requiere una validación estricta del certificado del servidor para evitar el robo de credenciales.
Asignación Dinámica de VLAN
El proceso de colocar 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 a través de atributos RADIUS.
Permite a los administradores de red segmentar el tráfico (por ejemplo, mantener a los estudiantes y al personal en diferentes subredes) utilizando un solo SSID, según la pertenencia a grupos de Google Workspace devuelta a través de Secure LDAP.
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo diseñado para automatizar la emisión y revocación de certificados digitales a escala, comúnmente utilizado en plataformas MDM y de gestión de dispositivos.
Se utiliza en conjunto con Google Admin Console para distribuir automáticamente certificados de cliente a Chromebooks gestionados para la autenticación EAP-TLS, sin requerir una instalación manual de certificados.
Ataque de Gemelo Malvado
Un punto de acceso WiFi fraudulento que parece ser legítimo al transmitir el mismo SSID que una red de confianza, diseñado para interceptar credenciales o tráfico de los usuarios.
La principal amenaza que se mitiga al aplicar una validación estricta del certificado del servidor en las configuraciones 802.1X. Sin la validación de certificados, 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 proporciona un cifrado más sólido (mínimo de 192 bits en el modo WPA3-Enterprise de 192 bits) y una mejor protección contra ataques de diccionario fuera de línea.
El protocolo de seguridad recomendado para todos los nuevos despliegues de 802.1X. Totalmente compatible con Chromebooks y puntos de acceso modernos, y configurable a través del perfil WiFi de Google Admin Console.
Ejemplos resueltos
Un campus universitario de 2,000 estudiantes necesita implementar WiFi seguro tanto para Chromebooks propiedad de la universidad (administrados a través de la administración de Google) como para dispositivos BYOD de los estudiantes (teléfonos, laptops). Utilizan Google Workspace for Education como su único proveedor de identidad y no tienen Active Directory local.
Para los Chromebooks administrados, la universidad debe implementar EAP-TLS. Configuran una PKI basada en la nube integrada con Google Workspace a través de SCEP. La consola de administración de Google envía la CA raíz, la carga útil SCEP y el perfil 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, implementan 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 específico para el dispositivo (o una PSK dinámica) para el SSID principal "Campus-Secure". Esto separa el tráfico administrado y no administrado mientras se 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 VLANs separadas según su membresía de grupo de Google Workspace.
Una cadena de tiendas minoristas con 50 ubicaciones utiliza Google Workspace. Quieren proporcionar WiFi para el personal en dispositivos propiedad de la empresa y un WiFi de invitados separado para los clientes. Actualmente utilizan una sola PSK para el personal, que no se ha cambiado en tres años. Se sabe que un excolaborador tiene la PSK.
La cadena de tiendas minoristas debe implementar Google Secure LDAP de inmediato. Implementan un servidor RADIUS central en la nube, configurado para autenticarse contra Google Secure LDAP. En la consola de administración de Google, crean un perfil WiFi utilizando PEAP-MSCHAPv2, aplicando una validación estricta del certificado del servidor. Los puntos de acceso en 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, implementan una solución de Captive Portal independiente en una VLAN segregada, que captura el consentimiento de marketing y garantiza el cumplimiento de GDPR, completamente aislada de la red del personal. La cuenta de Google del excolaborador se deshabilita, lo que revoca de inmediato su acceso a la red sin requerir una rotación de PSK en las 50 ubicaciones.
Preguntas de práctica
Q1. Su organización está implementando 802.1X en 500 Chromebooks administrados. Desea el nivel más alto de seguridad y evitar que los usuarios tengan que ingresar una contraseña para conectarse al WiFi. ¿Qué método EAP debería configurar en la Google Admin Console y qué componente de infraestructura adicional debe implementar?
Sugerencia: ¿Qué método depende completamente 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 Google Admin Console (usando SCEP o el 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 administrar los certificados de cliente.
Q2. Ha configurado Google Secure LDAP y un servidor FreeRADIUS. Los usuarios pueden autenticarse correctamente, pero todos están siendo asignados a 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 conecta los datos de identidad de Google con el equipo de red y qué atributos de protocolo llevan la información de VLAN?
Ver respuesta modelo
El servidor RADIUS debe estar configurado para consultar la membresía de grupo del usuario desde Google Secure LDAP y luego devolver los atributos RADIUS correspondientes (específicamente Tunnel-Private-Group-Id y Tunnel-Type) de vuelta al punto de acceso. El punto de acceso utiliza estos atributos para colocar al cliente en la VLAN correcta. La fuente de datos que habilita esto es la membresía de grupo de Google Workspace, recuperada a través de la consulta Secure LDAP.
Q3. Un usuario informa que no puede conectarse a la nueva red 802.1X en su teléfono Android personal (BYOD). Se le solicitan un nombre de usuario y contraseña (PEAP), pero la conexión falla de forma silenciosa después de ingresarlos. 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 el dispositivo cliente debe hacer antes de enviar las credenciales del usuario y qué configuración se requiere en el dispositivo.
Ver respuesta modelo
El dispositivo cliente está fallando al validar el certificado del servidor RADIUS. En las versiones modernas de Android, se fuerza la validación estricta de certificados por defecto. 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 el 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 director financiero solicita el caso de negocio. ¿Cuáles son los tres argumentos financieros y operativos más convincentes que presentaría?
Sugerencia: Considere los costos asociados con la gestión de PSK, el riesgo de exposición de credenciales y la carga operativa de la gestión de sitios distribuidos.
Ver respuesta modelo
- Eliminación de los costos de rotación de PSK: con una PSK estática, cualquier salida de personal requiere una rotación de clave en todos los sitios, una operación costosa e interruptiva. Con la autenticación basada en identidad, inhabilitar una cuenta de Google revoca el acceso de inmediato en todas las ubicaciones. 2. Menor riesgo de filtración de datos: 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 costo promedio de una filtración de datos supera los $4.8 millones de dólares, lo que hace que la inversión en infraestructura sea fácil de justificar. 3. Reducción de la carga de soporte: la gestión automatizada de credenciales a través de Google Workspace elimina los tickets de restablecimiento de contraseñas relacionados con el WiFi y la configuración manual de dispositivos, reduciendo típicamente 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 empresarial contra Google Workspace, las organizaciones implementan 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 contra los directorios de usuarios de Google sin necesidad de servidores locales.
¿Cómo se implementan certificados WiFi 802.1X en Chromebooks a través de Google Admin Console?
Para implementar certificados 802.1X en dispositivos ChromeOS, configure un perfil SCEP (Simple Certificate Enrollment Protocol) automatizado en Google Admin Console en Dispositivos > Redes > Certificados. Google Admin emite una solicitud de firma de certificado (CSR) con un par de claves generado por el TPM del hardware a una PKI en la nube de confianza. Una vez firmado por su CA emisora, Google Admin envía un perfil de WiFi gestionado en Dispositivos > Redes > WiFi con EAP-TLS y el certificado de cliente implementado a las unidades organizativas de destino.
¿Cuál es la diferencia entre EAP-TLS y Google Secure LDAP para la autenticación de WiFi?
EAP-TLS es un protocolo 802.1X basado en certificados donde los dispositivos se autentican criptográficamente utilizando certificados digitales únicos almacenados en TPMs de hardware. No requiere que el usuario ingrese contraseñas 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 sobre el puerto TLS 636 utilizando certificados de cliente. Aunque Secure LDAP permite un 802.1X basado en contraseñas mediante PEAP o EAP-TTLS, EAP-TLS es el estándar de la industria para Chromebooks gestionadas debido a su seguridad superior y a que no genera fricción para el usuario.
¿Cómo funciona la asignación dinámica de VLAN con Google Workspace y Cloud RADIUS?
Cuando una Chromebook o un usuario se autentica, Cloud RADIUS inspecciona la Unidad Organizativa (OU) del usuario o la membresía de Google Group 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 20 para el Personal, VLAN 30 para Estudiantes o VLAN 40 para Contratistas - dentro de un único SSID.
¿Qué sucede cuando se suspende a un empleado o estudiante en Google Workspace?
Debido a que Cloud RADIUS consulta a Google Workspace en tiempo real a través de Secure LDAP o valida los certificados contra un respondedor activo OCSP/CRL, la baja del usuario es instantánea. Tan pronto como una cuenta de usuario es suspendida o movida a una OU deshabilitada en la consola de administración de Google, las solicitudes posteriores de autenticación 802.1X reciben un Access-Reject de RADIUS. Además, el Cambio de Autorización dinámico de RADIUS (CoA, RFC 3576 / RFC 5176) puede terminar inmediatamente 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 requerir un Active Directory local ni controladores de dominio. Purple automatiza el aprovisionamiento de certificados SCEP para Chromebooks gestionadas, conecta Google Secure LDAP para la autenticación de dispositivos propios (BYOD) y proporciona una asignación dinámica de VLAN basada en Google Groups. Los equipos de TI obtienen visibilidad centralizada, telemetría de afluencia de visitantes y un aprovisionamiento de red sin intervención en más de 80,000 establecimientos en 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 a WiFi cuando un empleado se va
Esta guía muestra a los equipos de TI y de operaciones de recintos cómo eliminar el acceso de un empleado a la WiFi del personal cuando este se retira, sin interrumpir al resto de los trabajadores. Compara la desvinculación basada en certificados 802.1X, iPSK de identidad específica y aprovisionamiento controlado por SCIM, para luego ofrecer un manual de procedimientos para el mismo día, un método de prueba y un modelo de evidencia de auditoría.
WiFi seguro para BYOD: Incorporación con certificados Passpoint vs xPSK (iPSK)
Una guía técnica completa para equipos de TI sobre cómo proteger los dispositivos no gestionados de empleados y estudiantes (BYOD) mediante certificados Passpoint EAP-TLS de instalación sin intervención frente a tecnologías xPSK específicas de cada proveedor (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal frente a 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 empresariales. Describe las diferencias de arquitectura, las metodologías de implementación y las implicaciones de seguridad de cada estándar para ayudar a los arquitectos de red y a los líderes de TI a tomar decisiones de implementación fundamentadas.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.