¿Qué es GCPW? - Cómo gestionar el inicio de sesión de Windows con la autenticación de Google

En las consultas sobre cómo centralizar el inicio de sesión de los terminales Windows en torno a Google, es muy frecuente que estos temas se mezclen todos a la vez.

• ¿GCPW solo “muestra la pantalla de inicio de sesión de Google”?
• ¿Qué ocurre con los perfiles locales o de AD existentes?
• ¿Se puede gestionar también los privilegios de administrador de Windows, BitLocker y las actualizaciones?
• ¿Cómo funcionan el primer inicio de sesión, el modo sin conexión, la verificación en dos pasos y el cambio de contraseña?
• ¿Puede coexistir con Active Directory, o lo reemplaza?

Si se resuelven estas preguntas de forma superficial, las expectativas previas a la implementación quedan desalineadas y es fácil que ocurran incidentes durante la migración o la configuración inicial.

GCPW no es simplemente una “pantalla de inicio de sesión de Google”, ni tampoco un sustituto completo del dominio de Windows. En la práctica, la perspectiva se aclara si se separan el inicio de sesión de Google en Windows, la asociación con perfiles existentes, la gestión de la contraseña y la sesión en el lado de Google y el uso combinado con Windows device management.

En este artículo se organiza, de forma orientada a la práctica y con abundantes diagramas Mermaid, qué ocurre al usar Google Credential Provider for Windows (GCPW) en entornos Windows 10/11, qué configuraciones son adecuadas, el procedimiento de implementación y los puntos donde suele haber problemas. El contenido se basa principalmente en la documentación oficial de Google Workspace que se puede consultar a fecha de marzo de 2026.

Los diagramas son conceptuales. En entornos Markdown compatibles con Mermaid se muestran como diagramas.

1. Primero, la conclusión

Antes que nada, presentamos solo las conclusiones.

• GCPW es un mecanismo para iniciar sesión en Windows 10/11 con una cuenta de Google administrada.
• El protagonista de GCPW por sí solo es el inicio de sesión en Windows y la experiencia de SSO de Chrome Browser.
• Si además se quiere gestionar las actualizaciones de Windows, BitLocker, los privilegios de administrador local, las configuraciones personalizadas y el borrado remoto, lo más práctico es dar por sentado el uso combinado con Windows device management.
• En entornos con perfiles locales o de AD existentes, si no se decide primero si se asociará el perfil existente o se creará uno nuevo, es fácil que la migración se atasque.
• El primer inicio de sesión requiere conexión en línea. Además, en un terminal unido a AD sin un perfil existente basado en AD, también es importante poder conectarse a AD en ese primer inicio de sesión.
• El inicio de sesión sin conexión es posible, pero si no se decide hasta cuántos días se permite, la operación se vuelve inestable.
• La verificación en dos pasos se puede usar, pero las llaves de seguridad USB no son compatibles con GCPW.
• Si no se decide primero la gestión de contraseñas, ocurrirán incidentes de inicio de sesión por falta de coincidencia entre Google y Windows. En particular, es peligroso restablecer la contraseña primero solo en el lado de AD / Entra ID.
• GCPW trata únicamente a Google como proveedor de identidad, así que conviene diseñar la configuración partiendo de esta premisa para evitar desajustes.

En resumen, GCPW es “un mecanismo para entrar en Windows con Google”, y si se quiere controlar la operación completa de los terminales Windows, lo lógico es diseñarlo junto con Windows device management.

Terminología usada en este artículo

Como se mezclan términos del lado de Google y del lado de Windows, los organizamos primero.

Primero, una vista general en un solo diagrama

flowchart TD
    accTitle: Relación entre el objetivo y la herramienta a usar
    accDescr: Diagrama que, a partir de lo que se quiere lograr en el terminal Windows con una cuenta de Google, deriva la herramienta responsable (GCPW, Windows device management o el diseño de asociación de perfiles) y sus funciones concretas
    A["Quiero usar una cuenta de Google en un terminal Windows"] --> B{"¿Qué se quiere lograr?"}
    B --> C["Inicio de sesión de Google en Windows"]
    B --> D["Gestión centralizada de la configuración de Windows"]
    B --> E["Migración de perfiles existentes"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["Diseño de asociación de perfiles locales / de AD existentes"]

    F --> I["Inicio de sesión en Windows"]
    F --> J["SSO de Chrome Browser"]
    F --> K["Sincronización de contraseña de Google"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["Privilegios de administrador local"]
    G --> O["Configuración personalizada / borrado remoto / auditoría"]

    H --> P["¿Crear un perfil nuevo?"]
    H --> Q["¿Reutilizar el perfil existente?"]

Este diagrama sirve para derivar “la herramienta a usar” a partir de “lo que se quiere lograr”. Al elegir de izquierda a derecha lo que se desea conseguir, se determina el mecanismo responsable (GCPW / Windows device management / diseño de perfiles). Aquí solo hay un punto que confirmar: la gestión a nivel de terminal, como BitLocker o Windows Update, no aparece en la columna de GCPW.

2. Entender GCPW en cuatro capas es más sencillo

La razón por la que el tema de GCPW se vuelve complicado es que “el inicio de sesión”, “la migración de perfiles” y “la gestión del terminal” tienden a tratarse como si fueran el mismo asunto. En la práctica, es más rápido separarlos en estas cuatro capas.

Con este enfoque resulta más fácil ver el origen de desajustes como “instalé GCPW pero BitLocker no funciona” o “inicié sesión con Google pero no veo los datos de usuario existentes”.

Estructura de capas

flowchart LR
    accTitle: Estructura de capas de GCPW
    accDescr: Diagrama que muestra cómo la cuenta de Google y la verificación en dos pasos alimentan a GCPW, cómo GCPW se conecta con los distintos tipos de perfil de Windows y con Windows device management, y cómo Admin console y el registro configuran GCPW
    subgraph Id["ID / Sesión"]
        A["Cuenta de Google"]
        B["Verificación en dos pasos"]
    end

    subgraph SignIn["Capa de inicio de sesión"]
        C["GCPW"]
    end

    subgraph Profile["Capa de perfil de Windows"]
        D["Perfil local existente"]
        E["Perfil AD-backed existente"]
        F["Nuevo perfil de Windows"]
    end

    subgraph Mgmt["Capa de gestión"]
        G["Windows device management"]
        H["BitLocker / actualizaciones / privilegios de administrador local"]
        I["Configuración personalizada / borrado remoto / auditoría"]
    end

    subgraph Config["Capa de configuración"]
        J["Admin console"]
        K["Configuración del registro"]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F
    J --> C
    K --> C
    G --> H
    G --> I
    C --> G

Mientras que el diagrama del capítulo 1 “deriva la herramienta a partir del objetivo”, este diagrama reordena los mismos elementos según “de qué capa se trata” y “qué depende de qué”. Lo que interesa observar es que todas las flechas pasan por GCPW (la capa de inicio de sesión), y que la flecha que sale de GCPW hacia la capa de perfil se ramifica en tres. Esta ramificación es exactamente el diseño de “si se asocia el perfil existente o se crea uno nuevo” que se trata en el capítulo 4.

3. Cómo funciona en un entorno Windows

3.1 Comprender primero los requisitos compatibles

En un entorno Windows, lo primero es no tropezar con los requisitos.

Diferencias entre ediciones compatibles (el primer obstáculo para decidir la implementación)

Las ediciones necesarias difieren entre “GCPW solo” y “uso combinado con Windows device management”. La documentación oficial de Google (Overview: Enhanced desktop security for Windows) indica las siguientes ediciones compatibles.

La lectura es la siguiente. Si solo se busca el inicio de sesión con GCPW, se puede usar en prácticamente todas las ediciones. Por otro lado, si se desea gestionar también BitLocker, Windows Update o los privilegios de administrador local, se necesita una edición compatible como Business Plus, Enterprise Standard o superior, o Cloud Identity Premium. En particular, Business Starter / Business Standard y Cloud Identity Free permiten usar GCPW, pero no Windows device management. Las consultas del tipo “instalé GCPW pero no puedo gestionar BitLocker” a veces tienen aquí su origen.

La composición de las ediciones puede cambiar, por lo que antes de contratar es imprescindible consultar la tabla de compatibilidad más reciente de la documentación oficial.

Aquí es fácil pasar por alto Chrome y la falta de compatibilidad con ARM. Como se trata de terminales Windows, se tiende a mirar solo el sistema operativo, pero GCPW también depende de Chrome para iniciar la pantalla de inicio de sesión de Google, así que la falta de Chrome o una instalación incorrecta también puede hacer que falle el inicio de sesión.

3.2 Del primer inicio de sesión al inicio de sesión habitual

Simplificando el flujo tras implementar GCPW, queda así.

1. Se instala GCPW en el terminal.
2. El usuario inicia sesión por primera vez con su cuenta de Google.
3. GCPW asocia un perfil existente o crea un nuevo perfil de Windows.
4. A partir de entonces, se entra desde la pantalla habitual de inicio de sesión de Windows.
5. No obstante, ante eventos de seguridad como un cambio de contraseña de Google o la expiración de la sesión, se vuelve a solicitar la pantalla de inicio de sesión de Google.

Lo importante aquí es que no es cierto que “siempre haya que entrar por el cuadro de diálogo de Google”. En el primer inicio de sesión o ante ciertos eventos de seguridad, la autenticación de Google pasa a primer plano, pero en el uso habitual predomina el inicio de sesión desde la pantalla de Windows.

Flujo del primer inicio de sesión

sequenceDiagram
    accTitle: Flujo del primer inicio de sesión con GCPW
    accDescr: Diagrama de secuencia que muestra cómo el usuario inicia sesión con Google desde la pantalla de Windows, cómo GCPW asocia un perfil existente o crea uno nuevo tras la autenticación, y cómo se inicia la sesión de Chrome y de Windows
    participant U as Usuario
    participant W as Pantalla de inicio de sesión de Windows
    participant G as Inicio de sesión de Google
    participant P as GCPW
    participant R as Perfil existente o nuevo
    participant C as Chrome Browser

    U->>W: Elige "Agregar cuenta de trabajo" o una cuenta existente
    W->>G: Se inicia la pantalla de autenticación de Google
    G->>U: Solicita correo electrónico, contraseña y 2SV
    U->>G: Introduce las credenciales
    G->>P: Autenticación correcta

    alt Se asocia un perfil existente
        P->>R: Busca y asocia el perfil local o de AD existente
    else Creación de uno nuevo
        P->>R: Crea un nuevo perfil de Windows
    end

    P->>C: Traslada el estado de sesión de Google
    P->>W: Inicia la sesión de Windows

Lo que interesa observar en este diagrama es que solo hay una ramificación: si se asocia el perfil existente o se crea uno nuevo. Esto se decide en el instante del primer inicio de sesión, y volver atrás después diciendo “mejor asociar el perfil existente” implica rehacer trabajo. Por eso, el diseño de asociación del capítulo 4 debe completarse antes de distribuir el instalador.

3.3 Sincronización de contraseñas, modo sin conexión y verificación en dos pasos

Si se quiere operar GCPW de forma estable en un entorno Windows, en realidad lo primero que hay que revisar es la gestión de contraseñas.

La guía oficial de Google también parte de que, en los terminales que usan GCPW, la contraseña de Google y la de Windows están sincronizadas. Además, se asume que el usuario gestiona principalmente la contraseña del lado de Google. Por eso, un diseño que dependa del cambio de contraseña de Windows desde Ctrl + Alt + Supr no encaja bien.

Cómo pensar la sincronización de contraseñas

flowchart LR
    accTitle: Sincronización de contraseñas entre Google y Windows
    accDescr: Diagrama que compara el flujo de un cambio de contraseña en Google, que se sincroniza con Windows cuando el terminal está en línea o queda pendiente hasta la siguiente conexión, con el flujo de un cambio de contraseña realizado solo en AD o Entra ID, que provoca una falta de coincidencia y un error de sincronización
    A["Cambio de contraseña en Google"] --> B{"¿El terminal está en línea?"}
    B -- Sí --> C["GCPW sincroniza la contraseña del lado de Windows"]
    C --> D["El siguiente inicio de sesión se realiza con éxito"]

    B -- No --> E["La sincronización queda pendiente"]
    E --> F["Se resincroniza en la siguiente conexión"]

    G["Cambio de contraseña solo en AD / Entra ID"] --> H["Falta de coincidencia entre Google y Windows"]
    H --> I["Password incorrect / error de sincronización"]

Este diagrama se divide en dos flujos, arriba y abajo. El flujo superior (cambio en el lado de Google) se sincroniza si hay conexión, y si está sin conexión, se pone al día en la siguiente conexión. El flujo inferior (cambio solo en AD / Entra ID) no se sincroniza por mucho que se espere. Al elaborar el procedimiento de restablecimiento de contraseñas, es práctico anotar explícitamente este flujo inferior como un procedimiento prohibido.

En la práctica, esto es lo que suele ocurrir.

• Se cree haber cambiado la contraseña en Google, pero el terminal está sin conexión y aún no se ha sincronizado con Windows.
• A la inversa, se restablece primero solo en AD / Entra ID y se produce una falta de coincidencia con Google.
• La complejidad de la contraseña en Google es más débil que en Windows / AD, y se cambia a una cadena que no cumple los requisitos del lado de Windows.

Por eso, antes de la implementación hay que decidir al menos lo siguiente.

• Si el control de la contraseña recae en Google.
• O si, por el contrario, se sincroniza hacia Google desde AD / Entra ID u otra herramienta.
• Si la complejidad de la contraseña se ajusta al nivel de Windows o superior.

El tercer punto, la complejidad, se configura por unidad organizativa en la consola de administración de Google, en “Seguridad” → “Autenticación” → “Gestión de contraseñas”. Sin embargo, lo que se puede especificar ahí se limita a la casilla “Aplicar contraseña segura”, el número mínimo y máximo de caracteres (de 8 a 100), si se permite la reutilización y la fecha de caducidad. A diferencia de las directivas de contraseñas de Active Directory, no es posible especificar el tipo de caracteres, como “debe incluir tantos tipos entre mayúsculas, minúsculas, números y símbolos”. Esto se debe a que, en Google, se evalúa la solidez de la contraseña en su conjunto y no el desglose por tipo de carácter.

Por eso, en la práctica, la forma de alinearlo consiste en configurar en Google un número mínimo de caracteres igual o mayor que el de AD, y activar “Aplicar contraseña segura”. Si los requisitos de tipo de caracteres en AD son estrictos, sigue existiendo la posibilidad de que una contraseña aceptada en Google sea rechazada por Windows, así que esa combinación debe verificarse siempre en un piloto.

Modo sin conexión y verificación en dos pasos

El inicio de sesión sin conexión en sí es posible con GCPW. Sin embargo, se puede configurar hasta cuántos días se permite desde el último inicio de sesión en línea. Si se implementa sin decidir esto, se tiende a caer en uno de dos extremos: demasiado estricto, lo que incomoda al equipo, o demasiado laxo, lo que aumenta el riesgo en caso de pérdida del terminal.

Además, la verificación en dos pasos se puede usar, pero es más seguro comunicar de antemano al equipo los siguientes puntos.

• Las llaves de seguridad USB no son compatibles con GCPW.
• En su lugar, hay que basarse en métodos como Google prompt, Google Authenticator o los códigos de respaldo (backup code).
• Si la configuración solo permite llaves de seguridad, existe la posibilidad de que el usuario no pueda entrar en Windows.

4. Cómo tratar los perfiles locales o de AD existentes

Este es el punto donde más incidentes suelen ocurrir en una migración a GCPW.

Cuando el terminal ya tiene un perfil de Windows de uso profesional, la experiencia del usuario y la dificultad de la migración cambian mucho según si GCPW lo asocia y reutiliza, o si crea un nuevo perfil de Windows.

Tres patrones representativos

Según la propia guía de Google, cuando se asocia a un perfil existente, se utiliza un atributo personalizado (custom attribute) del lado del directorio para asociar el nombre de la cuenta de Windows o la cuenta de AD, o bien una configuración del registro basada en el SID en el propio terminal. Es decir, no se trata de una operación en la que “el usuario elige más o menos sobre la marcha después de instalarlo”, sino de un trabajo de migración que requiere un diseño previo.

Y lo que es aún más importante: el comportamiento cuando no se realiza la asociación.

• Para los usuarios de un perfil local existente, puede quedar la posibilidad de entrar al perfil antiguo.
• Para los usuarios de AD existentes, si se crea un nuevo perfil para el inicio de sesión con Google, es posible que no puedan entrar directamente al perfil profesional que esperaban.

Diagrama de decisión sobre cómo tratar un perfil existente

flowchart TD
    accTitle: Decisión sobre el tratamiento de un perfil existente
    accDescr: Diagrama que, partiendo de si se desea seguir usando los datos o la configuración de un perfil de Windows profesional existente, deriva si hay que diseñar la asociación (distinguiendo entre perfil local y AD-backed) o dejar que GCPW cree un perfil nuevo con un plan de migración de datos aparte
    A["El terminal tiene un perfil de Windows profesional existente"] --> B{"¿Se quiere seguir usando esos datos o esa configuración?"}
    B -- Sí --> C["Diseñar la asociación del perfil existente"]
    B -- No --> D["Dejar que GCPW cree un nuevo perfil de Windows"]

    C --> E{"Tipo de perfil existente"}
    E -- Local --> F["Asociar mediante Local Windows accounts, etc."]
    E -- AD-backed --> G["Asociar mediante AD accounts, etc."]

    G --> H["Confirmar la conectividad con AD en el primer inicio de sesión"]
    F --> I["Organizar el nombre de usuario de Windows / las restricciones por terminal"]
    D --> J["Avanzar la migración de datos existentes con un plan aparte"]

Esta decisión solo hace falta tomarla una vez por cada grupo de terminales. Si se decide de antemano, por grupo de terminales, la primera ramificación (si se quiere seguir usando los datos existentes tal cual), lo que queda converge en crear la definición de asociación o en crear un plan de migración de datos. Si se deja que cada terminal se decida individualmente sobre el terreno, se mezclarán perfiles nuevos y perfiles asociados dentro de un mismo grupo de terminales, y dejará de ser posible prever la atención a las consultas.

5. Diferencias entre GCPW solo y GCPW + Windows device management

Al hablar de GCPW, en la práctica es muy importante distinguir este punto.

Tabla comparativa

La propia documentación oficial de Google recomienda, para los terminales proporcionados por la empresa, una configuración que combine GCPW y Windows device management. A la inversa, si ya existe otra plataforma de gestión y solo se desea la experiencia de inicio de sesión de Google, el planteamiento adecuado es usar GCPW solo.

Una restricción poco visible pero importante al combinarlos

Al combinar Windows device management, conviene entender de antemano que solo un usuario puede quedar enrolado por cada terminal.

La propia documentación oficial de Google lo indica como una restricción del lado de Windows 10/11. Aunque la configuración permita que varios usuarios entren a ese terminal con GCPW, solo el primer usuario queda enrolado en Windows device management. Además, las configuraciones a nivel de terminal, como BitLocker, las actualizaciones o los privilegios de administrador local, también afectan a los demás usuarios de ese terminal.

El problema del primer usuario

flowchart TD
    accTitle: El problema del primer usuario enrolado
    accDescr: Diagrama que muestra cómo el primer usuario que inicia sesión con GCPW en un terminal recién configurado queda enrolado en Windows device management y recibe la configuración a nivel de terminal, mientras que los usuarios que inician sesión después pueden entrar a Windows pero no quedan enrolados
    A["Configurar el terminal"] --> B["Primer usuario que inicia sesión con GCPW"]
    B --> C["Enrola en Windows device management"]
    C --> D["Se aplica la configuración a nivel de terminal"]
    D --> E["BitLocker / actualizaciones / privilegios de administrador local / configuración personalizada"]

    F["Otro usuario que entra después con GCPW"] --> G["El inicio de sesión en Windows en sí es posible"]
    G --> H["Pero no aumenta el número de usuarios enrolados"]
    H --> I["La configuración a nivel de terminal se rige por el primer enroll"]

Esto afecta directamente a un problema concreto: que el responsable de la preparación (kitting) sea quien entra primero con GCPW. Si en lugar del empleado que va a usar ese terminal queda enrolada la cuenta del responsable de la configuración, más adelante ocurre el incidente de que la configuración prevista no se aplica.

6. Qué decidir antes de la implementación

En la implementación de GCPW, lo que más pesa después no es la ejecución del instalador en sí, sino el diseño previo. Traduciendo la guía oficial a términos prácticos, conviene decidir de antemano al menos estos seis puntos.

flowchart LR
    accTitle: Seis decisiones previas a la implementación
    accDescr: Diagrama que ordena, de izquierda a derecha, las decisiones que hay que tomar antes de implementar GCPW en el orden en que dependen unas de otras, desde el control de la contraseña hasta los días permitidos sin conexión
    A["Decidir antes de implementar"] --> B["Control de la contraseña"]
    B --> C["Requisitos de complejidad"]
    C --> D["Dominios permitidos"]
    D --> E["Tratamiento del perfil existente"]
    E --> F["Privilegios de administrador para soporte"]
    F --> G["Política de staging para el enrollment automático"]
    G --> H["Días permitidos sin conexión"]

En este diagrama el orden tiene sentido. Está organizado de izquierda a derecha, en el orden en que cada decisión depende de la anterior. Por ejemplo, la complejidad no se puede decidir si antes no se ha decidido si el control de la contraseña recae en Google o en AD. Dicho de otro modo, si se distribuye el instalador saltándose algún punto de este orden, todas las decisiones posteriores quedan pendientes mientras el número de terminales sigue creciendo.

Formas de proceder inadecuadas y formas prácticas

Tres puntos especialmente fáciles de pasar por alto

1. Los dominios permitidos son obligatorios

En GCPW, si no se decide de qué dominio se permiten las cuentas para iniciar sesión, ningún usuario podrá entrar. Se puede configurar tanto desde Admin console como desde el registro con domains_allowed_to_login, pero en cualquier caso es obligatorio.

2. Admin console y el registro tienen funciones distintas

En las explicaciones antiguas abundan los artículos centrados en la configuración por registro, pero en la actualidad lo básico es la gestión desde Admin console. Sin embargo, cuando se desea una granularidad más fina, como tener dominios permitidos distintos por terminal, hay casos en los que el registro resulta más adecuado.

3. La configuración de Admin console no se refleja de forma inmediata

La configuración de GCPW se sincroniza con el terminal aproximadamente cada hora. Es habitual pensar “ya configuré esto, pero no se refleja de inmediato”, así que durante el piloto es más seguro tener en cuenta este desfase.

7. Procedimiento práctico de implementación

Aquí resumimos, de la forma más breve posible, el flujo práctico para implementar GCPW en un entorno Windows.

Flujo de implementación

flowchart TD
    accTitle: Flujo de implementación de GCPW
    accDescr: Diagrama que enumera, en nueve pasos, el flujo de implementación desde confirmar el plan contratado y los requisitos hasta revisar los detalles del terminal, el enrollment y los registros tras el primer inicio de sesión
    A["1. Confirmar el plan contratado, el sistema operativo y los requisitos de Chrome"] --> B["2. Decidir la estrategia de contraseñas y la complejidad"]
    B --> C["3. Decidir los dominios permitidos y otras configuraciones"]
    C --> D["4. Decidir si se necesita asociar un perfil existente"]
    D --> E["5. Activar Windows device management si se va a usar"]
    E --> F["6. Obtener el instalador desde Admin console"]
    F --> G["7. Distribuir al terminal / instalar con privilegios de administrador"]
    G --> H["8. El usuario realiza el primer inicio de sesión en línea"]
    H --> I["9. Revisar los detalles del terminal, el enrollment y los registros"]

7.1 Primero, decidir la configuración

Lo primero que hay que decidir es esto.

• Si se usará GCPW solo.
• O GCPW + Windows device management.
• Si se asociará un perfil existente.
• O si se cambiará mediante un perfil nuevo.

Esta decisión va primero. Si se distribuye solo el instalador sin decidir esto, después ocurrirá que “no se puede gestionar el terminal como se esperaba” o “no se hereda el dato de usuario existente”.

7.2 Decidir los dominios permitidos y las opciones

Hay dos formas de configurarlo.

• Admin console Es adecuado cuando se quiere distribuir la misma configuración a toda la organización. Actualmente es la opción básica.
• Registro del terminal Es adecuado cuando se quiere diferenciar de forma detallada por terminal.

Si se usa el registro, como mínimo se necesita domains_allowed_to_login. Si GCPW se combina con Windows device management, también son puntos a decidir enable_dm_enrollment y validity_period_in_days, y si la operación se parece a la de un terminal compartido, también enable_multi_user_login.

7.3 Obtener el instalador y distribuirlo

Se obtiene el instalador de GCPW de 32 bits/64 bits desde Admin console y se distribuye a los terminales. La ruta de la pantalla donde se obtiene es la siguiente.

Consola de administración de Google
  → Menú
  → Dispositivos (Devices)
  → Móviles y puntos de conexión (Mobile & endpoints)
  → Configuración (Settings)
  → Windows
  → "Google Credential Provider for Windows setup"
  → "Download GCPW"

Esta operación requiere haber iniciado sesión como administrador con privilegios completos (super administrator). Desde aquí se descarga la versión de 64 bits o de 32 bits y se distribuye.

En el modelo de gestión actual, lo importante es que el instalador descargado desde Admin console lleva incrustado automáticamente el token de esa organización. La presencia o ausencia del token influye más adelante.

Además, si ya se ha distribuido a los terminales un token de registro para Chrome Enterprise Core, con ese mismo token también se puede gestionar la configuración de GCPW desde Admin console. Cuando “se configuró el dominio permitido en Admin console pero no se refleja en el terminal”, lo primero que hay que sospechar es si se ha distribuido un instalador sin token. Como el propio reflejo de la configuración puede tardar hasta una hora aproximadamente, conviene esperar ese tiempo antes de sacar conclusiones.

7.4 Instalar

Para una instalación manual, se puede hacer, por ejemplo, así.

# Versión de 64 bits
gcpwstandaloneenterprise64.exe /silent /install

# Versión de 32 bits
gcpwstandaloneenterprise.exe /silent /install

7.5 Ejemplo de configuración individual mediante el registro

Ejemplo para cuando se quiere introducir por terminal un valor que no está configurado en Admin console.

Nota: si el mismo ajuste existe tanto en Admin console como en el registro, prevalece Admin console.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"domains_allowed_to_login"="example.com"
"enable_dm_enrollment"=dword:00000001
"validity_period_in_days"=dword:00000007
"enable_multi_user_login"=dword:00000000

7.6 Si se va a reutilizar un perfil existente, crear primero la definición de asociación

Si se quiere reutilizar un perfil local o de AD existente, hay que preparar de antemano la correspondencia entre la cuenta de Google del usuario y la cuenta de Windows mediante un atributo personalizado (custom attribute) del lado del directorio. Si se posterga esto y se deja iniciar sesión primero, es fácil que se cree un perfil nuevo y luego haya que deshacerlo. Como es el punto donde más suelen ocurrir incidentes en este artículo, lo detallamos a continuación.

Paso 1: crear el atributo personalizado

Se agrega desde Admin console, en “Directorio” → “Usuarios” → “Más opciones” en la parte superior → “Gestionar atributos personalizados”. Los valores deben introducirse exactamente como se indica a continuación, incluyendo mayúsculas y minúsculas (si se comete un error, el nombre no se puede corregir después y habrá que volver a crearlo).

Si se crea mediante Directory API, se registra con el nombre de esquema Enhanced_desktop_security y los nombres de campo AD_accounts / Local_Windows_accounts. Para volcar valores desde un AD existente, también existe la opción de usar Google Cloud Directory Sync.

Paso 2: introducir el valor para cada usuario

En la pantalla de detalles del usuario, en “Información del usuario”, aparece el campo “Enhanced desktop security”, donde se introduce el nombre de la cuenta del lado de Windows. El formato está definido.

Hay tres restricciones que conviene tener presentes.

• La cuenta de AD debe ser solo una por usuario. Aunque se introduzcan varias, GCPW solo usa la primera.
• Si se configuran tanto AD como cuenta local, GCPW busca primero la cuenta de AD.
• Si el atributo no está configurado, o no se encuentra un perfil de Windows coincidente, se crea un perfil de Windows nuevo. La mayoría de los casos de “debería haberse asociado, pero no veo los datos existentes” tienen su origen aquí.

En un terminal unido a AD, un usuario que todavía no tiene un perfil AD-backed en ese terminal (quien entra desde “Otro usuario” en la pantalla de inicio de sesión) necesita que el terminal pueda conectarse a AD en el primer inicio de sesión. Si se hace iniciar sesión por primera vez en un terminal en teletrabajo, este paso falla.

Para el procedimiento exacto en pantalla y las especificaciones más recientes, consulte el documento oficial Associate Google accounts with existing Windows profiles.

7.7 Verificar después del primer inicio de sesión en línea

Después del primer inicio de sesión, hay que verificar lo siguiente.

• Si se ha entrado al perfil de Windows esperado.
• Si, en caso de combinar con Windows device management, el enroll se ha realizado con el usuario previsto.
• Si los detalles del terminal aparecen en Admin console.
• Si la sincronización de las directivas ha terminado.

8. Problemas frecuentes y cómo aislarlos en Windows

Los problemas de GCPW casi siempre encajan en alguna fila de esta tabla.

Desglosar el contenido de “interferencia de Chrome / antivirus”

En esta tabla, lo más ambiguo es la “interferencia de antivirus”. En la práctica, el problema suele ser alguno de los siguientes. Revisarlos en orden, de arriba abajo, agiliza el aislamiento.

De estos puntos, la comunicación previa al inicio de sesión es la que más se suele pasar por alto. Aunque la comunicación funcione después de que el usuario inicia sesión, en el momento de la pantalla de inicio de sesión opera con otra ruta o con otras credenciales, así que hay que verificar si se detiene ahí.

Flujo de resolución de problemas

flowchart TD
    accTitle: Flujo de resolución de problemas de GCPW
    accDescr: Diagrama que, a partir del síntoma observado, deriva el punto de verificación inicial entre autenticación, Chrome, sincronización de contraseñas, asociación de perfil o enrollment, y la acción correspondiente
    A["Ocurre un problema con GCPW"] --> B{"¿Qué está pasando?"}
    B -- Inicio de sesión rechazado --> C["Verificar el dominio permitido"]
    B -- No aparece la pantalla de Google --> D["Verificar si existe Chrome / la ruta / el antivirus"]
    B -- Password incorrect --> E["Verificar el estado de sincronización de Google / Windows"]
    B -- No se ven los datos existentes --> F["Verificar la asociación de perfil"]
    B -- No entra en device management --> G["Verificar el primer usuario enrolado"]
    C --> H["Revisar Admin console / el registro"]
    D --> I["Reinstalar Chrome"]
    E --> J["Reorganizar la gestión de contraseñas"]
    F --> K["Revisar de nuevo el atributo personalizado / el mapeo por SID"]
    G --> L["Revisar el procedimiento de staging"]

Este diagrama sirve para fijar, a partir del síntoma, un único punto de verificación inicial. Los problemas de GCPW caen en “autenticación”, “Chrome”, “sincronización de contraseñas”, “asociación de perfil” o “enrollment”, así que primero hay que determinar de cuál de estas columnas se trata, y luego pasar a los registros detallados. Cuando parece haber varios síntomas a la vez, comprobar quién fue el primer usuario que pudo iniciar sesión suele hacer que el problema se concentre en la columna de enrollment.

Dónde obtener los registros en Windows

Para investigar GCPW en Windows, lo primero es el Visor de eventos (Event Viewer).

• Registros de Windows > Aplicación (Windows Logs > Application)
• El origen del evento (Event source) es GCPW

Con esto se puede ver la mayor parte de la información básica. Si se quiere profundizar más, se puede activar el registro detallado (verbose logging) mediante el registro de Windows.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"enable_verbose_logging"=dword:00000001
"log_file_path"="C:\\GCPW.log"
"log_file_append"=dword:00000001

Si también se quiere revisar Windows device management, según sea necesario se puede consultar además lo siguiente.

• Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

Cuando se quiere confirmar el reflejo rápidamente

Si tras corregir los dominios permitidos o las directivas se quiere confirmar el reflejo de inmediato, la guía de Google indica un método para forzar la sincronización ejecutando GoogleUpdateTaskMachineUA desde el Programador de tareas (Task Scheduler). Durante el piloto, tener este procedimiento a mano agiliza el aislamiento de problemas.

9. Qué tipo de organización es adecuada, y cuál no

Casos adecuados

Casos no adecuados

10. Resumen

La clave para usar bien GCPW en un entorno Windows es no verlo como un bloque monolítico de funciones.

• GCPW es el mecanismo para entrar en Windows con Google.
• La asociación de perfiles existentes es el mecanismo de migración.
• Windows device management es el mecanismo de operación del terminal.

Separar estos tres elementos facilita mucho la decisión de implementación.

En la práctica, los siguientes cinco puntos son especialmente importantes.

1. Decidir primero la gestión de contraseñas.
2. Decidir primero los dominios permitidos.
3. Decidir si se reutilizará el perfil existente.
4. Si se usa Windows device management, no equivocarse con el primer usuario enrolado.
5. Tener preparado un procedimiento de resolución de problemas basado en el Visor de eventos.

GCPW es una herramienta práctica para acercar el inicio de sesión de Windows a Google. Sin embargo, lo que realmente cuenta no es el instante en que se ejecuta el instalador, sino el diseño previo a ese momento. Si se consolida esto primero, el inicio de sesión de Google, la continuidad de los datos existentes y la gestión de los terminales Windows quedan bien conectados.

Artículos relacionados

• ¿Cuándo se necesitan privilegios de administrador en Windows? - UAC, áreas protegidas y cómo distinguirlo en el diseño
• Cómo acelerar la validación de aplicaciones con Windows Sandbox
• ¿Qué es ClickOnce? - Su funcionamiento, las actualizaciones y los casos adecuados y no adecuados, explicados desde la práctica

Temas relacionados

• Temas técnicos de Windows

Servicios relacionados con este tema

• Desarrollo de aplicaciones Windows
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

1. Google Workspace Help - Overview: Enhanced desktop security for Windows
2. Google Workspace Help - Prepare to install GCPW
3. Google Workspace Help - Install Google Credential Provider for Windows
4. Google Workspace Help - Set up GCPW and Windows device management together
5. Google Workspace Help - Associate Google accounts with existing Windows profiles
6. Google Workspace Help - Set account privileges on Windows 10 or 11 devices
7. Google Workspace Help - FAQ for GCPW
8. Google Workspace Help - Troubleshoot GCPW
9. Google Workspace Learning Center - Sign in to Windows after GCPW installation
10. Google Workspace Help - Set token to manage GCPW from the Admin console
11. Google Workspace Help - What’s new in GCPW
12. Google Workspace - Ayuda para administradores: Aplicar y supervisar los requisitos de contraseña de los usuarios

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es GCPW?

GCPW (Google Credential Provider for Windows) es un mecanismo que permite iniciar sesión en Windows 10/11 con una cuenta de Google administrada. Cuando se usa solo, su protagonista es la experiencia de inicio de sesión en Windows y el SSO de Chrome Browser: no es simplemente una "pantalla de inicio de sesión de Google" ni un sustituto completo del dominio de Windows. Los sistemas operativos compatibles son Windows 10/11 Pro, Pro for Workstations, Enterprise y Education; los terminales basados en ARM no son compatibles, y se requiere que Chrome Browser 81 o posterior esté instalado con privilegios de administrador.

¿GCPW por sí solo permite gestionar BitLocker o Windows Update?

Por lo general, no. Con GCPW solo se puede iniciar sesión en Windows con Google, usar el SSO de Chrome y asociar perfiles existentes. Para BitLocker, el control de Windows Update, el control de los privilegios de administrador local, la distribución de configuraciones personalizadas o el borrado remoto, es necesario combinarlo con Windows device management. Al combinarlos, existe la restricción de que solo el primer usuario que inicia sesión en un terminal puede quedar enrolado (enroll), por lo que hay que tener cuidado con el accidente de que el responsable de la preparación del equipo (kitting) sea quien acabe enrolado al iniciar sesión primero.

¿GCPW permite iniciar sesión en Windows sin conexión?

El inicio de sesión sin conexión en sí es posible. Sin embargo, el primer inicio de sesión requiere obligatoriamente conexión a internet, y en un terminal unido a AD que aún no tiene un perfil existente basado en AD, también es necesario poder conectarse a AD en ese primer inicio de sesión. El número de días que se permite trabajar sin conexión se puede configurar con parámetros como validity_period_in_days; si no se decide hasta cuántos días se permite desde el último inicio de sesión en línea, se tiende a caer en un extremo demasiado estricto que incomoda a los usuarios, o demasiado laxo, lo que aumenta el riesgo en caso de pérdida del terminal.

¿Se pueden usar la verificación en dos pasos o las llaves de seguridad con GCPW?

La verificación en dos pasos se puede usar, pero las llaves de seguridad USB no son compatibles con GCPW. En su lugar, se debe partir de métodos como Google prompt, Google Authenticator o los códigos de respaldo (backup code). Si la configuración solo permite llaves de seguridad, los usuarios podrían quedar bloqueados fuera de Windows, por lo que conviene comunicarlo al equipo antes de la implementación. Además, como la contraseña se basa en la sincronización entre Google y Windows, restablecerla primero únicamente en el lado de AD / Entra ID puede provocar incidentes de inicio de sesión por falta de coincidencia.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.