將 Google Cloud 與 Microsoft Entra ID (原稱 Azure AD) 進行整合

本文說明如何設定 Cloud Identity 或 Google Workspace，將 Microsoft Entra ID (原稱「Azure AD」) 做為 IdP 和身分來源。

這份文件會比較 Microsoft Entra ID 的邏輯結構與 Cloud Identity 和 Google Workspace 使用的結構，並說明如何對應 Microsoft Entra ID 租戶、網域、使用者和群組。

實作聯盟

Google Cloud 使用 Google 身分進行驗證及存取權管理。當所有員工都擁有 Microsoft Entra ID 帳戶時，手動維護每位員工的 Google 身分會增加不必要的管理負擔。在 Google Cloud 與現有身分管理系統之間連結使用者身分後，您就可以將 Google 身分的維護工作自動化，並將身分生命週期連結至 Microsoft Entra ID 中的現有使用者。

設定 Microsoft Entra ID 與 Cloud Identity 或 Google Workspace 之間的連結涉及兩個部分：

• 佈建使用者：相關使用者和群組會定期從 Microsoft Entra ID 同步至 Cloud Identity 或 Google Workspace。這個程序可確保在 Microsoft Entra ID 中建立新使用者，或將新使用者從 Active Directory 同步至 Microsoft Entra ID 時，該使用者也能在 Google Cloud 中參照，甚至在關聯使用者第一次登入前，就能在 Google Cloud 中參照該使用者。這個程序也可以確保使用者刪除程序確實生效。

  佈建作業是單向的，也就是說，Microsoft Entra ID 中的變更會複製到 Google Cloud ，但反過來就不行。此外，佈建作業不包含密碼。

• 單一登入：每當使用者需要驗證時， Google Cloud會使用安全宣告標記語言 (SAML) 通訊協定，將驗證作業委派給 Microsoft Entra ID。根據您的 Microsoft Entra ID 設定，Microsoft Entra ID 可能會執行下列其中一項操作：

  • 自行執行驗證。
  • 使用傳遞驗證或密碼雜湊同步處理。
  • 將驗證作業交由內部部署 AD FS 伺服器處理。

讓 Cloud Identity 或 Google Workspace 將驗證作業交由 Microsoft Entra ID 處理不僅無須將密碼同步至Google Cloud，也可以確保您在 Microsoft Entra ID 或 AD FS 中設定的任何適用政策或多重驗證 (MFA) 機制會確實執行。

Microsoft Entra ID 的邏輯結構

使用 Azure 時，您會使用一或多個 Microsoft Entra ID 用戶群 (又稱為「目錄」)。Microsoft Entra ID 租戶是頂層結構，您可以將這類用戶群視為管理邊界，並做為使用者、群組及資源和資源群組的容器。

每個 Microsoft Entra ID 租戶都至少有一個與其關聯的 DNS 網域。這個 DNS 網域會反映在使用者名稱中 (亦稱為「使用者主要名稱」，英文簡稱為 UPN)，其格式為 name@domain，其中 domain 是與對應的租戶相關聯的 DNS 網域。

一家企業可能有多個 Microsoft Entra ID 租戶。有多個用戶群的常見原因包括為了區分機構的不同組成部分、分隔實際工作環境資源與開發和測試資源，以及使用不同的用戶群來整合內部部署 Active Directory 中的多個樹系。

Google Cloud的邏輯結構

在 Google Cloud中，機構會做為所有資源的容器，並且可以使用資料夾與專案進一步區隔這些資源。但是，除了服務帳戶以外，機構不能用來管理使用者和群組，所以機構不同於 Microsoft Entra ID 用戶群。

如要管理使用者和群組， Google Cloud 必須使用 Cloud Identity 或 Google Workspace。Cloud Identity 或 Google Workspace 帳戶可做為使用者和群組的私人目錄。帳戶管理員可以控管使用者和群組的生命週期和設定，並定義驗證方式。

建立 Cloud Identity 或 Google Workspace 帳戶時，系統會自動為您建立 Google Cloud 機構。Cloud Identity 或 Google Workspace 帳戶及其關聯的 Google Cloud 機構會共用相同名稱並彼此連結在一起。不過，Google Cloud 機構可以從其他 Cloud Identity 或 Google Workspace 帳戶參照使用者和群組。

整合 Microsoft Entra ID 和 Google Cloud

儘管 Microsoft Entra ID 與Google Cloud的邏輯結構之間具有某些相似性，但無論採取哪一種方式在兩種結構間進行對應，都不可能滿足所有使用情況。整合兩個系統和對應結構的正確方法取決於多項因素：

• 如何將 Microsoft Entra ID 租戶對應至 Cloud Identity 或 Google Workspace 帳戶
• 如何對應 DNS 網域
• 如何對應使用者
• 如何對應群組

以下幾節會逐一介紹這些因素。

Google Cloud 僅能與 Microsoft Entra ID 互動，而不能與內部部署的 Active Directory 互動。因此，將內部部署 Active Directory 的樹系對應至 Microsoft Entra ID 的方式不會有很大的影響。

對應 Microsoft Entra ID 租戶

下列各節說明如何針對這些情境對應 Microsoft Entra ID 租戶：

• 單一租戶
• 多個用戶群
• 外部使用者

單一用戶群

如果您只使用一個 Microsoft Entra ID 用戶群，那麼可以將這個用戶群對應至單一 Cloud Identity 或 Google Workspace 帳戶，並設定兩者之間的連結，然後這個帳戶會提供單一 Google Cloud 機構的基礎，讓您用來管理所有 Google Cloud 資源。

多個用戶群

在較大機構中，通常會有多個 Microsoft Entra ID 用戶群的情況。多個用戶群可用來區分測試與實際工作環境，或機構的不同組成部分。

您可以將多個 Microsoft Entra ID 租用戶對應至單一 Cloud Identity 或 Google Workspace 帳戶，並據此設定使用者帳戶佈建和單一登入。不過，這種 N:1 對應可能會削弱 Microsoft Entra ID 租用戶之間的隔離效果：如果您授予多個 Microsoft Entra ID 租用戶權限，讓他們在單一 Cloud Identity 或 Google Workspace 帳戶中建立及修改使用者，這些租用戶可能會互相干擾及竄改彼此的變更。

一般來說，與多個 Microsoft Entra ID 用戶群整合的較佳做法，是為每個用戶群分別建立 Cloud Identity 或 Google Workspace 帳戶，並設定各個組合之間的連結。

在 Google Cloud中，系統會為每個 Cloud Identity 或 Google Workspace 帳戶建立個別機構。由於 Google Cloud 允許使用單一機構內的專案和資料夾來分類資源，所以擁有多個機構通常不太符合實際需求。不過，您可以選取一個機構，並將其關聯至其他 Cloud Identity 或 Google Workspace 帳戶，有效建立與多個 Active Directory 樹系連結的機構。其他機構則保持不使用。

外部使用者

使用 Microsoft Entra ID B2B 時，您可以邀請外部使用者以訪客身分加入 Microsoft Entra ID 用戶群。系統會為每位訪客建立新的使用者，而 Microsoft Entra ID 會自動將 UPN 指派給這些訪客使用者。Microsoft Entra ID 產生的 UPN 會使用受邀者電子郵件地址衍生的前置字串，再加上用戶群的初始網域，也就是：prefix#EXT#@tenant.onmicrosoft.com。

從 Microsoft Entra ID 將訪客使用者佈建至 Cloud Identity 或 Google Workspace 時，會受到下列限制：

• 您無法將訪客使用者的 UPN 對應至 Cloud Identity 或 Google Workspace 中的電子郵件地址，因為 onmicrosoft.com 是無法在 Cloud Identity 或 Google Workspace 中新增及驗證的網域。因此，您必須使用 UPN 以外的屬性對應使用者。
• 如果主房客中的訪客使用者遭到停權，Cloud Identity 或 Google Workspace 中對應的使用者可能仍處於有效狀態，且資源存取權可能無法正確撤銷。 Google Cloud

如要處理源自不同 Microsoft Entra ID 用戶群的訪客使用者，更好的方式是建立多個 Cloud Identity 或 Google Workspace 帳戶 (如上節所述)，並將每個帳戶連結至不同的 Microsoft Entra ID 用戶群。詳情請參閱「Microsoft Entra ID B2B 使用者佈建和單一登入」

如要授予外部使用者存取某些 Google Cloud 資源的權限，使用者並不一定要先具備 Cloud Identity 或 Google Workspace 使用者帳戶。除非政策設有限制，否則只要使用者有 Google 身分，您也可以直接新增外部使用者到專案、資料夾或機構中，讓使用者成為該專案、資料夾或機構的成員。

對應 DNS 網域

DNS 在 Microsoft Entra ID 與 Cloud Identity 和 Google Workspace 中都扮演重要角色。規劃連結 Microsoft Entra ID 與 Google Cloud 時，要關注的第二個因素是如何在 Microsoft Entra ID 與 Google Cloud之間共用或對應 DNS 網域。

在 Google Cloud中使用 DNS 網域

Google 登入機制用以進行驗證，並使用電子郵件地址來識別使用者。 Google Cloud 這樣的方式不僅可以確保全域中的電子郵件地址皆不重複，也讓 Google Cloud 可以傳送通知訊息至這些地址。

Google 登入會根據電子郵件地址的網域部分 (@ 之後的部分) 確認用於驗證使用者的目錄或識別資訊提供者。例如，對於使用 gmail.com 網域的電子郵件地址，Google 登入會使用 Gmail 使用者目錄進行驗證。

註冊 Google Workspace 或 Cloud Identity 帳戶時，您等同於是在建立 Sign-In 可用來進行驗證的私人目錄。您需要將 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 記錄，這樣將訊息傳送至使用這個網域名稱構成的電子郵件地址時，才能正確傳遞。

在 Microsoft Entra ID 中使用 DNS 網域

Cloud Identity 和 Google Workspace 使用 DNS 的方式，類似於 Microsoft Entra ID 使用 DNS 來區分 Microsoft Entra ID 用戶群，以及建立使用者名稱與用戶群的關聯。但請注意兩個明顯差異：

1. 初始網域：建立 Microsoft Entra ID 租戶時，租戶會與「初始網域」相關聯，而初始網域是 onmicrosoft.com 的子網域。這個網域不同於任何您可能註冊的自訂網域名稱，這是因為此網域非您所有，而且您沒有各 DNS 區域的管理員權限。

   Cloud Identity 沒有與初始網域等效的項目，因而會要求您必須擁有與 Cloud Identity 帳戶相關聯的所有網域，也就是說，您不能將 onmicrosoft.com 子網域註冊為 Cloud Identity 網域。

2. 在使用者 ID 中使用的網域：Microsoft Entra ID 會區分電子郵件地址 MOERA (Microsoft Online Email Routing Address) 與 UPN。兩者皆採用 RFC 822 格式 (user@domain)，但用途不同：UPN 用於在登入表單中識別使用者，而傳遞電子郵件時只會使用 MOERA。

   UPN 使用的網域字尾必須與 Microsoft Entra ID 用戶群的一個註冊網域相符，但電子郵件地址不適用這項要求。

   Cloud Identity 和 Google Workspace 不採用 UPN 的概念，而是以使用者的電子郵件地址做為 ID。因此，電子郵件地址所用的網域必須與 Cloud Identity 或 Google Workspace 帳戶的一個註冊網域相符。

Microsoft Entra ID 租用戶和 Cloud Identity 或 Google Workspace 帳戶可以使用相同的 DNS 網域。如果無法使用相同網域，您可以設定使用者佈建和單一登入，以替代網域名稱。

考量上述兩個差異，您應以自己的網域對應為基礎，來規劃 Microsoft Entra ID 與 Cloud Identity 或 Google Workspace 之間對應使用者的方式。

Map users (對應使用者)

規劃連結 Microsoft Entra ID 與Google Cloud 時，要關注的第三個因素是如何在 Microsoft Entra ID 與 Cloud Identity 或 Google Workspace 之間對應使用者。

如要順利將 Microsoft Entra ID 使用者對應至 Cloud Identity 或 Google Workspace 中的使用者，需要每個使用者的兩項資訊：

1. 您可在同步處理期間使用的穩定且不重複的 ID，用以追蹤哪一個 Microsoft Entra ID 使用者對應至哪一個 Cloud Identity 或 Google Workspace 使用者。
2. 網域部分對應至 Cloud Identity 主網域、次要網域或別名網域的電子郵件地址。由於這個電子郵件地址將在整個 Google Cloud中使用，因此這個地址必須是使用者可以理解的地址。

Microsoft Entra ID 會在內部透過 ObjectId 識別使用者。ObjectId 是隨機產生且在全域中不重複的 ID。由於這是穩定 ID，因此符合第一個條件，對使用者來說不具意義，也不會遵循電子郵件地址的格式。如要對應使用者，唯一可行的做法是依 UPN 或電子郵件地址進行對應。

如果使用者輸入的電子郵件地址屬於某個 Cloud Identity 或 Google Workspace 帳戶，且此帳戶已設為對 Microsoft Entra ID 使用單一登入，則系統會接著將使用者重新導向至 Microsoft Entra ID 登入畫面。

Microsoft Entra ID 使用 UPN 而非電子郵件地址來識別使用者，因此登入畫面會提示使用者提供 UPN。

如果 Microsoft Entra ID 用戶群設為使用 AD FS 進行登入，則系統會再次執行重新導向並將使用者帶到 AD FS 登入畫面。AD FS 會根據 Active Directory UPN 或 Windows 2000 之前版本的登入名稱 (domain\user) 識別使用者。

如果用於 Cloud Identity 或 Google Workspace 的電子郵件地址、Microsoft Entra ID 所用的 UPN 和 Active Directory 所用的 UPN 都不同，則登入畫面的順序可能會讓使用者感到困惑。相對的，如果這三個 ID 全都相同，如範例螢幕擷取畫面所示 (johndoe@example.com)，那麼使用者就不會感覺到 UPN 與電子郵件地址之間的技術差異，以儘可能避免引起使用者的混淆。

依 UPN 對應

從使用者體驗的觀點來看，將 Microsoft Entra ID UPN 對應至 Cloud Identity 或 Google Workspace 電子郵件地址或許是最好的選擇。使用 UPN 的另一個好處是 Microsoft Entra ID 可保證不重複性，如此即可避免命名衝突的風險。

然而，如要將 Microsoft Entra ID UPN 對應至 Cloud Identity 電子郵件地址，必須符合以下條件：

• Microsoft Entra ID UPN 應為有效電子郵件地址，這樣 Google Cloud 寄出的所有通知電子郵件就會正確送達使用者的信箱。如果不是這樣，也許可以設定別名電子郵件地址，以確保使用者能收到這類的電子郵件。
• 在 Microsoft Entra ID 中，所有相關使用者的 UPN 都必須使用自訂網域做為尾碼 (user@custom-domain)。使用 Microsoft Entra ID 初始網域 (user@tenant.onmicrosoft.com) 的 UPN 無法對應至 Cloud Identity 中的電子郵件地址，因為初始網域並非您所有，而是為 Microsoft 所有。
• 由 Microsoft Entra ID 用於 UPN 的所有自訂網域也必須在 Cloud Identity 中完成註冊。也就是說，您必須擁有各 DNS 區域的存取權，才能執行網域驗證。為了避免覆寫您為在 Microsoft Entra ID 中驗證網域擁有權而建立的現有 TXT DNS 記錄，您可在 Cloud Identity 中使用 CNAME 記錄來驗證網域擁有權。

依電子郵件地址對應使用者

如果無法將 Microsoft Entra ID UPN 對應至 Cloud Identity 或 Google Workspace 電子郵件地址，您可以依電子郵件地址對應使用者。

在 Active Directory 中指定電子郵件地址時，該地址會儲存在相應 user 物件的 mail 屬性中，而 Microsoft Entra ID Connect 會將該值同步至 Microsoft Entra ID 中的 Mail 屬性。Microsoft Entra ID 也會提供屬性供使用者佈建，因此您可以將屬性對應至 Cloud Identity 或 cloudid_name_short 中的電子郵件地址。

至關重要的一點是，Microsoft Entra ID Mail 屬性目前不會顯示在 Azure 入口網站中，並且只能透過 API 或 PowerShell 進行查看和編輯。雖然使用者介面可讓您指定電子郵件地址和備用電子郵件地址，但這兩個值都不會儲存在 Mail 屬性中，因此不能用於佈建到 Cloud Identity 或 cloudid_name_short 的作業。因此，只有您在 Active Directory 中 (而不是 Microsoft Entra ID) 進行大部分的使用者建立和編輯作業時，對應電子郵件地址的使用者才有實際效用。

如果要依電子郵件地址對應使用者，另外還須符合以下條件：

• 必須完成電子郵件指派作業。所有要同步處理的使用者都必須有指派的電子郵件地址。但是從內部部署 Active Directory 同步處理使用者時，情況可能就不是這樣了，因為 mail 是 Active Directory 中的選用使用者屬性。系統會在同步處理時，以無訊息的方式忽略在 Microsoft Entra ID Mail 屬性中沒有電子郵件地址的使用者。
• Microsoft Entra ID 用戶群中的電子郵件地址不得重複。雖然 Active Directory 在建立使用者時不會檢查不重複性，但 Microsoft Entra ID Connect 預設會偵測衝突，如有衝突，可能會導致受影響使用者的同步作業失敗。
• 電子郵件地址使用的網域無須於 Microsoft Entra ID 註冊，但必須在 Cloud Identity 或 Google Workspace 中完成註冊。也就是說，您必須擁有各 DNS 區域的存取權，才能執行網域驗證，並且會排除使用非您所有網域 (例如 gmail.com) 的電子郵件地址。

描繪使用者生命週期

定義 Microsoft Entra ID 使用者與 Cloud Identity 或 Google Workspace 中使用者的對應關係後，您必須決定要佈建哪些使用者。如需相關指引，請參閱身分識別組合對應最佳做法。

如果不想佈建 Microsoft Entra ID 租戶的所有使用者，可以透過使用者指派或範圍篩選器，為部分使用者啟用佈建功能。

下表摘要說明 Microsoft Entra ID 佈建的預設行為，並顯示啟用或停用使用者佈建功能後，Microsoft Entra ID 會在 Cloud Identity 或 Google Workspace 中執行哪些動作。

已為 Microsoft Entra ID 使用者啟用佈建功能	Cloud Identity 或 Google Workspace 中的使用者狀態	在 Microsoft Entra ID 中執行的動作	在 Cloud Identity 或 Google Workspace 中執行的動作
否	(不存在)	啟用佈建	建立新使用者 (*)
否	存在 (有效)	啟用佈建	更新現有使用者
否	存在 (已停權)	啟用佈建	更新現有使用者，維持停權狀態
是	已存在	修改使用者	更新現有使用者
是	已存在	重新命名 UPN/電子郵件地址	變更主要電子郵件地址，保留先前的地址做為別名
是	已存在	停用佈建功能	將使用者停權
是	已存在	虛刪除使用者	將使用者停權

(*) 如果有電子郵件地址相同的個人帳戶，該帳戶會遭到逐出。

地圖群組

當您規劃連結 Microsoft Entra ID 與 Google Cloud 時，要關注的第四個因素是是否在 Microsoft Entra ID 與 Google Cloud 之間同步處理群組，以及對應群組的方式。

在 Google Cloud中，群組常用來做為跨專案有效管理存取權的一種方式。您不必為個別使用者指派每個專案中的 IAM 角色，而是可以根據機構中的常用角色定義一組群組，然後將這些群組指派給一組 IAM 角色。 修改群組的成員資格之後，您可以控管使用者對於任何一組資源的存取權。

您可以自行選擇是否要在 Microsoft Entra ID 與 Google Cloud 之間對應群組。設定使用者帳戶佈建後，您可以直接在 Cloud Identity 或 Google Workspace 中建立及管理群組，這表示 Active Directory 或 Microsoft Entra ID 會保持為身分管理的中央系統，而非存取權管理的中央系統。 Google Cloud

如要將 Active Directory 或 Microsoft Entra ID 同時保持為身分管理及存取權管理的中央系統，建議您從 Microsoft Entra ID 同步處理群組，而非在 Cloud Identity 或 Google Workspace 中管理群組。透過這種方式，您可以設定 IAM，以在 Active Directory 或 Microsoft Entra ID 中使用群組成員資格，控管誰在 Google Cloud中具有特定資源的存取權。

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 帳戶已註冊的一個網域。

在 IAM 中使用群組時，您通常需要依據電子郵件地址而非名稱來指定群組。所以群組最好不只有一個具意義的名稱，還需一個有意義且可辨識的電子郵件地址。

Microsoft Entra ID 中的群組

Microsoft Entra ID 支援多種類型的群組，每種類型各有不同用途。群組的範圍僅限單一租戶，並由物件 ID 識別，這是隨機產生的全域專屬 ID。群組可以巢狀結構呈現，且可包含來自相同租戶的使用者，或使用 Azure B2B 從其他租戶邀請的使用者。Microsoft Entra ID 也支援動態群組，系統會根據查詢自動決定成員。

在整合 Microsoft Entra ID 與 Cloud Identity 或 Google Workspace 的情況下，群組的兩個屬性是主要重點，即群組是否啟用郵件功能，以及是否啟用安全功能：

• 啟用安全功能的群組可用來管理 Microsoft Entra ID 中的資源存取權，因此，任何啟用安全功能的群組都可能與 Google Cloud相關。
• 啟用郵件功能的群組具有電子郵件地址，這個地址很重要，因為 Cloud Identity 和 Google Workspace 需要依據電子郵件地址來識別群組。

您可以在 Microsoft Entra ID 中建立類型為「安全性」或 Office 365 (有時稱為整合式群組) 的群組。從內部部署 Active Directory 同步處理群組或使用 Office 365 類型時，您也可以建立類型為「通訊群組清單」的群組。

下表大致列出有關啟用郵件功能或啟用安全功能時，上述不同類型群組的差異，以及假設使用預設 Microsoft Entra ID Connect 設定時，這些類型如何對應至 Active Directory 群組類型：

來源	Active Directory 群組類型	Microsoft Entra ID 群組類型	啟用郵件功能	啟用安全功能
Microsoft Entra ID	-	Office 365 群組	一律啟用	選用
Microsoft Entra ID	-	安全性群組	選用	一律啟用
內部部署	安全性群組 (含電子郵件地址)	安全性群組	是	是
內部部署	安全性群組 (無電子郵件地址)	安全性群組	否	是
內部部署	通訊群組清單 (含電子郵件)	通訊群組清單	是	否
內部部署	通訊群組清單 (不含電子郵件)	(Microsoft Entra ID Connect 會忽略此屬性)

與使用者不同，Microsoft Entra ID 會要求指派給群組的電子郵件地址使用已在 Microsoft Entra ID 中註冊為自訂網域的網域。這項規定會導致下列預設行為：

• 如果 Active Directory 中的群組使用的電子郵件地址使用過去已在 Microsoft Entra ID 中註冊的網域，那麼在同步至 Microsoft Entra ID 時，系統會正確保留這個電子郵件地址。
• 如果 Active Directory 中的群組使用的電子郵件地址尚未在 Microsoft Entra ID 中註冊，則 Microsoft Entra ID 會在同步處理時自動產生一個新的電子郵件地址。這個電子郵件地址將會使用用戶群的預設網域。如果您的用戶群使用初始網域做為預設網域，則產生的電子郵件地址將會使用[name]@[tenant].onmicrosoft.com格式。
• 如果您在 Microsoft Entra ID 中建立 Office 365 群組，Microsoft Entra ID 也會自動產生電子郵件地址，而這個地址將會使用用戶端的預設網域。

對應群組 ID

如要將 Microsoft Entra ID 群組順利對應至 Cloud Identity 或 Google Workspace 群組，必須使用通用 ID，且該 ID 必須是電子郵件地址。對 Microsoft Entra ID 來說，這項要求留給您兩個選擇：

• 您可以使用 Microsoft Entra ID 中群組的電子郵件地址，然後將其對應至 Cloud Identity 或 Google Workspace 電子郵件地址。
• 您可以從 Microsoft Entra ID 中群組的名稱衍生電子郵件地址，然後將產生的地址對應至 Cloud Identity 或 Google Workspace 中的電子郵件地址。

依電子郵件地址對應

依電子郵件地址對應群組是最理所當然的選擇，但必須符合幾個條件：

• 要同步處理的所有群組都必須有電子郵件地址。在具體做法上，這表示您只能同步啟用郵件功能的群組。系統會在佈建時忽略沒有電子郵件地址的群組。
• 在整個用戶群中，電子郵件地址不得重複。由於 Microsoft Entra ID 不會強制檢查不重複性，因此您可能必須實作自訂檢查或自訂政策。
• 您必須同時在 Microsoft Entra ID 和 Cloud Identity 或 Google Workspace 中註冊電子郵件地址所用的網域。任何群組的電子郵件地址如使用尚未在 Cloud Identity 或 Google Workspace 中註冊的網域 (包括 tenant.onmicrosoft.com 網域)，系統將無法同步這些群組。

如果所有相關群組都符合這些條件，請找出這些電子郵件地址使用的網域，並確認在 Cloud Identity 或 Google Workspace 中註冊的 DNS 網域清單包含這些網域。

依名稱對應

符合依電子郵件地址對應群組所需的條件可能不太容易，特別是您要佈建至 Cloud Identity 或 Google Workspace 的安全性群組大多沒有啟用郵件功能時。在這種情況下，可能更適合從群組的顯示名稱自動衍生電子郵件地址。

衍生電子郵件地址存在兩項挑戰：

1. 衍生自群組名稱的電子郵件地址可能與使用者的電子郵件地址衝突。
2. Microsoft Entra ID 不會強制檢查群組名稱的不重複性。如果 Microsoft Entra ID 用戶群中有多個群組共用相同名稱，那麼衍生自這個名稱的電子郵件地址將會發生衝突，進而造成只有一個群組可以成功同步處理。

您可以將使用者所用網域以外的不同網域用於產生電子郵件地址，以克服第一個挑戰。舉例來說，如果所有使用者使用的電子郵件地址以 example.com 為網域，那麼您可以將 groups.example.com 用於所有群組。在 Cloud Identity 或 Google Workspace 中註冊子網域時，不會要求驗證網域，所以 DNS 區域 groups.example.com 甚至不需要存在。

如要解決第二個問題 (群組名稱重複)，您只能從物件 ID 衍生群組電子郵件地址，因為產生的群組名稱相當隱晦，難以使用，因此最好先在 Microsoft Entra ID 中找出並重新命名重複的群組名稱，再設定佈建至 Cloud Identity 或 Google Workspace。

繪製群組生命週期圖

定義 Microsoft Entra ID 群組與 Cloud Identity 或 Google Workspace 中群組的對應關係後，您必須決定要佈建哪一組群組。與使用者類似，您可以使用群組指派或範圍篩選器，為部分群組啟用佈建功能。

下表彙整了 Microsoft Entra ID 佈建的預設行為，並說明啟用或停用群組佈建功能後，Microsoft Entra ID 會在 Cloud Identity 或 Google Workspace 中執行哪些動作。

已為 Microsoft Entra ID 群組啟用佈建功能	Cloud Identity 或 Google Workspace 中的群組狀態	在 Microsoft Entra ID 中執行的動作	在 Cloud Identity 或 Google Workspace 中執行的動作
否	(不存在)	啟用佈建	建立新群組
否	已存在	啟用佈建	新增成員，保留所有現有成員
是	已存在	重新命名群組	重新命名群組
是	已存在	修改說明	更新說明
是	已存在	新增成員	新增成員，保留所有現有成員
是	已存在	移除成員	移除成員
是	已存在	停用佈建功能	群組維持原狀 (包括成員)
是	已存在	刪除群組	群組維持原狀 (包括成員)

後續步驟

• 請參閱規劃帳戶和機構的最佳做法，以及連結外部身分識別提供者的最佳做法 Google Cloud 。
• 瞭解如何設定 Microsoft Entra ID 與 Cloud Identity 之間的佈建和單一登入。
• 瞭解管理超級管理員帳戶的最佳做法。