本文說明如何設定 Cloud Identity 或 Google Workspace，以便使用 Active Directory 做為 IdP 和權威來源。
這份文件會比較 Active Directory 的邏輯結構與 Cloud Identity 和 Google Workspace 使用的結構，並說明如何對應 Active Directory 的樹狀結構、網域、使用者和群組。這份文件也提供流程圖，協助您根據情境決定最佳對應方式。
本文假設您已熟悉 Active Directory。
實作聯盟
Google Cloud 使用 Google 身分進行驗證及存取權管理。當所有員工都擁有 Active Directory 的帳戶時，手動維護每位員工的 Google 身分會有點麻煩。在 Google Cloud 與現有的身分管理系統之間連結使用者身分後，您就可以將 Google 身分的維護工作自動化，並將其生命週期連結至 Active Directory 中的現有使用者。
設定 Active Directory 與 Cloud Identity 或 Google Workspace 之間的聯盟，需要完成兩個步驟：
佈建使用者：相關使用者和群組會定期從 Active Directory 同步至 Cloud Identity 或 Google Workspace。此程序可確保當您在 Active Directory 中建立新使用者時，也可以在 Google Cloud 關聯使用者尚未完成初次登入的情況下，就能在 GCP 中參照該使用者。這個程序也可以確保使用者刪除作業確實生效。
佈建作業是單向的，也就是說，Active Directory 中的變更會複製到 Google Cloud ，但相反的情況就不行。此外，佈建作業不包含密碼。在連結設定中，Active Directory 仍是管理憑證的唯一系統。
單一登入：每當使用者需要進行驗證時， Google Cloud會使用安全宣告標記語言 (SAML) 通訊協定，將驗證委派到 Active Directory。此委派程序可以確保只有 Active Directory 能夠管理使用者憑證，並強制執行任何適用的政策或多重驗證 (MFA) 機制。不過，如要成功登入，必須先為對應使用者提供權限。
您可以使用下列工具來實作連結：
- Google Cloud Directory Sync (GCDS) 是 Google 免費提供的工具，可實作同步處理程序。GCDS 會透過安全資料傳輸層 (SSL) 與 Google Cloud 通訊，通常會在現有運算環境中執行。
- Active Directory Federation Services (AD FS) 由 Microsoft 做為 Windows Server 的一部分提供。有了 AD FS，您可以使用 Active Directory 進行連結驗證。AD FS 通常會在現有運算環境中執行。
由於 Google Cloud的 API 開放給大眾使用，且 SAML 是一種開放標準，您可以使用許多工具來實作連結。本文件將著重於說明如何使用 GCDS 和 AD FS。
Active Directory 的邏輯結構
在 Active Directory 基礎架構中，頂層元件是「樹系」。樹系可做為一或多個網域的容器使用，並從樹系根網域衍生其名稱。Active Directory 樹系中的網域會彼此信任，讓在一個網域中驗證的使用者能夠存取其他網域中的資源。除非使用跨樹系信任連接樹系，個別的樹系預設不會彼此信任，在一個樹系中驗證的使用者將無法存取其他樹系中的資源。
Active Directory 網域是管理資源的容器，並且會被視為管理邊界。將多個網域納入一個樹系之中，是簡化管理或強制執行其他結構的一種方法，但樹系中的網域並不代表安全性邊界。
Google Cloud的邏輯結構
在 Google Cloud中，機構會做為所有資源的容器，並且可以使用資料夾與專案進一步區隔這些資源。因此機構、資料夾與專案的目的與 Active Directory 網域類似。
Active Directory 會將使用者當成資源處理，因此使用者管理與驗證會與網域關聯。相較之下， Google Cloud 不會管理機構中的使用者，但服務帳戶除外。而是會依賴 Cloud Identity 或 Google Workspace 來管理使用者。 Google Cloud
Cloud Identity 或 Google Workspace 帳戶可做為使用者和群組的私人目錄。帳戶管理員可以控管使用者和群組的生命週期和設定，並定義驗證方式。
建立 Cloud Identity 或 Google Workspace 帳戶時，系統會自動為您建立 Google Cloud 機構。Cloud Identity 或 Google Workspace 帳戶及其關聯的 Google Cloud 機構會共用相同名稱並彼此連結在一起。不過， Google Cloud 機構可以參照其他 Cloud Identity 或 Google Workspace 帳戶的使用者和群組。
整合 Active Directory 和 Google Cloud
儘管 Active Directory 與 Google Cloud的邏輯結構之間具有某些相似性，但無論採取哪一種方式在兩種結構間進行對應，都不可能滿足所有使用情況。整合兩個系統並對應結構的正確方法取決於多個因素：
- 如何將網域與樹系對應至 Cloud Identity 或 Google Workspace 帳戶
- 如何對應 DNS 網域
- 如何對應使用者
- 如何對應群組
以下幾節會逐一介紹這些因素。
對應樹系
在較大機構中，您通常會使用多個 Active Directory 網域管理身分及跨企業存取。當您規劃連結 Active Directory 與 Google Cloud時，要關注的第一個因素是 Active Directory 基礎架構的拓撲。
單一樹系、單一網域
當樹系只包含一個網域時，您可以將整個 Active Directory 樹系對應至單一 Cloud Identity 或 Google Workspace 帳戶。然後這個帳戶會提供單一 Google Cloud 機構的基礎，讓您用來管理 Google Cloud 資源。
在單一網域環境中，網域控制器與全域目錄伺服器都提供對於所有物件的存取權，而這些物件都在 Active Directory 中管理。在大多數情況下，您可以執行 GCDS 的單一執行個體，藉以將使用者帳戶與群組同步至 Google Cloud，並維護單一 AD FS 執行個體或群體以處理單一登入。
單一樹系、多個網域
當樹系中包含多個 Active Directory 網域時，您可以在一或多個網域樹狀結構中整理這些網域。在這兩種情況下，您都可以將整個樹系對應至單一 Cloud Identity 或 Google Workspace 帳戶。然後這個帳戶會提供單一 Google Cloud 機構的基礎，讓您用來管理 Google Cloud 資源。
在多網域環境中，可從網域控制器擷取的資訊與可從全域目錄伺服器查詢的資訊會有所不同。網域控制器只會從本機網域提供資料，而全域目錄伺服器則會從樹系中的所有網域提供資訊的存取權。至關重要的一點是，全域目錄伺服器提供的資料只有部分資料，並缺少某些 LDAP 屬性。這個限制會影響您設定 GCDS 以同步處理群組的方式。
根據您打算對應群組的方式而定，連結多網域樹系與Google Cloud 會需要一或多個 GCDS 執行個體，但只需要單一 AD FS 執行個體或群體即可處理單一登入。
具有跨樹系信任的多個樹系
在較大機構中，很少會有多個 Active Directory 樹系的情況，這通常是併購之後的結果。您可以使用雙向的跨樹系信任來合併這些樹系，這樣使用者就能夠跨單一樹系的邊界共用及存取資源。
如果所有樹系都與其他樹系之間保有雙向信任關係，您可以將整個環境對應至單一 Cloud Identity 或 Google Workspace 帳戶。這個帳戶會提供單一Google Cloud 機構的基礎，讓您用來管理 Google Cloud資源。
儘管全域目錄伺服器可從多個網域提供資料存取權，其範圍也受限於單一樹系。因此，在多樹系環境中，您必須查詢多個網域控制器或全域目錄伺服器，才能取得完整的使用者清單 (僅為舉例，可能還有其他項目受限)。由於存在這樣的限制，連結多樹系環境與 Google Cloud 會需要每個樹系至少有一個 GCDS 執行個體。跨樹系信任可跨樹系邊界進行使用者驗證，因此如要處理單一登入，單一 AD FS 執行個體或群體就足夠了。
如果您的環境跨越多個樹系而沒有跨樹系信任，但所有與連結 Google Cloud相關的 Active Directory 網域都透過外部信任連接，則也適用於相同的考量因素。
沒有跨樹系信任的多個樹系
在此處所述的環境中，您無法跨樹系邊界驗證或存取資源，單一 AD FS 執行個體或群體也無法為所有樹系的使用者處理單一登入要求。
因此，您無法將缺少跨樹系信任的多個樹系對應至單一 Cloud Identity 或 Google Workspace 帳戶。每個樹系都必須對應至單獨的 Cloud Identity 或 Google Workspace 帳戶，換言之，就是必須執行至少一個 GCDS 執行個體與一個 AD FS 伺服器或群體。
在 Google Cloud中，系統會為每個 Cloud Identity 或 Google Workspace 帳戶建立單獨的機構。在大多數情況下，您不需要維護多個單獨的機構。您可以選取一個機構，並將其關聯至其他 Cloud Identity 或 Google Workspace 帳戶，有效建立與多個 Active Directory 樹系連結的機構。其他機構則保持不使用。
對應 DNS 網域
DNS 在 Active Directory、Cloud Identity 和 Google Workspace 中都扮演重要角色。當您規劃連結 Active Directory 與 Google Cloud 時，要關注的第二個因素是如何在 Active Directory 與 Google Cloud之間共用或對應 DNS 網域。
在 Active Directory 中使用 DNS 網域
在 Active Directory 樹系中，DNS 網域可在多個位置使用：
- Active Directory DNS 網域：每個 Active Directory 網域都對應至一個 DNS 網域。這個網域可能是全域的 (例如
corp.example.com)，或可能是本機網域名稱 (例如corp.local或corp.internal)。 - 郵件交換 (MX) 網域：電子郵件使用 DNS 網域。在某些情況下，這個網域與 Active Directory DNS 網域相同，但在許多情況下會使用不同的，通常是更短的網域，例如
example.com。在理想的情況下，Active Directory 中的使用者電子郵件地址會與選用mail屬性相關聯。 - UPN 後置字串網域：這類網域是用於「使用者主要名稱」(UPN)。根據預設，使用者所屬網域的 Active Directory DNS 網域會用於建立 UPN。以
corp.example.com網域中的使用者 john 來說，預設的 UPN 為john@corp.example.com。但是，您可以設定讓樹系使用其他 DNS 網域做為 UPN 後置字串，此後置字串並不會對應到 Active Directory DNS 網域或 MX 網域。UPN 是選用的，並且會儲存在使用者的userPrincipalName欄位中。 - 端點網域：AD FS 伺服器等公用伺服器通常會獲派 DNS 名稱，例如
login.external.example.com。用於這些目的的網域可能會與 MX、UPN 後置字串或 Active Directory DNS 網域重疊，也可能是完全不同的網域。
在 Google Cloud中使用 DNS 網域
Google Cloud Google 登入服務用於驗證，會使用電子郵件地址來識別使用者。這樣的方式不僅可以確保全域中的電子郵件地址皆不重複，也讓 Google Cloud 可以傳送通知訊息至這些地址。
Google 登入會根據電子郵件地址的網域部分 (@ 之後的部分) 確認用於驗證使用者的目錄或識別資訊提供者。例如，對於使用 gmail.com 網域的電子郵件地址，Google 登入會使用 Gmail 使用者目錄進行驗證。
註冊 Google Workspace 或 Cloud Identity 帳戶時，您等同於是在建立「登入」功能可用來驗證的私人目錄。您需要將 Google Workspace 與 Cloud Identity 帳戶關聯至自訂網域，而方法恰與在 Gmail 目錄與 gmail.com 網域間建立關聯的方式相同。可使用的網域有以下數種：
- 主網域：這個網域會識別 Cloud Identity 或 Google Workspace 帳戶，同時也會做為 Google Cloud中的機構名稱使用。註冊 Cloud Identity 或 Google Workspace 時，您必須指定這個網域名稱。
- 次要網域：您可以將其他的次要網域與主網域一起關聯至 Cloud Identity 或 Google Workspace 帳戶。目錄中的每位使用者都與主網域或其中一個次要網域相關聯。如果
example.com是主網域，而secondary.example.com是次要網域，johndoe@example.com和johndoe@secondary.example.com這兩個使用者會被視為不同的使用者。 - 別名網域：別名網域是其他網域的替代名稱。也就是說，如果將
alias.example.com設為example.com的別名網域，johndoe@example.com和johndoe@alias.example.com就會指向相同使用者。
所有網域都必須滿足下列條件：
- 網域必須是有效的全域 DNS 網域名稱。設定期間，您可能需要各 DNS 區域的管理員權限，才能驗證網域擁有權。
example.com之類的網域只能指單一目錄，不過，您可以使用不同的子網域 (例如subdomain.example.com) 來指不同的目錄。- 主要與次要網域應該具有有效的 MX 記錄，這樣將訊息傳送至使用這個網域名稱構成的電子郵件地址時，才能正確傳遞。
為了順利完成目錄之間的同步處理，Active Directory 網域與 Cloud Identity 或 Google Workspace 使用的網域之間需要一些對應。是否能夠確認正確的對應，端視您如何使用 Active Directory，並且需要更深入地瞭解如何在 Active Directory 樹系中識別使用者，以及這些使用者可以如何對應至 Cloud Identity 或 Google Workspace。
Map users (對應使用者)
規劃連結 Active Directory 與Google Cloud 時，要關注的第三個因素是如何在 Active Directory 與 Cloud Identity 或 Google Workspace 之間對應使用者。
在 Active Directory 中識別使用者
Active Directory 在內部使用兩個 ID 來專門識別使用者：
objectGUID：這個全域不重複的 ID 會在建立使用者時產生，而且永遠不會變更。objectSID：SID (或稱安全性識別碼)，可用來進行所有存取權檢查作業。儘管此 ID 在網域中並不重複，也很穩定，但是使用者移動至樹系中的不同網域時，系統也可能會指派新的 SID。
這兩個 ID 對使用者而言都沒有意義，因此 Active Directory 提供兩種容易理解的方法來識別使用者：
UPN (
userPrincipalName)：比較適合識別使用者的方法是按 UPN 識別。UPN 遵循電子郵件地址的 RFC 822 格式，透過合併使用者名稱與 UPN 後置字串網域來建立，例如johndoe@corp.example.com。雖然 UPN 是比較適合識別使用者的方法，但 UPN 是選用的，因此 Active Directory 樹系中的某些使用者可能會缺少 UPN。儘管使用有效的電子郵件地址來當做 UPN 是一種最佳做法，但 Active Directory 並不強制採用這種做法。
Windows 2000 之前的登入名稱 (
sAMAccountName)：這個名稱會使用domain<var>user格式結合 NetBIOS 網域名稱和使用者名稱，如corp\johndoe所示。雖然這種命名方式屬於舊有做法，但目前仍相當常見，而且這也是使用者的唯一必要 ID。
要注意的是，Active Directory 並不採用使用者電子郵件地址 (mail) 來識別使用者，因此在樹系中，這個欄位並非必填，而且可以重複。
這些 ID 全都可以隨時變更。
對應使用者識別資訊
將 Active Directory 使用者對應至 Cloud Identity 或 Google Workspace 使用者，需要每位使用者的兩項資訊：
- 您可在同步處理期間使用的穩定、不重複的 ID，用以追蹤哪一個 Active Directory 使用者對應至 Cloud Identity 或 Google Workspace 中的哪一位使用者。就 AD 而言，
objectGUID非常適合這個目的。 - 網域部分對應至 Cloud Identity 或 Google Workspace 帳戶主網域、次要網域或別名網域的電子郵件地址。由於這個電子郵件地址將會在整個 Google Cloud中使用，因此請確保地址是正確的。從
objectGUID衍生而出的地址不能使用，而其他自動產生的電子郵件地址也是如此。
對於 Active Directory 使用者，有兩個欄位可用來提供 Cloud Identity 或 Google Workspace 電子郵件地址：userPrincipalName 和 mail。
依使用者主要名稱對應
使用 userPrincipalName 欄位時，系統會要求要同步處理的所有使用者符合兩個條件：
- 使用者主體名稱 (UPN) 必須是有效的電子郵件地址。做為 UPN 後置字串網域使用的所有網域也必須是 MX 網域，而且必須設定為將傳送至使用者 UPN 的電子郵件傳遞至其電子郵件收件匣。
必須完成 UPN 指派作業。要同步處理的所有使用者都必須指派 UPN。下列 PowerShell 指令可協助您尋找缺少 UPN 的使用者：
Get-ADUser -LDAPFilter "(!userPrincipalName=*)"
如果符合這兩個條件，您可以將 UPN 安全對應至 Cloud Identity 或 Google Workspace 電子郵件地址。您可以使用其中一個 UPN 後置字串網域做為 Cloud Identity 或 Google Workspace 中的主網域，並將其他任何 UPN 後置字串網域新增為次要網域。
如果不符合其中一個條件，您仍可將 UPN 對應至 Cloud Identity 或 Google Workspace 電子郵件地址，但請注意以下幾點：
- 如果 UPN 不是有效的電子郵件地址，使用者可能無法收到 Google Cloud傳送的通知電子郵件，而導致使用者遺失重要資訊。
- 沒有 UPN 的使用者會在同步處理期間遭到忽略。
- 您可以將同步處理設定為用不同的網域替換 UPN 後置字串網域。但是，當您使用樹系中的多個 UPN 後置字串網域時，這個方法可能會建立重複項目，因為所有 UPN 後置字串網域都將由單一網域取代。對於重複項目而言，只能同步處理單一使用者。
使用 UPN 對應使用者的一個主要優點在於，UPN 保證在樹系中是不重複的，而且會使用一組收錄的網域，這將有助於避免同步處理可能發生的問題。
依電子郵件地址對應
對於要同步處理的所有使用者而言，使用 mail 欄位需要符合下列條件：
必須完成電子郵件指派作業。要同步處理的所有使用者都必須填入
mail欄位。下列 PowerShell 指令可協助您尋找未填入此欄位的使用者：Get-ADUser -LDAPFilter "(!mail=*)"
電子郵件地址必須使用一組收錄的網域，而且這些網域全都為您所有。如果您的部分使用者使用的電子郵件地址參照了合作夥伴公司或消費者電子郵件提供者，則無法使用這些電子郵件地址。
所有電子郵件地址在樹系中都不得重複。由於 Active Directory 不會強制檢查不重複性，因此您可能必須自行檢查或套用自訂政策。
如果所有相關使用者都符合這些條件，您就能識別這些電子郵件地址使用的所有網域，並將這些網域當做 Cloud Identity 或 Google Workspace 中的主要網域與次要網域。
即便帳戶不符合任一項條件，您還是可以將電子郵件地址對應至 Cloud Identity 或 Google Workspace 電子郵件地址。不過，請注意以下事項：
- 在同步處理期間，系統會忽略沒有電子郵件地址的使用者，以及所含電子郵件地址使用的網域未連結至 Cloud Identity 或 Google Workspace 帳戶的使用者。
- 當兩位使用者共用相同電子郵件地址時，只會同步處理一位使用者。
- 您可以設定讓同步處理作業將電子郵件地址的網域替換為不同的網域。這個程序可能會建立重複項目，在這種情況下，只會同步處理一個使用者。
地圖群組
當您規劃連結 Active Directory 與 Google Cloud 時，要關注的第四個因素是是否在 Active Directory 與 Google Cloud 之間同步處理群組，以及對應群組的方式。
在 Google Cloud中，群組通常用來跨專案有效管理存取權。您不必為個別使用者指派每個專案中的 IAM 角色，而是可以根據機構中的常用角色定義一組群組，然後將這些群組指派給一組 IAM 角色。修改群組的成員資格之後，您可以控管使用者對於任何一組資源的存取權。
Active Directory 會區分兩種群組：通訊群組與安全性群組。通訊群組可用來管理電子郵件清單。當您要從 Microsoft Exchange 遷移至 Google Workspace 時，就會需要同步處理通訊群組，這樣 GCDS 就可以同時處理一般與動態通訊群組。不過，在 Google Cloud的身分與存取權管理中，通訊群組並不是問題，因此本討論會專注於安全性群組。
您可以自行選擇是否要在 Active Directory 與 Google Cloud 之間對應群組。設定使用者佈建後，您可以直接在 Cloud Identity 或 Google Workspace 中建立及管理群組，這表示 Active Directory 會保持為身分管理的中央系統，而非存取權管理的中央系統。如要將 Active Directory 同時保持為身分管理及存取權管理的中央系統，建議您從 Active Directory 同步處理安全性群組，而非在 Cloud Identity 或 Google Workspace 中管理安全性群組。透過這種方式，您可以設定 IAM，以便在 Active Directory 中使用群組成員資格控管誰在 Google Cloud中具有特定資源的存取權。
Active Directory 中的安全性群組
安全性群組在 Windows 安全性與 Active Directory 存取權管理中扮演了重要的角色。這個角色可以透過三種不同類型的 Active Directory 群組實現：「網域本機群組」、「全域群組」與「通用群組」。
- 網域本機群組
- 這些群組只在單一網域的範圍內具有相關性，無法在其他網域中參照。由於群組的成員清單不需要跨樹系複製，因此對於群組可以包含的成員類型而言，網域本機群組最具有彈性。
- 全域群組
- 這些群組會出現在其他網域中，並可在其他網域中參照，但不會複製群組的成員清單，這樣會限制這些群組可以包含的成員類型。這些群組只能包含相同網域中的使用者和其他全域群組。
- 通用群組
- 這些群組與其成員清單可跨樹系複製，因此可在其他網域中參照，除了使用者和其他通用群組外，也可包含所有網域中的全域群組。
如果您的 Active Directory 樹系只包含單一網域，您可以使用 GCDS 同步處理全部三種類型的安全性群組。如果您的 Active Directory 樹系使用多個網域，群組類型可決定其是否可同步至 Cloud Identity 或 Google Workspace，以及同步處理的方式。
由於網域本機與全域群組不會在整個樹系中完全複製，因此全域目錄伺服器會包含群組的不完整資訊。儘管此限制比較謹慎，而且可以協助加快目錄複製，但當您要將此類群組同步至 Cloud Identity 或 Google Workspace 時，還是會造成障礙。具體來說，如果您將 GCDS 設為使用全域目錄伺服器做為來源，這項工具就能在整個樹系中尋找所有網域的群組。不過，只有與全域目錄伺服器位於相同網域的群組才會包含成員名單，且適合用於複製。如要同步處理多網域樹系中的網域本機或全域群組，您必須為每個網域執行個別的 GCDS 執行個體。
由於通用群組會在整個樹系中完全複製，因此不受此限制。單一 GCDS 執行個體可從多個網域同步處理通用群組。
在推斷您需要多個 GCDS 執行個體來將多個 Active Directory 網域同步至 Cloud Identity 或 Google Workspace 之前，請記住並非所有群組都需要同步處理。因此，若能瞭解不同類型的安全性群組在整體 Active Directory 樹系中通常是如何使用，會非常值得。
在 Active Directory 中使用安全性群組
以下各節說明在 Active Directory 中使用的安全性群組類型。
資源群組
Windows 根據存取控制清單 (ACL) 使用存取模型。每種資源 (例如檔案或 LDAP 物件) 都有關聯的 ACL 可以控管哪些使用者能夠存取資源。資源與 ACL 受到非常完善的細部控制，因此會有許多資源與 ACL。為了簡化 ACL 的維護，建立「資源群組」來納入經常一起使用及存取的資源是一種很常見的做法。 您可以將資源群組一次新增到所有受影響的 ACL，並透過更改資源群組的成員資格來進一步管理存取權，而不用更改 ACL。
以這種方式納入的資源通常都存在於單一網域。因此，資源群組一般也只會在單一網域中參照，可能是 ACL，或者由其他資源群組參照。由於大多數資源群組都在本機，因此通常會使用 Active Directory 中的網域本機群組實作。
角色與機構群組
資源群組有助於簡化存取權管理，但是在大型環境中，您可能需要將新使用者新增至大量資源群組。因此，資源群組通常會透過「角色群組」或「機構群組」補充。
角色群組會匯總特定角色在機構中需要的權限。 舉例來說，名為「工程說明文件檢視者」的角色群組可能會為成員提供所有工程說明文件的唯讀存取權。事實上，如要達成此目的，您可以建立角色群組，並使該群組成為控制各種說明文件存取權的所有資源群組成員。
機構群組也可以透過類似方式匯總機構部門需要的權限。例如，名為「工程」的機構群組可以授予存取權給工程部門成員通常需要的所有資源。
就技術層面而言，角色群組與資源群組之間並無差異，這兩者通常會一起使用。但是，角色和機構群組可在網域邊界外具有關聯性，這點與資源群組不同。如要允許其他網域中的資源群組參照此類群組，角色與機構群組通常可以使用全域群組實作，這將僅限於單一網域的成員，有時候可透過通用群組來補充，進而允許來自其他網域的成員。
下圖顯示在多網域 Active Directory 環境中常用的巢狀模式。
Cloud Identity 和 Google Workspace 中的群組
在 Cloud Identity 和 Google Workspace 中，只有單一類型的群組。Cloud Identity 和 Google Workspace 中的群組不會因為已定義於 Cloud Identity 或 Google Workspace 帳戶之中，就受限於該帳戶的範圍內，而是能夠包含其他 Cloud Identity 或 Google Workspace 帳戶中的使用者，支援在其他帳戶中參照及處於其巢狀結構中，並且可以跨任何 Google Cloud 機構使用。
跟使用者一樣，Cloud Identity 和 Google Workspace 也會依電子郵件地址來識別群組。電子郵件地址不需要對應至實際的信箱，但必須使用所屬 Cloud Identity 帳戶已註冊的一個網域。
與 Active Directory 群組不同的是，Cloud Identity 或 Google Workspace 群組的成員無法間接取得列出同一群組其他成員清單的權限。相反地，若要查詢群組成員，一般都需要明確的授權。
在 Google Cloud中使用群組
Google Cloud 使用依角色提供的存取模型，而非依 ACL 提供的存取模型。角色適用於特定範圍內特定類型的所有資源。例如，「Kubernetes Engine 開發人員」角色能夠完全存取特定專案所有叢集中的 Kubernetes API 物件。有鑑於角色的特性，並不太需要在 Google Cloud上維護資源群組，更不太需要將資源群組同步至 Google Cloud。
角色群組與機構群組可以讓您輕鬆管理大量使用者的存取權，因此在 Google Cloud和 Active Directory 中一樣重要。同步處理角色與機構群組有助於將 Active Directory 保持為管理存取權的主要位置。
如果您持續將資源群組實作為網域本機群組，並將角色與機構群組實作為通用群組，便可使用群組類型來確認只會同步處理角色與機構群組。
如果您本來懷疑為每個多網域樹系執行單一 GCDS 執行個體是否足夠，或者是否需要多個 GCDS 執行個體，那麼現在的問題會變成是否要使用全域群組。如果您使用通用群組來實作所有角色與機構群組，那麼單一 GCDS 執行個體就夠了；否則，您的每個網域將需要一個 GCDS 執行個體。
對應群組 ID
將 Active Directory 安全性群組對應至 Cloud Identity 或 Google Workspace 群組需要有通用 ID。在 Cloud Identity 和 Google Workspace 中，這個 ID 必須是網域部分對應至 Cloud Identity 或 Google Workspace 帳戶的主網域、次要網域或別名網域的電子郵件地址。由於這個電子郵件地址將在整個 Google Cloud中使用，因此這個地址必須是使用者可以理解的地址。電子郵件地址不需要對應至信箱。
在 Active Directory 中，群組會依其慣用名稱 (cn) 或 Windows 2000 之前的登入名稱 (sAMAccountName) 識別。群組與使用者帳戶類似，也可以擁有電子郵件地址 (mail)，但電子郵件地址是群組的選用屬性，Active Directory 不會驗證不重複性。
您有兩個選項可以在 Active Directory 與 Cloud Identity 或 Google Workspace 之間對應群組 ID。
依慣用名稱對應
使用慣用名稱 (cn) 的優點是可以保證名稱一定可用，而且至少在機構單位之內不會重複。但是，慣用名稱並非電子郵件地址，因此需要加上後置字串 @DOMAIN 才能轉換成電子郵件地址。
您可以設定 GCDS，讓系統自動為群組名稱加上後置字串。由於 Active Directory 會確認群組名稱與使用者名稱不衝突，因此以這種方式衍生的電子郵件地址也不太可能會產生任何衝突。
如果您的 Active Directory 樹系中包含單一網域，請注意以下幾點：
- 如果不同網域中的兩個群組共用一個慣用名稱，衍生的電子郵件地址將會產生衝突，導致在同步處理期間忽略一個群組。
- 您只能從單一樹系的網域同步處理群組。如果使用單獨的 GCDS 執行個體同步處理多個樹系的群組，從慣用名稱衍生的電子郵件地址就不會反映出對應的樹系。這種模稜兩可的情形將會導致 GCDS 執行個體刪除之前由其他 GCDS 執行個體從不同樹系中建立的任何群組。
- 如果您使用網域替代來對應使用者，就無法按慣用名稱對應群組。
依電子郵件地址對應
使用電子郵件地址 (mail) 對應群組 ID 表示您必須符合與使用電子郵件對應使用者時相同的條件：
必須完成電子郵件指派作業。儘管通訊群組擁有電子郵件地址是一件很平常的事，但安全性群組經常會缺少這個屬性。如要使用電子郵件地址對應 ID，要進行同步處理的安全性群組必須填入
mail欄位。下列 PowerShell 指令可以協助您找到未填入此欄位的帳戶：Get-ADGroup -LDAPFilter "(!mail=*)"
電子郵件地址必須使用一組收錄的網域，而且這些網域全都為您所有。如果您的部分使用者使用的電子郵件地址參照了合作夥伴公司或消費者電子郵件提供者，則無法使用這些地址。
所有電子郵件地址在樹系中都不得重複。由於 Active Directory 不會強制檢查不重複性，因此您可能必須自行檢查或套用自訂政策。
如果所有相關群組都符合這些條件，您可以識別這些電子郵件地址使用的所有網域，確認在 Cloud Identity 或 Google Workspace 中註冊的 DNS 網域清單包含這些網域。
如果不符合其中一個條件，您仍可將 UPN 對應至 Cloud Identity 或 Google Workspace 電子郵件地址，但請注意以下幾點：
- 在同步處理期間，沒有電子郵件地址的群組將會遭到忽略，有網域但使用的網域與 Cloud Identity 或 Google Workspace 帳戶無關聯的電子郵件地址也會遭到忽略。
- 當兩個群組共用相同電子郵件地址時，只會同步處理一個群組。
如果您的 Active Directory 樹系中包含多個網域，而且您使用網域替代來對應使用者，就不支援按電子郵件地址對應群組。
對應機構單位
大多數 Active Directory 網域都大量使用機構單位來按階層分群及整理資源、控管存取權，以及強制執行政策。
在 Google Cloud中，資料夾和專案的目的相似，但在 Google Cloud 機構中管理的資源種類與在 Active Directory 中管理的資源非常不同。因此，企業的適當 Google Cloud資料夾階層很可能與 Active Directory 中的機構單位結構明顯不同。因此，將機構單位自動對應至資料夾與專案很難符合實際需求，GCDS 也不支援這種做法。
Cloud Identity 和 Google Workspace 與資料夾無關，而且支援機構單位的概念。機構單位會建立來分群及整理使用者，這與 Active Directory 類似。但是與 Active Directory 不同的是，機構單位僅適用於使用者，而不適用於群組。
GCDS 提供將 Active Directory 機構單位同步至 Cloud Identity 或 Google Workspace 的選項。在 Cloud Identity 僅用來將 Active Directory 身分管理延伸至 Google Cloud的設定中，通常不需要對應機構單位。
選擇正確的對應
如本文開頭所述，對應 Active Directory 與 Google Cloud的結構並沒有什麼絕對的最佳做法。為了協助您選擇符合情境的正確對應方法，以下決策圖匯總了在前文中討論的條件。
首先，請參閱下圖來瞭解您將需要多少 Cloud Identity 或 Google Workspace 帳戶、GCDS 執行個體與 AD FS 執行個體或群體。
然後請參閱第二個圖表，找出要在 Cloud Identity 或 Google Workspace 帳戶中設定的網域。
後續步驟
- 請參閱規劃帳戶和機構的最佳做法，以及連結 Google Cloud 與外部識別資訊提供者的最佳做法 Google Cloud 。
- 設定 GCDS 以將 Active Directory 使用者和群組同步至 Cloud Identity。
- 設定 Active Directory 與 Google Cloud之間的單一登入。
- 瞭解管理超級管理員帳戶的最佳做法