GCPW 是什麼 - 用 Google 驗證處理 Windows 登入的方法

在把 Windows 裝置的登入統整成以 Google 為中心的討論中，相當高頻率會一次混進以下這些話題。

• GCPW 是不是「只跳出 Google 登入畫面」而已
• 既有的本機設定檔或 AD 設定檔會如何處理
• 是否能連 Windows 的系統管理員權限、BitLocker、更新管理都一起照顧到
• 首次登入、離線、兩步驟驗證、密碼變更會如何運作
• 能否與 Active Directory 共存，還是會取代它

如果把這些草草整理過去，導入前的期望值就會出現偏差，導致遷移或初期設定時容易出事故。

GCPW 既不是單純的「Google 登入畫面」，也不是 Windows 網域本身的完全替代。 在實務上，把 對 Windows 的 Google 登入、與既有設定檔的對應關係、Google 端的密碼 / 工作階段運作、與 Windows device management 併用分開來想，整體脈絡會清楚很多。

本文將以 Windows 10 / 11 環境為對象，搭配大量 Mermaid 圖表，從實務角度整理使用 Google Credential Provider for Windows（GCPW）時會發生什麼事、適合的架構、導入步驟，以及常見的陷阱。內容主要以 2026 年 3 月時點可查證的 Google Workspace 官方文件為依據。

圖表為概念圖。在支援 Mermaid 的 Markdown 環境中會顯示為圖表。

1. 先講結論

先把結論列出來。

• GCPW 是讓受管理的 Google 帳戶登入 Windows 10 / 11 的機制。
• GCPW 單獨使用時的主角是 Windows 登入 與 Chrome Browser 的 SSO 體驗。
• 如果還想照顧到 Windows 更新、BitLocker、本機系統管理員權限、自訂設定、清除，比較實務的做法是預設要 與 Windows device management 併用。
• 在已有既有本機 / AD 設定檔的環境中，若不先決定 「要關聯既有設定檔，還是建立新設定檔」，遷移過程很容易卡住。
• 首次登入的前提是在線上。而且在已加入 AD 的裝置上，如果還沒有既有的 AD 支援設定檔，首次登入時能否連上 AD 也很重要。
• 離線登入是可行的，但若不決定 要允許到第幾天，運作方式就會不穩定。
• 兩步驟驗證可以使用，但 GCPW 不支援 USB 安全金鑰。
• 若不先決定密碼運作方式，Google 端與 Windows 端不一致就會造成登入事故。特別是 只在 AD / Entra ID 端先重設 這種做法很危險。
• GCPW 只把 Google 當作身分識別提供者，以此為前提來設計架構，方向才不會偏掉。

簡單來說，GCPW 是 「用 Google 進入 Windows 的機制」，如果想整個掌握 Windows 裝置的營運，合理的做法是 與 Windows device management 一起設計。

先用一張圖看整體定位

flowchart TD
    A["想在 Windows 裝置上使用 Google 帳戶"] --> B{"想實現什麼"}
    B --> C["對 Windows 的 Google 登入"]
    B --> D["Windows 設定的集中管理"]
    B --> E["既有設定檔的遷移"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["既有本機 / AD 設定檔的關聯設計"]

    F --> I["Windows 登入"]
    F --> J["Chrome Browser SSO"]
    F --> K["Google 密碼同步"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["本機系統管理員權限"]
    G --> O["自訂設定 / 清除 / 稽核"]

    H --> P["建立新設定檔"]
    H --> Q["重複使用既有設定檔"]

2. 把 GCPW 拆成 4 個層次比較好理解

GCPW 的討論容易變複雜，是因為「登入」、「設定檔遷移」、「裝置管理」常被當成同一個箱子裡的話題。 實務上，拆成以下 4 個層次來看是最快的方法。

用這種方式看，就比較容易看出「裝了 GCPW 但 BitLocker 沒生效」、「用 Google 登入了卻看不到既有使用者資料」這類落差的原因。

分層架構

flowchart LR
    subgraph Id["身分 / 工作階段"]
        A["Google 帳戶"]
        B["兩步驟驗證"]
    end

    subgraph SignIn["登入層"]
        C["GCPW"]
    end

    subgraph Profile["Windows 設定檔層"]
        D["既有本機設定檔"]
        E["既有 AD 支援設定檔"]
        F["新的 Windows 設定檔"]
    end

    subgraph Mgmt["管理層"]
        G["Windows device management"]
        H["BitLocker / 更新 / 本機系統管理員權限"]
        I["自訂設定 / 清除 / 稽核"]
    end

    subgraph Config["設定層"]
        J["Admin console"]
        K["登錄檔設定"]
    end

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

3. 在 Windows 環境中如何運作

3.1 先掌握支援需求

在 Windows 環境中，最重要的是先不要在需求上出錯。

這裡容易被忽略的是 Chrome 與 不支援 ARM。 因為這是 Windows 裝置的話題，容易只盯著作業系統看，但 GCPW 啟動 Google 登入畫面也依賴 Chrome，所以 Chrome 不存在或部署不當同樣會導致登入失敗。

3.2 從首次登入到日常登入

把安裝 GCPW 之後的流程單純化，會是這樣：

1. 在裝置上安裝 GCPW
2. 使用者用 Google 帳戶進行首次登入
3. GCPW 會 關聯既有設定檔，或 建立新的 Windows 設定檔
4. 之後就從一般的 Windows 登入畫面進入
5. 但在 Google 密碼變更或工作階段過期等資安事件發生時，會再次要求 Google 登入畫面

這裡重要的是，「並不是每次都一定要透過 Google 對話框進入」這一點。 在首次登入或特定資安事件時，Google 端的驗證會出現在前面，但平常主要是在 Windows 登入畫面上登入。

首次登入流程

sequenceDiagram
    participant U as 使用者
    participant W as Windows 登入畫面
    participant G as Google 登入
    participant P as GCPW
    participant R as 既有 / 新設定檔
    participant C as Chrome Browser

    U->>W: 選擇 Add Work Account 或既有帳戶
    W->>G: 啟動 Google 驗證畫面
    G->>U: 電子郵件地址 / 密碼 / 2SV
    U->>G: 輸入憑證
    G->>P: 驗證成功

    alt 關聯既有設定檔
        P->>R: 找到並關聯既有本機 / AD 設定檔
    else 建立新設定檔
        P->>R: 建立新的 Windows 設定檔
    end

    P->>C: 延續 Google 登入狀態
    P->>W: 開始 Windows 工作階段

3.3 密碼同步、離線、兩步驟驗證

若想在 Windows 環境中穩定運作 GCPW，其實最先要看的是 密碼運作方式。

Google 官方指南也是以 在使用 GCPW 的裝置上，Google 密碼與 Windows 密碼保持同步為前提。而且通常是以使用者主要管理 Google 端密碼為前提。 因此，這與依賴 Ctrl + Alt + Delete 變更 Windows 密碼的設計並不搭。

密碼同步的概念

flowchart LR
    A["Google 密碼變更"] --> B{"裝置是否在線上"}
    B -- 是 --> C["GCPW 同步 Windows 端密碼"]
    C --> D["下次登入成功"]

    B -- 否 --> E["同步暫緩"]
    E --> F["下次上線時再同步"]

    G["只在 AD / Entra ID 端變更密碼"] --> H["Google 與 Windows 不一致"]
    H --> I["Password incorrect / 同步錯誤"]

實務上常見的狀況如下。

• 以為在 Google 端已經改好密碼，但裝置離線，還沒和 Windows 端同步
• 反過來只在 AD / Entra ID 端先重設，造成與 Google 端不一致
• Google 端的密碼複雜度比 Windows / AD 弱，改成了不符合 Windows 端要求的字串

因此，導入前至少要決定以下事項。

• 密碼的主導權要放在 Google
• 還是要 從 AD / Entra ID / 其他工具同步到 Google
• 密碼複雜度是否要對齊到 Windows 端以上

離線與兩步驟驗證

GCPW 本身支援離線登入。 但可以設定 距離上次上線登入最多允許幾天。若沒決定這一點就導入，很容易偏向過嚴讓現場困擾，或過鬆讓裝置遺失時的風險提高。

另外，兩步驟驗證可以使用，但建議先把以下幾點告知現場，比較安全。

• GCPW 不支援 USB 安全金鑰
• 請改以 Google 提示、Google Authenticator、備用碼等方式為前提
• 若設定成只允許安全金鑰，使用者可能會無法登入 Windows

4. 如何處理既有的本機 / AD 設定檔

GCPW 遷移中最容易出事故的地方就在這裡。

當裝置上已經有業務用的 Windows 設定檔時，GCPW 端要 關聯並重複使用它，還是 建立新的 Windows 設定檔，會大幅改變使用者體驗與遷移難度。

3 種代表性模式

Google 的說明中，關聯既有設定檔時也會用 Directory 端的 custom attribute 對應 Windows 帳戶名稱或 AD 帳戶，或是在裝置端使用 基於 SID 的登錄檔設定。 換句話說，這是 需要事先設計的遷移作業，而不是「安裝之後讓使用者當場隨意選擇」的做法。

更重要的是，不做關聯時的行為。

• 既有本機設定檔的使用者，有時仍會有進入舊設定檔的空間
• 既有 AD 使用者若建立了用於 Google 登入的新設定檔，可能無法順利進入原本期望的業務設定檔

如何處理既有設定檔的判斷流程

flowchart TD
    A["裝置上有既有的業務用 Windows 設定檔"] --> B{"想直接沿用資料 / 設定嗎"}
    B -- 是 --> C["設計既有設定檔的關聯"]
    B -- 否 --> D["讓 GCPW 建立新的 Windows 設定檔"]

    C --> E{"既有設定檔的類型"}
    E -- 本機 --> F["用 Local Windows accounts 等方式對應"]
    E -- AD 支援 --> G["用 AD accounts 等方式對應"]

    G --> H["確認首次登入時的 AD 連線性"]
    F --> I["整理 Windows 使用者名稱 / 每台裝置的限制"]
    D --> J["以另一個計畫進行既有資料遷移"]

5. GCPW 單獨使用與 GCPW + Windows device management 的差異

討論 GCPW 時，把這兩者分開來看在實務上非常重要。

比較表

Google 官方對公司配發的裝置也建議 同時使用 GCPW 與 Windows device management 的架構。 反之，若已經有其他管理平台，只想要 Google 登入體驗，那就是 GCPW 單獨使用的思路。

併用時容易被忽略但很重要的限制

併用 Windows device management 時，最好先理解 一台裝置只有 1 位使用者能夠 enroll 這一點，會比較安全。

Google 官方也把這視為 Windows 10 / 11 端的限制。 即使多名使用者都能透過 GCPW 進入該裝置，只有第一位使用者會被 enroll 進 Windows device management。而且 BitLocker、更新、本機系統管理員權限這類 裝置層級的設定，也會影響到使用該裝置的其他使用者。

第一位使用者的問題

flowchart TD
    A["設定裝置"] --> B["第一位透過 GCPW 登入的使用者"]
    B --> C["enroll 進 Windows device management"]
    C --> D["套用裝置層級設定"]
    D --> E["BitLocker / 更新 / 本機系統管理員權限 / 自訂設定"]

    F["之後透過 GCPW 登入的其他使用者"] --> G["Windows 登入本身可行"]
    G --> H["但 enroll 的使用者不會增加"]
    H --> I["裝置層級設定以第一次 enroll 為前提運作"]

這會導致的問題是 負責安裝作業的技術人員先透過 GCPW 登入。 如果 enroll 的是設定人員的帳戶，而不是真正要使用該裝置的員工，之後就會出現預期的設定沒有套用上去的事故。

6. 導入前該決定的事項

GCPW 導入後真正發揮效果的，並不是執行安裝程式本身，而是 事前設計。 把官方指南換成實務上的說法，至少以下 6 項要先決定好。

flowchart LR
    A["導入前決定"] --> B["密碼主導權"]
    B --> C["複雜度需求"]
    C --> D["允許的網域"]
    D --> E["既有設定檔的處理"]
    E --> F["支援用的系統管理員權限"]
    F --> G["自動 enrollment 的 staging 方針"]
    G --> H["允許離線的天數"]

不好的做法與實務上的做法

特別容易忽略的 3 點

1. 允許的網域是必須的

在 GCPW 中，若不決定 允許哪些網域的帳戶登入，使用者就無法進入。 無論是透過 Admin console 還是登錄檔的 domains_allowed_to_login 都可以設定，但無論哪一種，這都是必須的。

2. 讓 Admin console 與登錄檔各自分工

較舊的說明文章多以登錄檔設定為主，但現在 以 Admin console 管理為基本做法。 不過，若想要 每台裝置設定不同的允許網域 這類更細的粒度，登錄檔有時反而更適合。

3. Admin console 的設定不會立即生效

GCPW 的設定會以 大約每小時一次 的頻率同步到裝置。 「設定已經輸入了，卻沒有馬上生效」是常見狀況，pilot 階段最好把這段時間差也納入考量會比較安全。

7. 實務上的導入步驟

這裡盡量精簡地整理在 Windows 環境中實務導入 GCPW 的流程。

導入流程

flowchart TD
    A["1. 確認訂閱方案 / 作業系統 / Chrome 需求"] --> B["2. 決定密碼策略與複雜度"]
    B --> C["3. 決定允許的網域與各項設定"]
    C --> D["4. 決定是否需要關聯既有設定檔"]
    D --> E["5. 若要使用 Windows device management 就啟用它"]
    E --> F["6. 從 Admin console 取得安裝程式"]
    F --> G["7. 部署到裝置 / 以系統管理員權限安裝"]
    G --> H["8. 使用者進行首次線上登入"]
    H --> I["9. 確認裝置詳細資訊 / enrollment / 記錄"]

7.1 先決定架構

最先要決定的是以下項目。

• 要用 GCPW 單獨使用嗎
• 要用 GCPW + Windows device management 嗎
• 是否要 關聯 既有設定檔
• 還是要用 新設定檔 切換

這個判斷要先做。 若不先決定就只發佈安裝程式，之後就會遇到「沒辦法照原本想的方式管理裝置」、「既有使用者資料沒有承接過來」。

7.2 決定允許的網域與選項

設定方式有 2 種。

• Admin console 適合想把同一套設定發佈給整個組織時使用，現在的基本做法就是這個。
• 裝置登錄檔 適合想針對每台裝置做細部區分時使用。

若使用登錄檔，至少需要 domains_allowed_to_login。 若讓 GCPW 與 Windows device management 併用，enable_dm_enrollment 與 validity_period_in_days 會成為決策點；若是類似共用裝置的運作，enable_multi_user_login 也會是判斷點。

7.3 取得並部署安裝程式

從 Admin console 取得 32bit / 64bit 的 GCPW 安裝程式並部署到裝置。 在目前的管理模式下，從 Admin console 下載的安裝程式會內嵌 organization-specific token，所以現在以此為基準來理解會更清楚。

7.4 安裝

若是手動安裝，例如可以這樣做：

# 64bit 版本
gcpwstandaloneenterprise64.exe /silent /install

# 32bit 版本
gcpwstandaloneenterprise.exe /silent /install

7.5 想用登錄檔做個別設定時的範例

以下是想針對每台裝置輸入 Admin console 尚未設定的值時的範例。

注意：若 Admin console 與登錄檔同時存在相同設定，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 若要重複使用既有設定檔，先建立關聯定義

若想重複使用既有本機 / AD 設定檔，請先透過 Directory 端的 custom attribute 等方式，準備好使用者的 Google 帳戶與 Windows 帳戶的對應關係。 若把這件事往後延，先讓使用者登入，很容易在新設定檔建立之後才要回頭處理。

7.7 首次線上登入後要確認的事項

首次登入後，請確認以下項目。

• 是否進入了預期的 Windows 設定檔
• 若併用 Windows device management，是否以預期的使用者身分完成 enroll
• Admin console 上是否出現該裝置的詳細資訊
• 政策同步是否已完成

8. 常見的問題與在 Windows 上的排查方式

GCPW 的問題大致都會落在下表其中一項。

問題排查流程

flowchart TD
    A["GCPW 發生問題"] --> B{"發生了什麼狀況"}
    B -- 拒絕登入 --> C["確認允許的網域"]
    B -- Google 畫面沒出現 --> D["確認 Chrome 是否存在 / 路徑 / 防毒軟體"]
    B -- Password incorrect --> E["確認 Google / Windows 的同步狀態"]
    B -- 看不到既有資料 --> F["確認設定檔關聯"]
    B -- 沒進入 device management --> G["確認第一次 enroll 的使用者"]
    C --> H["確認 Admin console / 登錄檔"]
    D --> I["重新安裝 Chrome"]
    E --> J["重新整理密碼運作方式"]
    F --> K["重新確認 custom attribute / SID 對應"]
    G --> L["重新檢視 staging 步驟"]

在 Windows 上確認記錄的位置

要在 Windows 上追查 GCPW 時，先看 Event Viewer。

• Windows Logs > Application
• Event source 為 GCPW

這樣就能看到大部分的基本資訊。 若想看得更詳細，可以透過登錄檔啟用 verbose logging。

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

若還想連 Windows device management 一起看，也可視需要查看：

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

想快點確認是否已套用時

修正允許的網域或政策之後，若想馬上確認是否已套用，Google 的說明提到可以從 Task Scheduler 執行 GoogleUpdateTaskMachineUA 來促使同步。 pilot 階段隨手備好這個步驟，能加快排查速度。

9. 適合哪種組織，不適合哪種組織

適合的場景

不適合的場景

10. 結語

在 Windows 環境中善用 GCPW 的訣竅，是不要把功能當成一整塊來看。

• GCPW 是用 Google 進入 Windows 的機制
• 既有設定檔關聯 是遷移的機制
• Windows device management 是裝置營運的機制

把這 3 件事分開來想，導入時的判斷就會輕鬆許多。

實務上特別重要的是以下 5 點。

1. 先決定密碼運作方式
2. 先決定允許的網域
3. 決定是否要重複使用既有設定檔
4. 若使用 Windows device management，不要選錯第一位 enroll 的使用者
5. 準備一套以 Event Viewer 為基礎的問題排查流程

GCPW 是 讓 Windows 登入向 Google 靠攏的實務工具。 但真正發揮效果的並非執行安裝程式的那一刻，而是 在那之前的設計。 先把這部分打好基礎，Google 登入、既有資料的持續使用、Windows 裝置管理這幾條線就能整齊地連在一起。

相關文章

• Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式
• 用 Windows 沙箱加速 Windows 應用程式開發的驗證 - 以實務向整理管理員權限問題、乾淨環境、權限不足・資源不足的重現
• ClickOnce 是什麼 - 以實務視角整理機制、更新、適合場面・不適合場面

相關主題

• Windows 技術主題

此主題連接的服務

• Windows 應用程式開發
• 技術諮詢・設計審查
• 聯絡我們

參考資料

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

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

GCPW 是什麼？

GCPW（Google Credential Provider for Windows）是讓受管理的 Google 帳戶登入 Windows 10 / 11 的機制。單獨使用時的主角是 Windows 登入與 Chrome Browser 的 SSO 體驗，既不是單純的「Google 登入畫面」，也不是 Windows 網域的完全替代。支援的作業系統為 Windows 10 / 11 的 Pro、Pro for Workstations、Enterprise、Education，不支援 ARM 架構裝置，前提是已用系統管理員權限安裝 Chrome Browser 81 以上版本。

只靠 GCPW 能管理 BitLocker 或 Windows Update 嗎？

單靠 GCPW 基本上做不到。GCPW 單獨能做到的只有透過 Google 登入 Windows、Chrome SSO、既有設定檔關聯，而 BitLocker、Windows Update 控制、本機系統管理員權限控制、自訂設定發佈、清除等都需要搭配 Windows device management。併用時有「一台裝置只有第一位使用者能夠 enroll」的限制，因此要注意負責安裝作業的人員若先登入，可能會誤被 enroll 的問題。

GCPW 可以在離線狀態下登入 Windows 嗎？

離線登入本身是可行的。但首次登入必須連上網際網路，若是已加入 AD 的裝置且尚無既有的 AD 支援設定檔，首次登入時也必須能連線到 AD。允許離線的天數可透過 validity_period_in_days 等設定，若不事先決定「距離上次上線登入最多可允許幾天」，很容易偏向過嚴讓現場困擾，或過鬆讓裝置遺失時的風險提高。

GCPW 可以使用兩步驟驗證或安全金鑰嗎？

可以使用兩步驟驗證，但 GCPW 不支援 USB 安全金鑰。請改以 Google 提示、Google Authenticator、備用碼等方式為前提。若設定成只允許安全金鑰，使用者可能會無法登入 Windows，因此建議在導入前先告知現場。另外，密碼是以 Google 端與 Windows 端同步為前提，若只在 AD / Entra ID 端先重設，會因為不一致而導致登入事故。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。