身分佈建 (或帳戶佈建) 是指設定帳戶，並在儲存使用者資料的三個系統之間建立連線的程序，有時也會在使用者和裝置之間建立連線。
在 Android 企業環境中，有三種不同的系統會保存使用者帳戶資訊：
- 機構的使用者目錄是使用者資訊的最終來源。
- 您 (EMM 解決方案供應商) 必須維護機構使用者目錄，至少要包含最基本的部分。
- Google 會保留受管理 Google Play 帳戶和 Google 帳戶的部分資訊，以便透過 Google Play 提供應用程式管理功能。
Users 資源代表與企業相關聯的帳戶。帳戶可專屬於裝置，也可以與擁有數部裝置的個人建立關聯，並在所有裝置上使用該帳戶。視您設定客戶企業的方式而定，該帳戶可提供 Google Play 管理版存取權，或提供其他 Google 服務存取權：
受管理 Google 帳戶是由 Google 管理的現有帳戶。客戶必須使用 Google 做為身分識別提供者，或是將機構的使用者目錄連結至 Google，才能使用這些帳戶。如果企業使用受管理 Google 帳戶，Google 會在裝置佈建期間負責驗證使用者。
Google Play 管理版帳戶可讓企業透過企業行動管理 (EMM) 解決方案供應商，自動建立受限的使用者帳戶。這些帳戶只提供 Google Play 管理版的存取權。EMM 必須在必要時驗證使用者身分。如果是 Google Play 管理版帳戶企業，則只能使用這類帳戶。
表 1：Users API 欄位和方法
| Google Play 管理版帳戶 | 受管理的 Google 帳戶 | |
|---|---|---|
| 欄位 | ||
| id | ||
| kind | ||
| accountIdentifier | 您建立的專屬 ID，並對應至 Google Play 傳回的 ID (userId)。請勿使用個人識別資訊 (PII)。 | 未設定。 |
| accountType | deviceAccount、userAccount | userAccount |
| displayName | 您在 UI 項目中顯示的名稱，例如 Google Play 內。請勿使用個人識別資訊。 | 未設定。 |
| managementType | emmManaged | googleManaged、emmManaged |
| primaryEmail | 未設定。 | 這個欄位是主要鍵，您可藉此將 Google 管理的網域帳戶同步至系統中的使用者帳戶。 |
| 方法 | ||
| 刪除 | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| insert | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
為提升裝置註冊體驗，我們將改用受管理 Google 帳戶，管理員工使用公司身分識別資訊登入的所有 Android Enterprise 裝置。
對於新註冊的裝置，我們現在建議使用受管理 Google 帳戶，而非受管理 Google Play 帳戶。我們將繼續為現有使用者提供 Google Play 管理版帳戶支援，但這類帳戶只能存取 Google Play 管理版商店。受管理 Google 帳戶可讓使用者存取全套 Google 服務和跨裝置功能。
註冊流程改善
受管理的 Google 帳戶會向 Google 驗證使用者身分。這項功能可提供跨裝置體驗，例如交接工作、通知和鄰近分享。在企業領域，使用者經常會使用多部裝置，因此這些功能越來越重要。
如果企業並非使用 Google 做為識別資訊提供者，我們強烈建議將現有的識別資訊提供者連結至 Google。這樣一來，在繫結程序中，系統就能為員工建立受管理 Google 帳戶。企業應使用與 EMM 相同的識別資訊提供者。
我們已進行下列變更：
裝置註冊期間的使用者驗證作業，現在由 Google/Android 處理。EMM 的裝置政策控制器 (DPC) 會要求 Android 在適當時間驗證使用者，然後 Android 會將登入使用者的身分識別資訊傳回 DPC。
EMM 必須在要求使用者驗證時，將註冊權杖傳遞給 Android。這個權杖是透過 Android Enterprise API 的 API 呼叫傳回，且可能會編碼在 QR code、NFC 或零接觸註冊酬載中。
雖然 Android 現在會處理驗證作業，並將使用者身分提供給 EMM，但 EMM 仍有責任將使用者身分對應至正確的群組或機構結構。這項對應作業非常重要，因為裝置必須套用適當的政策。因此，企業必須繼續將機構的使用者目錄連結至 EMM。
IT 管理員可以啟用或停用 Google 提供的新版使用者驗證功能。為提供最佳使用者體驗 (包括跨裝置功能)，建議 IT 管理員將機構的使用者目錄連結至 Google。如果沒有這個連結，使用者將擁有 Google Play 管理版帳戶，且無法存取跨裝置體驗。
所有 EMM 都必須遵守新規定，在建立註冊和登入權杖時提供額外資訊。具體來說，您現在必須指出裝置是否無使用者 (例如資訊站或專用裝置)。
優點
新程序的主要改良項目如下：
簡化註冊程序：與標準方法相比，這項功能可減少手動步驟和複雜度。
支援 Google 帳戶：現在所有佈建方法都支援使用 Google 帳戶。這樣就不需要 Google Play 管理版帳戶。
更完善的使用者體驗：透過受管理 Google 帳戶，您可享有更豐富的 Android 體驗，包括分享和複製貼上等強大的跨裝置功能。
實作使用者帳戶
如要瞭解如何繼續使用這個新的註冊流程，請參閱「導入使用者帳戶」。
受管理 Google 帳戶的生命週期
如果機構使用 Google 帳戶，EMM 解決方案中的使用者帳戶會反映與其他 Google 服務 (例如 Google Workspace) 相關聯的現有使用者帳戶。這些帳戶是 googleManaged
(表 1)，因為帳戶的建立和相關資訊都來自 Google 的後端服務。
EMM 可以在控制台中提供機制，方便您使用 Google Cloud Directory Sync (GCDS) 和 Google Admin SDK Directory API 等工具，建立系統中的使用者帳戶，並持續與 Google 網域帳戶來源同步處理。如需各種方法的總覽，Google 管理的網域身分識別模型要求使用者帳戶必須存在於解決方案 (EMM 控制台、EMM 伺服器，可能位於資料存放區) 的環境中，才能在工作設定檔環境中，佈建至使用者的任何裝置。
在佈建身分期間，系統會使用使用者帳戶填入機構的 Google 管理網域。在某些情況下，系統會將使用者現有的線上身分 (例如 Microsoft Exchange 帳戶) 與 Google 帳戶同步處理。
同步處理客戶帳戶
在 Google 帳戶部署作業中，機構可以使用 GCDS 工具，將 G Suite 網域中的資料與 LDAP 目錄中的資料同步處理。或者，如果貴機構授予您存取權，您也可以使用 GCDS 代表機構執行這項操作。
GCDS 工具會呼叫 Google Directory API 並同步處理使用者名稱，但不會同步處理密碼。
如果貴機構使用 Microsoft Active Directory，並希望使用者的 G Suite 密碼與 Active Directory 密碼保持同步，則貴機構 (或您) 可以搭配 GCDS 使用 G Suite Password Sync (GSPS) 工具。
如需管理員適用的 GCDS 操作說明，請參閱準備 G Suite 網域以進行同步處理。
Google Directory API
在 Google 帳戶部署作業中，您可以使用 Google Directory API 同步處理 Active Directory、密碼或兩者：
使用 Directory API 進行僅限目錄的同步作業。 如果您對機構的受管理 Google 網域具有唯讀存取權，可以使用 Google Directory API 取得 Google 帳戶資訊，例如 Google 的使用者名稱 (但不包括密碼)。由於您無法將任何資料寫入使用者的 Google 帳戶，因此貴機構必須全權負責帳戶生命週期。
情境 1 和 SAML 式單一登入 (SSO) 驗證情境更完整地說明瞭這種情況。
如要瞭解如何以這種方式使用 Directory API，請參閱 Directory API 說明文件中的「Retrieve all account users」(擷取所有帳戶使用者)。
使用 Directory API 同步處理目錄和選用密碼。 如果您擁有機構受管理 Google 網域的讀寫權，可以使用 Google Directory API 取得使用者名稱、密碼和其他 Google 帳戶資訊。您可以更新這項資訊並與自己的資料庫同步，而且視您提供給客戶的解決方案而定，您可能要全權或部分負責帳戶生命週期。
情境 2 說明瞭這種情況。
如要進一步瞭解如何使用 Directory API 管理使用者帳戶資訊，請參閱開發人員指南：Directory API - 使用者帳戶。
Google 帳戶情境
以下章節將說明幾種常見的 Google 帳戶身分佈建情境。
情境 1：客戶負責帳戶生命週期
在這個情境中，客戶會為使用者建立及維護 Google 帳戶。
您會從機構的 LDAP 目錄取得使用者帳戶資訊，並使用 Google Directory API，將這些資訊與從 Google 取得的 Google 帳戶資料建立關聯。
機構全權負責帳戶生命週期。舉例來說，當建立新的 Google 帳戶時，機構會將使用者新增至 LDAP 目錄。下次將資料庫與 LDAP 目錄同步時，資料庫就會收到這位新使用者的資訊。
此時：
- 您只有 Google 帳戶的唯讀存取權。
- 資料庫會取得 Google 帳戶名稱，但不會取得 LDAP 使用者名稱或密碼。
- 您可以使用 Google Directory API 取得客戶使用者的基本帳戶資訊。(您可存取的資訊是
Users.get要求傳回的不可寫入資訊)。您可以使用這項資訊驗證使用者的 Google 帳戶是否存在，讓使用者在裝置上完成驗證。 - 客戶使用 GCDS 工具進行單向同步，以填入使用者的 Google 帳戶。(機構可能也會在身分識別佈建完成後，使用 GCDS 進行持續同步處理)。機構也可以視需要使用 GSPS 工具，同步處理使用者名稱和密碼。
情境 2：EMM 負責帳戶生命週期
在這個情境中，您會代表客戶處理建立 Google 帳戶的程序，並負責管理使用者的帳戶生命週期。
舉例來說，如果機構的 LDAP 目錄中使用者資訊有變更，您必須負責更新使用者的 Google 帳戶。在此情境中，不會使用 GCDS。
此時：
- 您擁有 Google 帳戶的讀寫權限。
- 資料庫會取得 Google 帳戶名稱和 LDAP 使用者名稱 (以及密碼雜湊值，視需要)。
- 您代表客戶使用 Google Directory API，讀取及寫入機構使用者帳戶資訊。(您可用的資訊是
Users.get要求傳回的不可寫入資訊)。您可以使用這項資訊驗證使用者的 Google 帳戶是否存在，讓使用者在裝置上完成驗證。 - 未使用 GCDS 工具。
SAML 式單一登入 (SSO) 驗證情境
在 Google 帳戶部署作業中，您或客戶可能會搭配使用安全宣告標記語言 (SAML) 和身分識別提供者 (IdP)，驗證與每位使用者相關聯的 Google 帳戶。您可以使用 Google 帳戶名稱驗證使用者的 Google 帳戶是否存在，使用者登入裝置時需要進行使用者驗證。舉例來說，SAML 可用於情境 2。如要瞭解如何設定，請參閱「為 G Suite 帳戶設定單一登入 (SSO) 服務」。