Was ist GCPW? – Windows-Anmeldung mit Google-Authentifizierung

Bei Beratungen, die die Anmeldung an Windows-Geräten stärker auf Google ausrichten wollen, vermischen sich sehr häufig auf einmal folgende Themen.

• Zeigt GCPW nur „den Google-Anmeldebildschirm“ an, oder mehr?
• Was passiert mit bestehenden lokalen Profilen oder AD-Profilen?
• Kümmert es sich auch um Windows-Administratorrechte, BitLocker und die Update-Verwaltung?
• Wie verhalten sich die erste Anmeldung, der Offline-Betrieb, die Zwei-Faktor-Authentifizierung und Passwortänderungen?
• Kann es mit Active Directory koexistieren, oder ersetzt es Active Directory?

Wird das nachlässig zusammengefasst, driften die Erwartungen vor der Einführung auseinander, und Migration wie Ersteinrichtung werden anfälliger für Pannen.

GCPW ist weder ein bloßer „Google-Anmeldebildschirm“ noch ein vollständiger Ersatz für eine Windows-Domäne. In der Praxis wird die Lage übersichtlicher, wenn man die Google-Anmeldung an Windows, die Zuordnung zu bestehenden Profilen, den Passwort-/Sitzungsbetrieb auf Google-Seite und die gemeinsame Nutzung mit Windows device management getrennt betrachtet.

Dieser Artikel ordnet praxisorientiert und mit reichlich Mermaid-Diagrammen, was passiert, wenn Sie Google Credential Provider for Windows (GCPW) in einer Windows-10/11-Umgebung einsetzen: welche Konfigurationen sich eignen, die Einführungsschritte und die typischen Stolperfallen. Grundlage ist im Wesentlichen die offizielle Google-Workspace-Dokumentation, wie sie Stand März 2026 einsehbar war.

Die Diagramme sind konzeptionell. In Mermaid-fähigen Markdown-Umgebungen werden sie als Diagramme dargestellt.

1. Zuerst das Fazit

Vorab die Kernaussagen im Überblick.

• GCPW ist ein Mechanismus, mit dem sich Nutzer mit einem verwalteten Google-Konto bei Windows 10/11 anmelden.
• Im Alleinbetrieb stehen die Windows-Anmeldung und das SSO-Erlebnis im Chrome Browser im Mittelpunkt von GCPW.
• Wer auch Windows-Updates, BitLocker, lokale Administratorrechte, benutzerdefinierte Einstellungen und Wipe abdecken möchte, sollte praktisch von einer gemeinsamen Nutzung mit Windows device management ausgehen.
• In Umgebungen mit bestehenden lokalen oder AD-Profilen bleibt die Migration leicht stecken, wenn nicht vorab entschieden wird, ob ein bestehendes Profil zugeordnet oder ein neues Profil angelegt wird.
• Die erste Anmeldung setzt eine Online-Verbindung voraus. Bei einem AD-beigetretenen Gerät ohne bestehendes AD-basiertes Profil ist zudem wichtig, dass bei der ersten Anmeldung eine Verbindung zu AD möglich ist.
• Die Offline-Anmeldung ist möglich, aber ohne vorherige Festlegung, wie viele Tage sie erlaubt sein soll, gerät der Betrieb ins Wanken.
• Zwei-Faktor-Authentifizierung lässt sich nutzen, aber USB-Sicherheitsschlüssel werden von GCPW nicht unterstützt.
• Wird der Passwortbetrieb nicht vorab festgelegt, führen Diskrepanzen zwischen Google- und Windows-Seite zu Anmeldeproblemen. Besonders gefährlich ist ein Betrieb, bei dem nur auf der AD-/Entra-ID-Seite zuerst zurückgesetzt wird.
• GCPW behandelt ausschließlich Google als Identitätsanbieter – wer die Konfiguration darauf aufbaut, vermeidet Fehleinschätzungen.

Kurz gesagt ist GCPW „ein Mechanismus, um mit Google in Windows zu gelangen“ – wer den gesamten Windows-Endpunktbetrieb in der Hand behalten will, sollte konsequenterweise zusammen mit Windows device management planen.

Begriffe, die dieser Artikel verwendet

Da sich Begriffe aus der Google- und der Windows-Welt vermischen, hier vorab eine Übersicht.

Zunächst die Einordnung auf einen Blick

flowchart TD
    A["Google-Konten auf Windows-Geräten nutzen"] --> B{"Was soll erreicht werden?"}
    B --> C["Google-Anmeldung an Windows"]
    B --> D["Zentrale Verwaltung der Windows-Einstellungen"]
    B --> E["Migration bestehender Profile"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["Design der Zuordnung bestehender lokaler / AD-Profile"]

    F --> I["Windows-Anmeldung"]
    F --> J["Chrome Browser SSO"]
    F --> K["Google-Passwortabgleich"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["Lokale Administratorrechte"]
    G --> O["Benutzerdefinierte Einstellungen / Wipe / Audit"]

    H --> P["Neues Profil anlegen?"]
    H --> Q["Bestehendes Profil wiederverwenden?"]

Dieses Diagramm leitet vom „Ziel“ zum „passenden Werkzeug“ über. Wählen Sie von links nach rechts, was Sie erreichen wollen, ergibt sich der zuständige Mechanismus (GCPW / Windows device management / Profildesign). Hier gibt es nur einen Punkt zu verstehen: Gerätebezogene Verwaltung wie BitLocker oder Windows Update taucht in der GCPW-Spalte nicht auf.

2. GCPW lässt sich leichter verstehen, wenn man es in 4 Schichten aufteilt

GCPW-Diskussionen werden kompliziert, weil „Anmeldung“, „Profilmigration“ und „Geräteverwaltung“ leicht als ein und dieselbe Sache behandelt werden. In der Praxis kommt man schneller voran, wenn man diese vier Schichten trennt.

Mit dieser Sichtweise werden die Ursachen für Diskrepanzen wie „GCPW ist installiert, aber BitLocker greift nicht“ oder „Anmeldung mit Google funktioniert, aber bestehende Nutzerdaten sind nicht sichtbar“ leichter erkennbar.

Die Schichtstruktur

flowchart LR
    subgraph Id["ID / Sitzung"]
        A["Google-Konto"]
        B["Zwei-Faktor-Authentifizierung"]
    end

    subgraph SignIn["Anmeldeschicht"]
        C["GCPW"]
    end

    subgraph Profile["Windows-Profilschicht"]
        D["Bestehendes lokales Profil"]
        E["Bestehendes AD-basiertes Profil"]
        F["Neues Windows-Profil"]
    end

    subgraph Mgmt["Verwaltungsschicht"]
        G["Windows device management"]
        H["BitLocker / Updates / lokale Administratorrechte"]
        I["Benutzerdefinierte Einstellungen / Wipe / Audit"]
    end

    subgraph Config["Konfigurationsschicht"]
        J["Admin console"]
        K["Registry-Einstellungen"]
    end

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

Während das Diagramm aus Kapitel 1 vom Ziel zum Werkzeug führte, ordnet dieses Diagramm dieselben Elemente danach an, zu welcher Schicht sie gehören und was wovon abhängt. Zu erkennen ist, dass alle Pfeile durch GCPW (die Anmeldeschicht) verlaufen und sich der Pfeil von GCPW zur Profilschicht in drei Zweige aufteilt. Diese Verzweigung ist genau das Design aus Kapitel 4: „Bestehendes Profil zuordnen oder neu anlegen?“

3. Wie es sich in einer Windows-Umgebung verhält

3.1 Zuerst die Systemvoraussetzungen klären

In einer Windows-Umgebung ist zunächst wichtig, nicht an den Voraussetzungen zu scheitern.

Unterschiede bei den unterstützten Editionen (die erste Hürde bei der Einführungsentscheidung)

Zwischen „GCPW allein“ und der „gemeinsamen Nutzung mit Windows device management“ unterscheiden sich die benötigten Editionen. Die von Googles offizieller Dokumentation (Overview: Enhanced desktop security for Windows) genannten unterstützten Editionen sind folgende.

So liest sich die Tabelle: Für die reine Anmeldung mit GCPW reicht praktisch jede Edition. Wer dagegen auch BitLocker, Windows Update und lokale Administratorrechte verwalten will, benötigt eine unterstützte Edition wie Business Plus, Enterprise Standard oder höher, oder Cloud Identity Premium. Besonders bei Business Starter / Business Standard und Cloud Identity Free lässt sich GCPW zwar nutzen, Windows device management jedoch nicht. Die Anfrage „GCPW ist installiert, aber BitLocker lässt sich nicht verwalten“ hat manchmal genau hier ihre Ursache.

Da sich die Editionszusammenstellung ändern kann, prüfen Sie vor Vertragsabschluss unbedingt die aktuelle Vergleichstabelle in der offiziellen Dokumentation.

Leicht übersehen werden hier Chrome und die fehlende ARM-Unterstützung. Da es um Windows-Geräte geht, richtet sich der Blick meist nur auf das Betriebssystem, doch GCPW hängt beim Start des Google-Anmeldebildschirms auch von Chrome ab – fehlt Chrome oder ist es falsch platziert, schlägt die Anmeldung ebenfalls fehl.

3.2 Von der ersten Anmeldung bis zur alltäglichen Anmeldung

Vereinfacht sieht der Ablauf nach der GCPW-Einführung so aus.

1. GCPW wird auf dem Gerät installiert
2. Der Nutzer meldet sich erstmals mit seinem Google-Konto an
3. GCPW ordnet ein bestehendes Profil zu oder legt ein neues Windows-Profil an
4. Danach erfolgt die Anmeldung über den gewohnten Windows-Anmeldebildschirm
5. Bei Sicherheitsereignissen wie einer Google-Passwortänderung oder einem abgelaufenen Sitzungstoken wird jedoch erneut der Google-Anmeldebildschirm verlangt

Wichtig ist hier: Es ist nicht so, dass jedes Mal zwingend über den Google-Dialog angemeldet wird. Bei der ersten Anmeldung und bei bestimmten Sicherheitsereignissen tritt die Google-seitige Authentifizierung in den Vordergrund, im Alltag erfolgt die Anmeldung jedoch überwiegend über den Windows-Anmeldebildschirm.

Der Ablauf der ersten Anmeldung

sequenceDiagram
    participant U as Benutzer
    participant W as Windows-Anmeldebildschirm
    participant G as Google-Anmeldung
    participant P as GCPW
    participant R as Bestehendes / neues Profil
    participant C as Chrome Browser

    U->>W: Wählt „Add Work Account“ oder ein bestehendes Konto
    W->>G: Startet den Google-Authentifizierungsbildschirm
    G->>U: E-Mail-Adresse / Passwort / 2SV
    U->>G: Gibt die Anmeldedaten ein
    G->>P: Authentifizierung erfolgreich

    alt Bestehendes Profil zuordnen
        P->>R: Findet das bestehende lokale / AD-Profil und ordnet es zu
    else Neu anlegen
        P->>R: Legt ein neues Windows-Profil an
    end

    P->>C: Übergibt den Google-Anmeldestatus
    P->>W: Startet die Windows-Sitzung

In diesem Diagramm gibt es nur an einer einzigen Stelle eine Verzweigung: Wird das bestehende Profil zugeordnet, oder wird ein neues angelegt? Das entscheidet sich im Moment der ersten Anmeldung, und ein nachträgliches „doch lieber das bestehende Profil“ bedeutet Mehrarbeit. Genau deshalb wird das Zuordnungsdesign aus Kapitel 4 abgeschlossen, bevor der Installer verteilt wird.

3.3 Passwortabgleich, Offline-Betrieb und Zwei-Faktor-Authentifizierung

Wer GCPW in einer Windows-Umgebung stabil betreiben möchte, sollte sich tatsächlich zuerst den Passwortbetrieb ansehen.

Auch Googles offizieller Leitfaden setzt voraus, dass auf Geräten mit GCPW das Google-Passwort und das Windows-Passwort synchron gehalten werden. Zudem wird davon ausgegangen, dass Nutzer in der Regel das Google-seitige Passwort primär verwalten. Deshalb passt das schlecht zu einem Design, das auf die Windows-Passwortänderung über Strg+Alt+Entf setzt.

Wie der Passwortabgleich zu verstehen ist

flowchart LR
    A["Google-Passwort geändert"] --> B{"Ist das Gerät online?"}
    B -- Ja --> C["GCPW gleicht das Windows-Passwort ab"]
    C --> D["Nächste Anmeldung erfolgreich"]

    B -- Nein --> E["Abgleich zurückgestellt"]
    E --> F["Erneuter Abgleich beim nächsten Online-Kontakt"]

    G["Passwortänderung nur auf AD- / Entra-ID-Seite"] --> H["Diskrepanz zwischen Google und Windows"]
    H --> I["Password incorrect / Abgleichfehler"]

Dieses Diagramm zeigt zwei Abläufe, oben und unten. Der obere Ablauf (Änderung auf Google-Seite) wird bei Online-Verbindung sofort abgeglichen, und selbst offline holt der Abgleich beim nächsten Online-Kontakt auf. Der untere Ablauf (Änderung nur auf AD-/Entra-ID-Seite) wird dagegen niemals abgeglichen, egal wie lange man wartet. Beim Erstellen eines Passwort-Reset-Verfahrens ist es praxisnah, diesen unteren Ablauf ausdrücklich als verbotenen Schritt zu kennzeichnen.

In der Praxis kommt häufig Folgendes vor.

• Das Passwort wurde vermeintlich auf Google-Seite geändert, aber das Gerät war offline und hat noch nicht mit der Windows-Seite synchronisiert
• Umgekehrt wurde nur auf der AD-/Entra-ID-Seite zuerst zurückgesetzt, wodurch eine Diskrepanz zur Google-Seite entstand
• Die Passwortkomplexität auf Google-Seite war schwächer als bei Windows/AD, sodass das Passwort auf eine Zeichenfolge geändert wurde, die die Windows-Anforderungen nicht erfüllt

Deshalb muss vor der Einführung mindestens Folgendes festgelegt werden.

• Liegt die Passworthoheit bei Google,
• oder wird von AD / Entra ID / einem anderen Tool zu Google synchronisiert?
• Wird die Passwortkomplexität mindestens auf das Windows-Niveau abgestimmt?

Der dritte Punkt, die Komplexität, wird in der Google Admin console unter „Sicherheit“ → „Authentifizierung“ → „Passwortverwaltung“ je Organisationseinheit konfiguriert. Festlegen lassen sich hier jedoch nur das Kontrollkästchen „Sichere Passwörter erzwingen“ sowie die Mindest- und Höchstzeichenzahl (8 bis 100 Zeichen), ob eine Wiederverwendung zulässig ist, und die Gültigkeitsdauer. Eine Vorgabe der Zeichenarten wie bei der Active-Directory-Passwortrichtlinie – „so und so viele Arten aus Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen“ – ist nicht möglich. Google bewertet nämlich nicht die Zusammensetzung der Zeichenarten, sondern die Gesamtstärke des Passworts.

In der Praxis läuft das darauf hinaus, auf Google-Seite mindestens die gleiche Mindestzeichenzahl wie auf AD-Seite einzustellen und „Sichere Passwörter erzwingen“ zu aktivieren. Sind die Anforderungen an die Zeichenarten auf AD-Seite streng, kann ein auf Google-Seite akzeptiertes Passwort auf Windows-Seite trotzdem abgelehnt werden – prüfen Sie diese Kombination unbedingt im Pilotbetrieb.

Offline-Betrieb und Zwei-Faktor-Authentifizierung

Die Offline-Anmeldung ist mit GCPW grundsätzlich möglich. Konfigurieren lässt sich jedoch, wie viele Tage seit der letzten Online-Anmeldung zulässig sind. Wird das bei der Einführung nicht festgelegt, tendiert man leicht entweder zu einer zu strengen Regelung, die den Betrieb vor Ort behindert, oder zu einer zu lockeren, die das Risiko bei Geräteverlust erhöht.

Zwei-Faktor-Authentifizierung lässt sich zudem nutzen, aber Folgendes sollte vorab kommuniziert werden.

• USB-Sicherheitsschlüssel werden von GCPW nicht unterstützt
• Stattdessen sind Verfahren wie Google-Eingabeaufforderung, Google Authenticator und Backup-Codes vorzusehen
• In einer Konfiguration, die ausschließlich Sicherheitsschlüssel zulässt, können Nutzer möglicherweise nicht mehr bei Windows anmelden

4. Wie mit bestehenden lokalen / AD-Profilen umzugehen ist

Hier passieren bei GCPW-Migrationen die meisten Pannen.

Existiert auf dem Gerät bereits ein geschäftlich genutztes Windows-Profil, hängt es stark vom Nutzererlebnis und der Migrationsschwierigkeit ab, ob GCPW dieses zuordnet und weiterverwendet oder ein neues Windows-Profil anlegt.

Die drei typischen Muster

Auch Googles Anleitung sieht vor, beim Zuordnen bestehender Profile Windows-Kontonamen oder AD-Konten über ein Custom Attribute auf Directory-Seite zuzuordnen oder SID-basierte Registry-Einstellungen auf dem Gerät zu nutzen. Mit anderen Worten: Das ist eine Migrationsaufgabe, die eine vorherige Planung erfordert – kein Betrieb, bei dem der Nutzer nach der Installation einfach spontan auswählt.

Noch wichtiger ist das Verhalten, wenn keine Zuordnung erfolgt.

• Nutzer bestehender lokaler Profile behalten unter Umständen weiterhin die Möglichkeit, in das alte Profil zu gelangen
• Bestehende AD-Nutzer gelangen möglicherweise nicht ohne Weiteres in das erwartete Arbeitsprofil, sobald ein neues Profil für die Google-Anmeldung angelegt wird

Entscheidungsdiagramm für den Umgang mit bestehenden Profilen

flowchart TD
    A["Gerät hat ein bestehendes geschäftliches Windows-Profil"] --> B{"Sollen Daten / Einstellungen unverändert genutzt werden?"}
    B -- Ja --> C["Zuordnung des bestehenden Profils planen"]
    B -- Nein --> D["GCPW ein neues Windows-Profil anlegen lassen"]

    C --> E{"Art des bestehenden Profils"}
    E -- Lokal --> F["Zuordnung z. B. über Local Windows accounts"]
    E -- AD-basiert --> G["Zuordnung z. B. über AD accounts"]

    G --> H["AD-Konnektivität bei der ersten Anmeldung prüfen"]
    F --> I["Windows-Benutzernamen / geräteweise Einschränkungen klären"]
    D --> J["Migration bestehender Daten separat planen"]

Diese Entscheidung muss nur einmal pro Gerätegruppe getroffen werden. Ist die erste Verzweigung (sollen bestehende Daten weiterverwendet werden) auf Gerätegruppenebene festgelegt, läuft alles Weitere entweder auf die Erstellung der Zuordnungsdefinition oder auf einen Datenmigrationsplan hinaus. Wird die Entscheidung vor Ort gerätweise getroffen, mischen sich innerhalb derselben Gerätegruppe neue Profile und Zuordnungen, und der Support wird unvorhersehbar.

5. Der Unterschied zwischen GCPW allein und GCPW + Windows device management

Bei Diskussionen über GCPW ist es in der Praxis sehr wichtig, diese beiden Fälle zu trennen.

Vergleichstabelle

Auch offiziell empfiehlt Google für firmeneigene Geräte die Konfiguration mit gemeinsamer Nutzung von GCPW und Windows device management. Ist umgekehrt bereits eine andere Verwaltungsplattform vorhanden und nur das Google-Anmeldeerlebnis erwünscht, ist GCPW allein die passende Überlegung.

Eine unscheinbare, aber wichtige Einschränkung bei gemeinsamer Nutzung

Bei gemeinsamer Nutzung mit Windows device management ist es sicherer, vorab zu verstehen, dass pro Gerät nur ein einziger Nutzer enrollt werden kann.

Auch offiziell wird dies als Einschränkung auf Seiten von Windows 10/11 beschrieben. Selbst wenn mehrere Nutzer sich über GCPW an diesem Gerät anmelden können, wird nur der erste Nutzer in Windows device management enrollt. Zudem wirken sich gerätebezogene Einstellungen wie BitLocker, Updates und lokale Administratorrechte auch auf die übrigen Nutzer dieses Geräts aus.

Das Problem des ersten Nutzers

flowchart TD
    A["Gerät wird eingerichtet"] --> B["Erster Nutzer, der sich mit GCPW anmeldet"]
    B --> C["Enrollment in Windows device management"]
    C --> D["Gerätebezogene Einstellungen werden angewendet"]
    D --> E["BitLocker / Updates / lokale Administratorrechte / benutzerdefinierte Einstellungen"]

    F["Weiterer Nutzer, der sich später über GCPW anmeldet"] --> G["Windows-Anmeldung an sich ist möglich"]
    G --> H["Aber es werden keine weiteren Nutzer enrollt"]
    H --> I["Gerätebezogene Einstellungen basieren auf dem ersten Enrollment"]

Wo sich das auswirkt, ist das Problem, dass das Kitting-Personal sich als Erstes über GCPW anmeldet. Wird statt des Mitarbeiters, der das Gerät eigentlich nutzen soll, das Konto der einrichtenden Person enrollt, kommt es später zur Panne, dass die beabsichtigten Einstellungen nicht greifen.

6. Was vor der Einführung festzulegen ist

Was sich bei der GCPW-Einführung später auszahlt, ist weniger die Ausführung des Installers selbst als vielmehr die vorherige Planung. Übersetzt man den offiziellen Leitfaden in die Praxis, sollten mindestens diese sechs Punkte vorab festgelegt werden.

flowchart LR
    A["Vor der Einführung festlegen"] --> B["Passworthoheit"]
    B --> C["Komplexitätsanforderungen"]
    C --> D["Erlaubte Domänen"]
    D --> E["Umgang mit bestehenden Profilen"]
    E --> F["Administratorrechte für den Support"]
    F --> G["Staging-Strategie für das automatische Enrollment"]
    G --> H["Erlaubte Offline-Tage"]

Die Reihenfolge in diesem Diagramm hat eine Bedeutung. Von links nach rechts sind die Punkte in der Reihenfolge angeordnet, in der die Entscheidung des einen die Entscheidung des nächsten erst ermöglicht. Die Komplexität etwa lässt sich nicht festlegen, solange nicht entschieden ist, ob die Passworthoheit bei Google oder bei AD liegt. Umgekehrt gilt: Wird der Installer verteilt, ohne einen dieser Punkte in dieser Reihenfolge geklärt zu haben, bleiben alle nachfolgenden Entscheidungen offen, während die Zahl der Geräte weiter wächst.

Der schlechte Weg und der praxistaugliche Weg

Drei besonders leicht übersehene Punkte

1. Erlaubte Domänen sind Pflicht

Bei GCPW können sich Nutzer erst anmelden, wenn festgelegt ist, welche Domänen für die Anmeldung zugelassen sind. Konfigurieren lässt sich das sowohl über die Admin console als auch über den Registry-Wert domains_allowed_to_login – in jedem Fall ist dieser Schritt Pflicht.

2. Admin console und Registry haben getrennte Rollen

In älteren Erläuterungen dreht sich vieles um die Registry-Konfiguration, doch heute ist die Verwaltung über die Admin console der Standard. Wer jedoch feinere Granularität möchte – etwa unterschiedliche erlaubte Domänen je Gerät –, für den eignet sich in manchen Fällen die Registry besser.

3. Einstellungen der Admin console wirken nicht sofort

GCPW-Einstellungen werden etwa im Stundentakt mit den Geräten synchronisiert. „Die Einstellung wurde vorgenommen, wirkt aber nicht sofort“ ist üblich – im Pilotbetrieb ist es daher sicherer, diese Verzögerung von vornherein einzuplanen.

7. Praxisorientiertes Einführungsverfahren

Hier wird der Ablauf für die praktische Einführung von GCPW in einer Windows-Umgebung so knapp wie möglich zusammengefasst.

Einführungsablauf

flowchart TD
    A["1. Lizenzplan / OS / Chrome-Anforderungen prüfen"] --> B["2. Passwortstrategie und Komplexität festlegen"]
    B --> C["3. Erlaubte Domänen und weitere Einstellungen festlegen"]
    C --> D["4. Notwendigkeit der Zuordnung bestehender Profile klären"]
    D --> E["5. Bei Nutzung von Windows device management aktivieren"]
    E --> F["6. Installer aus der Admin console beziehen"]
    F --> G["7. An Geräte verteilen / mit Administratorrechten installieren"]
    G --> H["8. Nutzer führt erste Online-Anmeldung durch"]
    H --> I["9. Gerätedetails / Enrollment / Protokolle prüfen"]

7.1 Zuerst die Konfiguration festlegen

Zuerst ist Folgendes festzulegen.

• Soll GCPW allein genutzt werden?
• Soll GCPW + Windows device management genutzt werden?
• Sollen bestehende Profile zugeordnet werden?
• Oder erfolgt der Umstieg mit neuen Profilen?

Diese Entscheidung kommt zuerst. Wird nur der Installer verteilt, ohne dies festzulegen, kommt es später zu „die erwartete Geräteverwaltung funktioniert nicht“ oder „bestehende Nutzerdaten werden nicht übernommen“.

7.2 Erlaubte Domänen und Optionen festlegen

Es gibt zwei Konfigurationswege.

• Admin console Geeignet, wenn dieselbe Einstellung organisationsweit verteilt werden soll. Das ist heute der Standardweg.
• Geräte-Registry Geeignet, wenn eine feine, gerätebezogene Unterscheidung gewünscht ist.

Wird die Registry verwendet, ist mindestens domains_allowed_to_login erforderlich. Wird GCPW gemeinsam mit Windows device management genutzt, werden enable_dm_enrollment und validity_period_in_days zu Entscheidungspunkten; bei einem eher gemeinsam genutzten Gerätebetrieb kommt auch enable_multi_user_login hinzu.

7.3 Installer beziehen und verteilen

Der 32-Bit- bzw. 64-Bit-GCPW-Installer wird aus der Admin console bezogen und an die Geräte verteilt. Der Pfad zum entsprechenden Bildschirm lautet wie folgt.

Google Admin console
  → Menü
  → Geräte (Devices)
  → Mobilgeräte und Endpunkte (Mobile & endpoints)
  → Einstellungen (Settings)
  → Windows
  → „Google Credential Provider for Windows setup“
  → „Download GCPW“

Für diesen Vorgang ist eine Anmeldung als privilegierter Administrator (super administrator) erforderlich. Von hier aus wird die 64-Bit- oder die 32-Bit-Version heruntergeladen und verteilt.

Im aktuellen Verwaltungsmodell ist wichtig, dass in den aus der Admin console heruntergeladenen Installer automatisch das Token der Organisation eingebettet wird. Ob dieses Token vorhanden ist, wirkt sich später aus.

Wurde bereits ein Registrierungstoken für Chrome Enterprise Core an die Geräte verteilt, lässt sich mit diesem Token auch die GCPW-Konfiguration über die Admin console verwalten. Wenn „die erlaubten Domänen wurden in der Admin console konfiguriert, aber auf dem Gerät nicht wirksam“ auftritt, prüfen Sie zuerst, ob nicht versehentlich ein Installer ohne Token verteilt wurde. Da die Übernahme der Einstellung selbst bis zu etwa einer Stunde dauern kann, sollte diese Zeit abgewartet werden, bevor eine Entscheidung getroffen wird.

7.4 Installieren

Für eine manuelle Installation kann beispielsweise wie folgt vorgegangen werden.

# 64-Bit-Version
gcpwstandaloneenterprise64.exe /silent /install

# 32-Bit-Version
gcpwstandaloneenterprise.exe /silent /install

7.5 Beispiel für individuelle Registry-Einstellungen

Ein Beispiel dafür, wie Werte, die nicht über die Admin console konfiguriert sind, pro Gerät gesetzt werden können.

Hinweis: Existiert dieselbe Einstellung sowohl in der Admin console als auch in der Registry, hat die Admin console Vorrang.

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 Wer bestehende Profile weiterverwenden will, sollte die Zuordnungsdefinition zuerst erstellen

Wer bestehende lokale / AD-Profile weiterverwenden möchte, sollte die Zuordnung zwischen dem Google-Konto und dem Windows-Konto des Nutzers vorab über ein Custom Attribute auf Directory-Seite vorbereiten. Wird das aufgeschoben und Nutzer melden sich zuerst an, wird meist erst ein neues Profil angelegt, das anschließend wieder zurückgerollt werden muss. Da dies die Stelle im Artikel ist, an der am häufigsten Pannen passieren, wird sie hier konkret beschrieben.

Schritt 1: Ein benutzerdefiniertes Attribut anlegen

Das Anlegen erfolgt in der Admin console unter „Verzeichnis“ → „Nutzer“ → oben „Weitere Optionen“ → „Benutzerdefinierte Attribute verwalten“. Die Werte sind genau wie folgt einzugeben, einschließlich Groß- und Kleinschreibung (bei einem Fehler lässt sich der Name später nicht korrigieren – das Attribut muss dann neu angelegt werden).

Wird das Attribut über die Directory API angelegt, erfolgt die Registrierung mit dem Schemanamen Enhanced_desktop_security und den Feldnamen AD_accounts / Local_Windows_accounts. Sollen Werte aus einem bestehenden AD eingespielt werden, lässt sich dafür auch Google Cloud Directory Sync nutzen.

Schritt 2: Werte je Nutzer eintragen

Auf der Detailseite eines Nutzers erscheint unter „Nutzerinformationen“ das Feld „Enhanced desktop security“, in das der Windows-Kontoname eingetragen wird. Das Format ist festgelegt.

Drei Einschränkungen sind zu beachten.

• Pro Nutzer ist nur ein AD-Konto zulässig. Werden mehrere eingetragen, verwendet GCPW nur den ersten Eintrag.
• Sind sowohl AD als auch lokal konfiguriert, sucht GCPW zuerst nach dem AD-Konto.
• Ist das Attribut nicht gesetzt oder wird kein passendes Windows-Profil gefunden, wird ein neues Windows-Profil angelegt. Die meisten Fälle von „obwohl zugeordnet, sind die bestehenden Daten nicht sichtbar“ liegen genau hier.

Bei einem AD-beigetretenen Gerät muss für Nutzer, die auf diesem Gerät noch kein AD-basiertes Profil besitzen (also über „Andere Nutzer“ auf dem Anmeldebildschirm einsteigen), das Gerät bei der ersten Anmeldung eine Verbindung zu AD herstellen können. Lässt man die erste Anmeldung auf einem im Homeoffice befindlichen Gerät durchführen, schlägt genau das fehl.

Die genauen Bildschirmschritte und die aktuelle Spezifikation finden Sie in der offiziellen Anleitung Associate Google accounts with existing Windows profiles.

7.7 Nach der ersten Online-Anmeldung überprüfen

Nach der ersten Anmeldung ist Folgendes zu überprüfen.

• Ist die Anmeldung im erwarteten Windows-Profil erfolgt?
• Bei gemeinsamer Nutzung mit Windows device management: Wurde der beabsichtigte Nutzer enrollt?
• Erscheinen die Gerätedetails in der Admin console?
• Ist die Richtliniensynchronisation abgeschlossen?

8. Häufige Stolperfallen und die Fehlereingrenzung unter Windows

GCPW-Probleme lassen sich meist einer der Zeilen dieser Tabelle zuordnen.

Was hinter „Chrome / AV-Interferenz“ steckt

Der am wenigsten greifbare Punkt in dieser Tabelle ist die „AV-Interferenz“. In der Praxis handelt es sich immer um eines der folgenden Probleme. Wird von oben nach unten geprüft, geht die Fehlereingrenzung schneller.

Von diesen Punkten wird die Kommunikation vor der Anmeldung besonders leicht übersehen. Selbst wenn eine Verbindung nach der Anmeldung des Nutzers durchgeht, läuft sie auf dem Anmeldebildschirm über einen anderen Pfad und mit anderen Anmeldeinformationen – prüfen Sie, ob genau dort ein Stillstand auftritt.

Der Ablauf der Fehlersuche

flowchart TD
    A["Problem mit GCPW aufgetreten"] --> B{"Was tritt auf?"}
    B -- Anmeldung verweigert --> C["Erlaubte Domänen prüfen"]
    B -- Google-Bildschirm erscheint nicht --> D["Vorhandensein / Pfad / AV von Chrome prüfen"]
    B -- Password incorrect --> E["Synchronisationsstatus zwischen Google und Windows prüfen"]
    B -- Bestehende Daten nicht sichtbar --> F["Profilzuordnung prüfen"]
    B -- Kein Eintrag im Device Management --> G["Ersten Enrollment-Nutzer prüfen"]
    C --> H["Admin console / Registry prüfen"]
    D --> I["Chrome neu installieren"]
    E --> J["Passwortbetrieb neu ordnen"]
    F --> K["Custom Attribute / SID-Zuordnung erneut prüfen"]
    G --> L["Staging-Verfahren überprüfen"]

Dieses Diagramm dient dazu, ausgehend vom Symptom genau einen Ort für die erste Prüfung festzulegen. GCPW-Probleme lassen sich immer einer der Kategorien „Authentifizierung“, „Chrome“, „Passwortabgleich“, „Profilzuordnung“ oder „Enrollment“ zuordnen – klären Sie zuerst, um welche Spalte es geht, bevor Sie zu den Detailprotokollen weitergehen. Wirken mehrere Symptome gleichzeitig vorhanden, führt die Prüfung, wer sich zuerst erfolgreich angemeldet hat, häufig zur Spalte „Enrollment“.

Wo unter Windows Protokolle zu finden sind

Wer GCPW unter Windows nachverfolgen möchte, beginnt mit der Ereignisanzeige (Event Viewer).

• Windows-Protokolle > Anwendung
• Ereignisquelle: GCPW

Damit lassen sich die meisten grundlegenden Informationen einsehen. Für eine detailliertere Ansicht lässt sich über die Registry das ausführliche Protokollieren (verbose logging) aktivieren.

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

Wer auch Windows device management einsehen möchte, prüft bei Bedarf zusätzlich Folgendes.

• Anwendungs- und Dienstprotokolle > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

Wenn die Übernahme schnell überprüft werden soll

Wer nach einer Änderung der erlaubten Domänen oder von Richtlinien sofort prüfen möchte, ob sie übernommen wurden, findet in Googles Anleitung die Methode, über den Task Scheduler GoogleUpdateTaskMachineUA auszuführen, um die Synchronisation anzustoßen. Während des Pilotbetriebs beschleunigt es die Fehlereingrenzung, dieses Verfahren griffbereit zu haben.

9. Für welche Organisationen es sich eignet – und für welche nicht

Wofür es sich eignet

Wofür es sich nicht eignet

10. Zusammenfassung

Der Trick, GCPW in einer Windows-Umgebung erfolgreich einzusetzen, besteht darin, die Funktionen nicht als monolithischen Block zu betrachten.

• GCPW ist der Mechanismus, um mit Google in Windows zu gelangen
• Die Zuordnung bestehender Profile ist der Migrationsmechanismus
• Windows device management ist der Mechanismus für den Endpunktbetrieb

Werden diese drei getrennt betrachtet, fällt die Einführungsentscheidung deutlich leichter.

In der Praxis besonders wichtig sind diese fünf Punkte.

1. Den Passwortbetrieb zuerst festlegen
2. Die erlaubten Domänen zuerst festlegen
3. Entscheiden, ob bestehende Profile weiterverwendet werden
4. Bei Nutzung von Windows device management den ersten Enrollment-Nutzer nicht verwechseln
5. Ein auf der Ereignisanzeige basierendes Fehlersuchverfahren bereithalten

GCPW ist ein praxistaugliches Werkzeug, um die Windows-Anmeldung stärker auf Google auszurichten. Was wirklich zählt, ist jedoch nicht der Moment, in dem der Installer ausgeführt wird, sondern die Planung davor. Wird diese vorab abgesichert, verbinden sich die Google-Anmeldung, die Weiternutzung bestehender Daten und die Windows-Geräteverwaltung sauber miteinander.

Verwandte Artikel

• Wann sind unter Windows Administratorrechte tatsächlich erforderlich? – UAC, geschützte Bereiche und wie man es am Design erkennt
• Anwendungsprüfungen mit Windows Sandbox beschleunigen
• Was ist ClickOnce? – Funktionsweise, Updates und wofür es sich eignet (und wofür nicht), aus praktischer Sicht

Verwandte Themen

• Windows-Technikthemen

Verwandte Leistungen

• Windows-Anwendungsentwicklung
• Technische Beratung & Design-Review
• Kontakt

Quellen

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 Verwaltungshilfe - Passwortanforderungen für Nutzer festlegen und überwachen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist GCPW?

GCPW (Google Credential Provider for Windows) ist ein Mechanismus, mit dem sich Nutzer mit einem verwalteten Google-Konto bei Windows 10/11 anmelden. Im Alleinbetrieb stehen die Windows-Anmeldung und das SSO-Erlebnis im Chrome Browser im Mittelpunkt – GCPW ist weder ein bloßer „Google-Anmeldebildschirm“ noch ein vollständiger Ersatz für eine Windows-Domäne. Unterstützt werden Windows 10/11 Pro, Pro for Workstations, Enterprise und Education; ARM-basierte Geräte werden nicht unterstützt, und Voraussetzung ist, dass Chrome Browser 81 oder neuer mit Administratorrechten installiert ist.

Kann ich mit GCPW allein BitLocker oder Windows Update verwalten?

Mit GCPW allein grundsätzlich nicht. Allein leistet GCPW die Windows-Anmeldung mit Google, Chrome-SSO und die Zuordnung bestehender Profile; für BitLocker, die Steuerung von Windows Update, die Kontrolle lokaler Administratorrechte, die Verteilung benutzerdefinierter Einstellungen und Wipe ist die gemeinsame Nutzung mit Windows device management Voraussetzung. Bei gemeinsamer Nutzung gilt die Einschränkung, dass pro Gerät nur der erste Nutzer enrollt werden kann – daher ist Vorsicht geboten, damit nicht versehentlich das für das Kitting zuständige Personal beim ersten Anmelden enrollt wird.

Kann sich GCPW auch offline bei Windows anmelden?

Die Offline-Anmeldung selbst ist möglich. Die erste Anmeldung erfordert jedoch zwingend eine Internetverbindung, und bei AD-beigetretenen Geräten ohne bestehendes AD-basiertes Profil muss bei der ersten Anmeldung zusätzlich eine Verbindung zu AD möglich sein. Wie viele Tage Offline-Betrieb erlaubt sind, lässt sich etwa über validity_period_in_days konfigurieren; wird nicht vorab festgelegt, wie viele Tage seit der letzten Online-Anmeldung zulässig sind, tendiert die Praxis entweder zu einer zu strengen Regelung, die den Betrieb behindert, oder zu einer zu lockeren, die das Risiko bei Geräteverlust erhöht.

Lassen sich mit GCPW Zwei-Faktor-Authentifizierung und Sicherheitsschlüssel nutzen?

Zwei-Faktor-Authentifizierung lässt sich nutzen, USB-Sicherheitsschlüssel werden von GCPW jedoch nicht unterstützt. Stattdessen sind Verfahren wie Google-Eingabeaufforderung, Google Authenticator und Backup-Codes vorzusehen. In einer Konfiguration, die ausschließlich Sicherheitsschlüssel zulässt, kann es passieren, dass Nutzer nicht mehr bei Windows anmelden können – das sollte vor der Einführung unbedingt kommuniziert werden. Da zudem ein Passwortabgleich zwischen Google- und Windows-Seite vorausgesetzt wird, führt ein Betrieb, bei dem nur auf der AD-/Entra-ID-Seite zuerst zurückgesetzt wird, zu Anmeldeproblemen durch Inkonsistenz.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.