Qu'est-ce que GCPW ? - Gérer la connexion Windows avec l'authentification Google

Dans les consultations où l’on souhaite regrouper la connexion des postes Windows autour de Google, ces questions se mélangent très fréquemment d’un seul coup :

• GCPW se contente-t-il d’« afficher l’écran de connexion Google », ou fait-il plus ?
• Que deviennent les profils locaux existants ou les profils AD ?
• Peut-il aussi prendre en charge les droits d’administrateur Windows, BitLocker et la gestion des mises à jour ?
• Comment se comportent la première connexion, le mode hors ligne, la validation en 2 étapes et le changement de mot de passe ?
• Peut-il coexister avec Active Directory, ou le remplace-t-il ?

Si l’on résume ces points à la va-vite, les attentes avant le déploiement se décalent, ce qui rend la migration et la configuration initiale sujettes aux incidents.

GCPW n’est ni un simple « écran de connexion Google », ni un substitut complet à un domaine Windows. En pratique, la vision devient beaucoup plus claire si l’on distingue la connexion à Windows via Google, la correspondance avec les profils existants, la gestion des mots de passe et des sessions côté Google, et l’utilisation combinée avec Windows device management.

Cet article organise, de façon pratique et avec de nombreux schémas Mermaid, ce qui se passe lorsqu’on utilise Google Credential Provider for Windows (GCPW) dans un environnement Windows 10 / 11 : les configurations adaptées, la procédure de déploiement et les pièges à éviter. Le contenu s’appuie principalement sur la documentation officielle de Google Workspace telle qu’elle pouvait être consultée en mars 2026.

Les schémas sont conceptuels. Ils s’affichent comme des diagrammes dans les environnements Markdown compatibles avec Mermaid.

1. D’abord, la conclusion

Commençons par poser les conclusions.

• GCPW est un mécanisme permettant de se connecter à Windows 10 / 11 avec un compte Google géré.
• Utilisé seul, le rôle principal de GCPW se limite à la connexion Windows et à l’expérience SSO de Chrome Browser.
• Si vous voulez aussi couvrir les mises à jour Windows, BitLocker, les droits d’administrateur local, les paramètres personnalisés et l’effacement à distance, il est plus réaliste de prévoir d’emblée une utilisation combinée avec Windows device management.
• Dans un environnement où existent déjà des profils locaux ou AD, il faut d’abord décider « associer le profil existant, ou en créer un nouveau ? », sinon la migration risque de se bloquer.
• La première connexion suppose d’être en ligne. De plus, sur un appareil joint à un AD sans profil AD-backed existant, il est également important de pouvoir joindre l’AD dès la première connexion.
• La connexion hors ligne est possible, mais si vous ne décidez pas combien de jours l’autoriser, le fonctionnement au quotidien deviendra instable.
• La validation en 2 étapes fonctionne, mais les clés de sécurité USB ne sont pas prises en charge par GCPW.
• Si vous ne définissez pas d’abord la gestion des mots de passe, des incidents de connexion surviendront à cause d’un décalage entre le côté Google et le côté Windows. En particulier, réinitialiser d’abord uniquement du côté AD / Entra ID est dangereux.
• GCPW ne traite que Google comme fournisseur d’identité, il vaut donc mieux concevoir la configuration en partant de ce principe pour éviter tout décalage.

En résumé, GCPW est « un mécanisme pour entrer dans Windows avec Google », et si vous voulez maîtriser l’ensemble de l’exploitation des postes Windows, la logique est de le concevoir en tandem avec Windows device management.

D’abord, une vue d’ensemble en un coup d’œil

flowchart TD
    A["Vouloir utiliser un compte Google sur un poste Windows"] --> B{"Que voulez-vous accomplir ?"}
    B --> C["Connexion à Windows via Google"]
    B --> D["Gestion centralisée des paramètres Windows"]
    B --> E["Migration des profils existants"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["Conception de l'association avec les profils locaux / AD existants"]

    F --> I["Connexion Windows"]
    F --> J["Chrome Browser SSO"]
    F --> K["Synchronisation du mot de passe Google"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["Droits d'administrateur local"]
    G --> O["Paramètres personnalisés / effacement / audit"]

    H --> P["Créer un nouveau profil ?"]
    H --> Q["Réutiliser le profil existant ?"]

2. Diviser GCPW en 4 couches facilite la compréhension

Les discussions sur GCPW deviennent compliquées parce que « la connexion », « la migration des profils » et « la gestion des appareils » ont tendance à être traitées comme un seul et même sujet. En pratique, il est plus rapide de les diviser en ces 4 couches.

Avec cette grille de lecture, il devient plus facile de repérer l’origine de décalages comme « on a installé GCPW mais BitLocker ne s’applique pas » ou « on s’est connecté avec Google mais les données utilisateur existantes sont introuvables ».

Structure en couches

flowchart LR
    subgraph Id["Identité / session"]
        A["Compte Google"]
        B["Validation en 2 étapes"]
    end

    subgraph SignIn["Couche de connexion"]
        C["GCPW"]
    end

    subgraph Profile["Couche de profil Windows"]
        D["Profil local existant"]
        E["Profil AD-backed existant"]
        F["Nouveau profil Windows"]
    end

    subgraph Mgmt["Couche de gestion"]
        G["Windows device management"]
        H["BitLocker / mises à jour / droits d'administrateur local"]
        I["Paramètres personnalisés / effacement / audit"]
    end

    subgraph Config["Couche de configuration"]
        J["Admin console"]
        K["Paramètres du Registre"]
    end

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

3. Comment cela fonctionne dans un environnement Windows

3.1 Vérifier d’abord les prérequis de compatibilité

Dans un environnement Windows, l’important est avant tout de ne pas trébucher sur les prérequis.

Les points les plus faciles à négliger ici sont Chrome et l’absence de prise en charge d’ARM. Comme il s’agit d’un sujet lié aux postes Windows, on a tendance à ne regarder que l’OS ; mais GCPW dépend aussi de Chrome pour lancer l’écran de connexion Google, donc l’absence de Chrome ou un emplacement incorrect peuvent également faire échouer la connexion.

3.2 De la première connexion à la connexion quotidienne

En simplifiant le déroulement après le déploiement de GCPW, on obtient ceci.

1. GCPW est installé sur l’appareil
2. L’utilisateur se connecte pour la première fois avec son compte Google
3. GCPW associe un profil existant, ou crée un nouveau profil Windows
4. Ensuite, l’utilisateur se connecte via l’écran de connexion Windows habituel
5. Cependant, lors d’événements de sécurité tels qu’un changement de mot de passe Google ou l’expiration d’une session, l’écran de connexion Google est de nouveau requis

Le point important ici est que ce n’est pas le cas que « l’on passe systématiquement par la boîte de dialogue Google à chaque fois ». Lors de la première connexion ou de certains événements de sécurité, l’authentification côté Google passe au premier plan, mais au quotidien, la connexion se fait principalement via l’écran de connexion Windows.

Le déroulement de la première connexion

sequenceDiagram
    participant U as Utilisateur
    participant W as Écran de connexion Windows
    participant G as Connexion Google
    participant P as GCPW
    participant R as Profil existant / nouveau
    participant C as Chrome Browser

    U->>W: Choisit Add Work Account ou un compte existant
    W->>G: Lance l'écran d'authentification Google
    G->>U: E-mail / mot de passe / 2SV
    U->>G: Saisit ses identifiants
    G->>P: Authentification réussie

    alt Associer un profil existant
        P->>R: Trouve et associe le profil local / AD existant
    else Créer un nouveau profil
        P->>R: Crée un nouveau profil Windows
    end

    P->>C: Transmet l'état de connexion Google
    P->>W: Démarre la session Windows

3.3 Synchronisation du mot de passe, mode hors ligne et validation en 2 étapes

Pour exploiter GCPW de façon stable dans un environnement Windows, le tout premier point à examiner est en réalité la gestion des mots de passe.

Le guide officiel de Google suppose lui aussi que, sur les appareils utilisant GCPW, le mot de passe Google et le mot de passe Windows restent synchronisés. De plus, on part du principe que les utilisateurs gèrent habituellement le mot de passe côté Google en priorité. C’est pourquoi cela s’accorde mal avec une conception qui repose sur le changement du mot de passe Windows via Ctrl + Alt + Suppr.

Comment penser la synchronisation du mot de passe

flowchart LR
    A["Changement du mot de passe Google"] --> B{"L'appareil est-il en ligne ?"}
    B -- Oui --> C["GCPW synchronise le mot de passe côté Windows"]
    C --> D["La prochaine connexion réussit"]

    B -- Non --> E["La synchronisation est différée"]
    E --> F["Nouvelle synchronisation à la prochaine connexion en ligne"]

    G["Changement du mot de passe uniquement côté AD / Entra ID"] --> H["Décalage entre Google et Windows"]
    H --> I["Password incorrect / erreur de synchronisation"]

Voici ce qui revient le plus souvent en pratique :

• On pense avoir changé le mot de passe côté Google, mais l’appareil était hors ligne et ne s’est pas encore synchronisé côté Windows
• À l’inverse, on a d’abord réinitialisé uniquement côté AD / Entra ID, créant un décalage avec le côté Google
• La complexité du mot de passe côté Google était plus faible que celle exigée par Windows / AD, et l’utilisateur l’a changé pour une chaîne qui ne satisfait pas les exigences côté Windows

C’est pourquoi il faut décider au minimum ces points avant le déploiement.

• Le pilotage du mot de passe est-il confié à Google ?
• Ou bien est-il synchronisé vers Google depuis AD / Entra ID / un autre outil ?
• La complexité du mot de passe est-elle alignée sur des exigences au moins équivalentes à celles de Windows ?

Mode hors ligne et validation en 2 étapes

GCPW permet bien la connexion hors ligne. Cependant, il est possible de configurer le nombre de jours autorisés depuis la dernière connexion en ligne. Déployer sans avoir décidé ce point mène facilement à l’un de ces deux écueils : trop strict, ce qui gêne le terrain, ou trop permissif, ce qui augmente le risque en cas de perte de l’appareil.

Par ailleurs, la validation en 2 étapes fonctionne, mais il est plus sûr d’en informer le terrain à l’avance sur les points suivants.

• Les clés de sécurité USB ne sont pas prises en charge par GCPW
• Prévoir à la place des méthodes comme Google prompt, Google Authenticator ou les codes de secours (backup codes)
• Dans une configuration qui n’autorise que les clés de sécurité, les utilisateurs risquent de ne plus pouvoir se connecter à Windows

4. Comment traiter les profils locaux / AD existants

C’est ici que les migrations GCPW connaissent le plus d’incidents.

Lorsqu’un appareil dispose déjà d’un profil Windows professionnel, le fait que GCPW l’associe et le réutilise, ou crée un nouveau profil Windows, change considérablement l’expérience utilisateur et la difficulté de la migration.

Les 3 scénarios types

Selon les indications de Google, pour associer un profil existant, on fait correspondre le nom de compte Windows ou le compte AD via un attribut personnalisé (custom attribute) côté Directory, ou l’on utilise des paramètres de Registre basés sur le SID côté appareil. Autrement dit, il s’agit d’un travail de migration qui exige une conception préalable, et non d’une opération où « l’utilisateur choisit vaguement sur place après l’installation ».

Plus important encore, il faut connaître le comportement en l’absence d’association.

• Les utilisateurs d’un profil local existant peuvent conserver la possibilité d’accéder à l’ancien profil
• Pour les utilisateurs AD existants, si un nouveau profil est créé pour la connexion Google, ils peuvent ne pas accéder directement au profil professionnel attendu

Schéma de décision pour traiter les profils existants

flowchart TD
    A["L'appareil dispose d'un profil Windows professionnel existant"] --> B{"Voulez-vous continuer à utiliser les données / paramètres tels quels ?"}
    B -- Oui --> C["Concevoir l'association avec le profil existant"]
    B -- Non --> D["Laisser GCPW créer un nouveau profil Windows"]

    C --> E{"Type de profil existant"}
    E -- Local --> F["Correspondance via Local Windows accounts, etc."]
    E -- AD-backed --> G["Correspondance via AD accounts, etc."]

    G --> H["Vérifier la connectivité à l'AD lors de la première connexion"]
    F --> I["Clarifier le nom d'utilisateur Windows / les restrictions par appareil"]
    D --> J["Mener la migration des données existantes dans un plan distinct"]

5. Différences entre GCPW seul et GCPW + Windows device management

Lorsqu’on parle de GCPW, il est en pratique très important de distinguer ces deux cas.

Tableau comparatif

Google recommande officiellement, pour les appareils fournis par l’entreprise, la configuration combinant GCPW et Windows device management. À l’inverse, si vous disposez déjà d’une autre plateforme de gestion et souhaitez uniquement l’expérience de connexion Google, l’approche GCPW seul est celle à retenir.

Une contrainte discrète mais importante en cas d’utilisation combinée

Lorsqu’on combine avec Windows device management, il est plus prudent de comprendre au préalable que seul un utilisateur peut être enrollé (enroll) par appareil.

Google présente officiellement cela comme une contrainte côté Windows 10 / 11. Même dans une configuration où plusieurs utilisateurs peuvent se connecter à cet appareil via GCPW, seul le premier utilisateur est enrollé dans Windows device management. De plus, des paramètres au niveau de l’appareil comme BitLocker, les mises à jour ou les droits d’administrateur local affectent aussi les autres utilisateurs de cet appareil.

Le problème du premier utilisateur

flowchart TD
    A["Configuration de l'appareil"] --> B["Premier utilisateur connecté via GCPW"]
    B --> C["Enroll dans Windows device management"]
    C --> D["Les paramètres au niveau de l'appareil s'appliquent"]
    D --> E["BitLocker / mises à jour / droits d'administrateur local / paramètres personnalisés"]

    F["Un autre utilisateur se connectant plus tard via GCPW"] --> G["La connexion Windows elle-même est possible"]
    G --> H["Mais aucun utilisateur supplémentaire n'est enrollé"]
    H --> I["Les paramètres au niveau de l'appareil fonctionnent sur la base du premier enroll"]

Là où cela pose problème, c’est le cas où la personne chargée du kitting se connecte en premier via GCPW. Si c’est le compte de la personne chargée de la configuration, et non celui de l’employé qui utilisera réellement l’appareil, qui est enrollé, un incident survient plus tard : les paramètres prévus ne s’appliquent pas.

6. Ce qu’il faut décider avant le déploiement

Ce qui compte vraiment, dans un déploiement de GCPW, ce n’est pas tant l’exécution de l’installateur elle-même que la conception préalable. En reformulant le guide officiel de façon pratique, voici au moins 6 points qu’il vaut mieux avoir décidés à l’avance.

flowchart LR
    A["À décider avant le déploiement"] --> B["Pilotage du mot de passe"]
    B --> C["Exigences de complexité"]
    C --> D["Domaines autorisés"]
    D --> E["Traitement des profils existants"]
    E --> F["Droits d'administrateur pour le support"]
    F --> G["Politique de staging pour l'inscription automatique (enrollment)"]
    G --> H["Nombre de jours hors ligne autorisés"]

Mauvaises approches et approches pratiques

Trois points particulièrement faciles à négliger

1. Les domaines autorisés sont obligatoires

Avec GCPW, tant que vous n’avez pas décidé quels domaines de compte sont autorisés à se connecter, les utilisateurs ne peuvent pas entrer. Cela peut se configurer aussi bien via l’Admin console que via la valeur de Registre domains_allowed_to_login, mais dans les deux cas, ce réglage est obligatoire.

2. Répartir les rôles entre l’Admin console et le Registre

Les anciens tutoriels se concentrent souvent sur la configuration par le Registre, mais aujourd’hui, la gestion via l’Admin console est la base. Cela dit, si vous souhaitez une granularité plus fine — par exemple des domaines autorisés différents selon l’appareil — le Registre reste parfois plus adapté.

3. Les paramètres de l’Admin console ne s’appliquent pas instantanément

Les paramètres de GCPW se synchronisent sur les appareils à un rythme d’environ une heure. « J’ai bien saisi le paramètre, mais il ne s’applique pas tout de suite » est une situation courante ; il est donc plus sûr d’en tenir compte, avec ce décalage, pendant le pilote.

7. Procédure de déploiement pratique

Voici, aussi condensé que possible, le déroulement pratique du déploiement de GCPW dans un environnement Windows.

Flux de déploiement

flowchart TD
    A["1. Vérifier le plan d'abonnement / les prérequis OS / Chrome"] --> B["2. Décider la stratégie de mot de passe et la complexité"]
    B --> C["3. Décider les domaines autorisés et les autres paramètres"]
    C --> D["4. Décider s'il faut associer les profils existants"]
    D --> E["5. Activer Windows device management si vous l'utilisez"]
    E --> F["6. Obtenir l'installateur depuis l'Admin console"]
    F --> G["7. Distribuer aux appareils / installer avec des droits d'administrateur"]
    G --> H["8. L'utilisateur effectue sa première connexion en ligne"]
    H --> I["9. Vérifier les détails de l'appareil / l'enrollment / les journaux"]

7.1 D’abord, décider la configuration

Voici ce qu’il faut décider en premier.

• Utiliser GCPW seul ?
• Utiliser GCPW + Windows device management ?
• Associer les profils existants ?
• Ou basculer avec de nouveaux profils ?

Cette décision vient en premier. Si vous distribuez seulement l’installateur sans avoir tranché ce point, vous vous retrouverez plus tard avec « la gestion des appareils prévue n’est pas possible » ou « les données utilisateur existantes n’ont pas été conservées ».

7.2 Décider les domaines autorisés et les options

Il existe deux méthodes de configuration.

• Admin console Adapté lorsqu’on veut diffuser les mêmes paramètres à l’ensemble de l’organisation. C’est aujourd’hui la méthode de base.
• Registre de l’appareil Adapté lorsqu’on veut différencier finement, appareil par appareil.

Si vous utilisez le Registre, domains_allowed_to_login est au minimum requis. Si vous combinez GCPW avec Windows device management, enable_dm_enrollment et validity_period_in_days deviennent aussi des points de décision ; pour une exploitation de type appareil partagé, enable_multi_user_login l’est également.

7.3 Obtenir et distribuer l’installateur

Récupérez l’installateur GCPW en 32 bits / 64 bits depuis l’Admin console et distribuez-le aux appareils. Dans le modèle de gestion actuel, un jeton propre à l’organisation (organization-specific token) est intégré à l’installateur téléchargé depuis l’Admin console, ce qui est aujourd’hui la référence la plus claire à retenir.

7.4 Installer

Pour une installation manuelle, voici un exemple.

# Version 64 bits
gcpwstandaloneenterprise64.exe /silent /install

# Version 32 bits
gcpwstandaloneenterprise.exe /silent /install

7.5 Exemple de configuration individuelle via le Registre

Voici un exemple pour saisir, appareil par appareil, des valeurs non configurées dans l’Admin console.

Remarque : si le même paramètre existe à la fois dans l’Admin console et dans le Registre, c’est l’Admin console qui l’emporte.

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 Pour réutiliser un profil existant, créer d’abord la définition d’association

Si vous voulez réutiliser un profil local / AD existant, préparez d’abord la correspondance entre le compte Google de l’utilisateur et son compte Windows, par exemple via un attribut personnalisé côté Directory. Si vous repoussez cette étape et laissez les utilisateurs se connecter en premier, vous risquez de devoir revenir en arrière après qu’un nouveau profil a déjà été créé.

7.7 Vérifications après la première connexion en ligne

Après la première connexion, vérifiez les points suivants.

• L’utilisateur accède-t-il au profil Windows attendu ?
• En cas d’utilisation combinée avec Windows device management, l’enroll a-t-il bien été effectué pour l’utilisateur prévu ?
• Les détails de l’appareil apparaissent-ils dans l’Admin console ?
• La synchronisation des stratégies est-elle terminée ?

8. Pièges fréquents et diagnostic sous Windows

Les problèmes liés à GCPW se rangent presque toujours dans l’une des lignes de ce tableau.

Le déroulement du diagnostic

flowchart TD
    A["Un problème survient avec GCPW"] --> B{"Que se passe-t-il ?"}
    B -- Connexion refusée --> C["Vérifier les domaines autorisés"]
    B -- L'écran Google n'apparaît pas --> D["Vérifier la présence / le chemin / l'antivirus de Chrome"]
    B -- Password incorrect --> E["Vérifier l'état de synchronisation Google / Windows"]
    B -- Données existantes introuvables --> F["Vérifier l'association de profil"]
    B -- Pas d'entrée dans device management --> G["Vérifier le premier utilisateur enrollé"]
    C --> H["Vérifier l'Admin console / le Registre"]
    D --> I["Réinstaller Chrome"]
    E --> J["Réorganiser la gestion des mots de passe"]
    F --> K["Revérifier l'attribut personnalisé / le mappage SID"]
    G --> L["Revoir la procédure de staging"]

Où récupérer les journaux sous Windows

Pour investiguer GCPW sous Windows, commencez par l’Observateur d’événements.

• Journaux Windows > Application
• La source de l’événement est GCPW

Cela permet déjà de consulter l’essentiel des informations de base. Pour aller plus loin, vous pouvez activer la journalisation détaillée (verbose logging) via le Registre.

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 vous voulez aussi examiner Windows device management, consultez également, au besoin, l’emplacement suivant.

• Journaux des applications et des services > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

Pour vérifier rapidement la prise en compte des changements

Après avoir corrigé les domaines autorisés ou une stratégie, si vous voulez vérifier rapidement la prise en compte, Google indique la méthode consistant à exécuter GoogleUpdateTaskMachineUA depuis le Planificateur de tâches pour forcer une synchronisation. Pendant le pilote, garder cette procédure sous la main accélère le diagnostic.

9. Pour quelles organisations est-ce adapté, ou non

Cas où c’est adapté

Cas où ce n’est pas adapté

10. Conclusion

L’astuce pour bien utiliser GCPW dans un environnement Windows est de ne pas considérer ses fonctionnalités comme un bloc monolithique.

• GCPW est le mécanisme pour entrer dans Windows avec Google
• L’association avec un profil existant est le mécanisme de migration
• Windows device management est le mécanisme d’exploitation des appareils

En distinguant clairement ces trois éléments, les décisions de déploiement deviennent beaucoup plus simples.

Voici les 5 points particulièrement importants en pratique.

1. Décider d’abord la gestion des mots de passe
2. Décider d’abord les domaines autorisés
3. Décider s’il faut réutiliser les profils existants
4. En cas d’utilisation de Windows device management, ne pas se tromper sur le premier utilisateur enrollé
5. Disposer d’une procédure de diagnostic construite autour de l’Observateur d’événements

GCPW est un outil pratique pour rapprocher la connexion Windows de Google. Mais ce qui compte vraiment n’est pas le moment où l’on exécute l’installateur, c’est la conception qui le précède. En consolidant ce point en amont, la connexion Google, la poursuite de l’utilisation des données existantes et la gestion des postes Windows s’articulent proprement.

Articles connexes

• Quand les privilèges d’administrateur sont-ils réellement nécessaires sous Windows ? - UAC, zones protégées et comment le repérer par la conception
• Accélérer la validation du développement d’applications Windows avec Windows Sandbox - Problèmes de droits d’administrateur, environnements propres et reproduction des manques de privilèges / ressources, organisés pour la pratique
• Qu’est-ce que ClickOnce ? - Le mécanisme, les mises à jour, et les cas où c’est adapté ou non, du point de vue de la pratique

Sujets connexes

• Sujets techniques Windows

Services liés à ce thème

• Développement d’applications Windows
• Conseil technique et revue de conception
• Nous contacter

Références

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

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que GCPW ?

GCPW (Google Credential Provider for Windows) est un mécanisme permettant de se connecter à Windows 10 / 11 avec un compte Google géré. Utilisé seul, son rôle principal se limite à la connexion Windows et à l'expérience SSO de Chrome Browser : ce n'est ni un simple « écran de connexion Google », ni un substitut complet à un domaine Windows. Les systèmes d'exploitation pris en charge sont Windows 10 / 11 Pro, Pro for Workstations, Enterprise et Education ; les appareils basés sur ARM ne sont pas pris en charge, et Chrome Browser 81 ou une version ultérieure doit être installé avec des droits d'administrateur.

GCPW seul permet-il de gérer BitLocker ou Windows Update ?

En principe, non, GCPW seul ne le permet pas. Utilisé seul, GCPW se limite à la connexion à Windows via Google, au SSO Chrome et à l'association avec un profil existant ; BitLocker, le contrôle de Windows Update, le contrôle des droits d'administrateur local, la distribution de paramètres personnalisés ou l'effacement à distance supposent tous une utilisation combinée avec Windows device management. Lorsqu'on combine les deux, une seule contrainte s'applique : sur un même appareil, seul le premier utilisateur peut être enrollé (enroll). Il faut donc veiller à ce que ce ne soit pas la personne chargée du kitting qui se connecte en premier et se retrouve enrollée par erreur.

GCPW permet-il de se connecter à Windows même hors ligne ?

Oui, la connexion hors ligne elle-même est possible. Cependant, la toute première connexion exige une connexion Internet, et sur un appareil joint à un AD sans profil AD-backed existant, il faut également pouvoir joindre l'AD lors de cette première connexion. Le nombre de jours d'autorisation hors ligne peut être défini via un paramètre comme validity_period_in_days ; si vous ne décidez pas à l'avance combien de jours sont autorisés depuis la dernière connexion en ligne, vous risquez soit d'être trop strict et de gêner le terrain, soit trop permissif et d'augmenter le risque en cas de perte de l'appareil.

Peut-on utiliser la validation en 2 étapes ou une clé de sécurité avec GCPW ?

La validation en 2 étapes fonctionne, mais les clés de sécurité USB ne sont pas prises en charge par GCPW. Il faut plutôt prévoir des méthodes comme Google prompt, Google Authenticator ou les codes de secours (backup codes). Dans une configuration qui n'autorise que les clés de sécurité, les utilisateurs risquent de ne plus pouvoir se connecter à Windows : il est donc plus sûr d'en informer le terrain avant le déploiement. Par ailleurs, la gestion des mots de passe suppose une synchronisation entre le côté Google et le côté Windows ; réinitialiser le mot de passe uniquement du côté AD / Entra ID en premier entraîne des incidents de connexion dus à cette désynchronisation.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.