連結 Google Cloud Platform 與 Active Directory:簡介

針對如何將現有的 Active Directory 身分識別管理解決方案延伸到 Google Cloud Platform (GCP),我們提供了一系列的文章加以探討,而本文是該系列的第一單元。本文說明如何在混合運算環境中建立一致的驗證與授權機制,並聚焦於如何使用 Cloud Identity,不過某些討論內容適用於 G Suite

本系列包含以下單元:

企業的 IT 部門通常會依賴 Active Directory 管理使用者帳戶,以及控管應用程式與運算資源的存取權。這樣的依存關係使 Active Directory 成為 IT 環境與內部部署基礎架構的基石。

當您將現有 IT 環境延伸到 GCP 成為混合策略的一部分時,您會想要在單一位置管理身分。擁有單一身分管理解決方案可以將花費在管理上的精力降到最低,並協助確保使用者與應用程式都能安全地在混合環境中進行驗證。

本文會對 Active Directory 與 GCP 的邏輯結構進行比較,並討論各種方式,讓您瞭解該如何將 Active Directory 帳戶對應至 GCP 的使用者與群組帳戶,藉以實作連結。在本文結尾,會有一份流程圖能協助您根據您的使用情境,決定哪一種對應 Active Directory 和 GCP 的方式最為適當。

本文假設您已熟悉 Active Directory。

實作連結

GCP 使用 Google 身分進行驗證及存取權管理。如要存取任何 GCP 資源,員工必須擁有 Google 身分。當所有員工都擁有 Active Directory 的帳戶時,手動維護每位員工的 Google 身分會有點麻煩。在 Active Directory 與 GCP 之間連結使用者身分後,您就可以將 Google 帳戶的維護工作自動化,並將帳戶生命週期連結至 Active Directory 的帳戶。連結能確保系統實施以下機制:

  • Active Directory 仍然是身分管理的單一可靠資料來源。
  • 對於 Active Directory 中的所有使用者帳戶或所選部分帳戶,系統會自動建立 Google 使用者帳戶。
  • 如果在 Active Directory 中停用或刪除帳戶,對應的 Google 帳戶也會遭到停權或刪除。相較之下,將 Google 帳戶停權或刪除對 Active Directory 沒有影響,因為 Google 帳戶將於下次同步處理期間自動重新建立。
  • Active Directory 會處理使用者驗證,因此您不必將密碼同步至 GCP。

在 Google 這一端,您可以使用 Cloud Identity 設定私人使用者帳戶目錄,並在該目錄中建立及管理 Google 帳戶。連結 Active Directory 與 Cloud Identity 包含兩個部分:

連結 Active Directory 與 Cloud Identity

  • 同步處理帳戶:相關使用者帳戶與群組會定期從 Active Directory 同步至 Cloud Identity。此程序可確保當您在 Active Directory 中建立新帳戶時,也可以在 GCP 中參照該帳戶,甚至是在關聯使用者尚未完成初次登入的情況下,也不會有問題。這個程序也可以確保帳戶的移除程序確實生效。

    同步處理是單向的,也就是說,Active Directory 中的變更會複製到 Cloud Identity,但相反的情況就不行。此外,同步處理並不包含密碼。在連結設定中,Active Directory 仍是管理憑證的唯一系統。

  • 單一登入:每當使用者需要在 GCP 中進行驗證時,Cloud Identity 會使用安全宣告標記語言 (SAML) 通訊協定將驗證委派到 Active Directory。此委派程序可以確保只有 Active Directory 能夠管理使用者憑證,並強制執行任何適用的政策或多重驗證 (MFA) 機制。但是,如要成功登入,必須提前同步處理各帳戶。

您可以使用下列工具來實作連結:

  • Google Cloud Directory Sync 是 Google 免費提供的工具,可實作同步處理程序。Cloud Directory Sync 會透過安全資料傳輸層 (SSL) 與 Google Identity Platform 通訊,並通常會在現有運算環境中執行。
  • Active Directory Federation Services (AD FS) 由 Microsoft 做為 Windows Server 的一部分提供。有了 AD FS,您可以使用 Active Directory 進行連結驗證。AD FS 通常會在現有運算環境中執行。

由於 Google Identity Platform 的 API 會開放給大眾使用,且 SAML 是一種開放標準,您可以使用許多工具來實作連結。本文的重點在於介紹如何使用 Cloud Directory Sync 與 AD FS。

Active Directory 的邏輯結構

在 Active Directory 基礎架構中,頂層元件是「樹系」。樹系可做為一或多個網域的容器使用,並從樹系根網域衍生其名稱。 Active Directory 樹系中的網域會彼此信任,讓在一個網域中驗證的使用者能夠存取其他網域中的資源。除非使用跨樹系信任連接樹系,個別的樹系預設不會彼此信任,在一個樹系中驗證的使用者將無法存取其他樹系中的資源。

Active Directory 基礎架構

Active Directory 網域是管理資源的容器,並且會被視為管理邊界。將多個網域納入一個樹系之中,是簡化管理或強制執行其他結構的一種方法,但樹系中的網域並不代表安全性邊界。

GCP 的邏輯結構

您可在 GCP 中管理機構中的資源,並且可以使用資料夾與專案進一步區隔這些資源,因此機構、資料夾與專案的目的與 Active Directory 網域類似。

Active Directory 會將使用者帳戶當成資源處理,因此使用者帳戶管理與驗證會與網域關聯。相較之下,除了服務帳戶以外,GCP 不會管理機構中的使用者帳戶,而是會依賴 Cloud Identity 或 G Suite 來管理使用者帳戶。

您可以使用 Cloud Identity 來為使用者帳戶與群組建立及管理私人目錄。這些目錄都受到獨立管理,因此目錄允許使用的驗證方法或強制使用的密碼政策會有所不同。Cloud Identity 中的目錄稱為「Cloud Identity 帳戶」,可由網域名稱識別。

GCP 身分識別基礎架構

樹系與樹系根網域一律同時在 Active Directory 中建立,同樣的,Cloud Identity 帳戶一律與 GCP 機構一起建立。就跟樹系根網域及樹系共用相同名稱,且無法彼此卸離一樣,Cloud Identity 帳戶與 GCP 機構會共用相同名稱並彼此連結在一起。但是,GCP 機構可以從其他 Cloud Identity 帳戶參照使用者與群組。

整合 Active Directory 與 GCP

儘管 Active Directory 與 GCP 的邏輯結構之間具有某些相似性,但無論採取哪一種方式在兩種結構間進行對應,都不可能滿足所有使用情況。整合兩個系統並對應結構的正確方法取決於多個因素:

  • 如何將網域與樹系對應至 Cloud Identity 帳戶
  • 如何對應 DNS 網域
  • 如何對應使用者帳戶
  • 如何對應群組

以下幾節會介紹以上幾個因素。

對應樹系

在較大機構中,您通常會使用多個 Active Directory 網域管理身分及跨企業存取。當您規劃連結 Active Directory 與 GCP 時,要關注的第一個因素是 Active Directory 基礎架構的拓撲。

單一樹系、單一網域

單一樹系、單一網域

當樹系只包含一個網域時,您可將整個 Active Directory 樹系對應至單一 Cloud Identity 帳戶。然後這個帳戶會提供單一 GCP 機構的基礎,讓您用來管理 GCP 資源。

在單一網域環境中,網域控制器與全域目錄伺服器都提供對於所有物件的存取權,而這些物件都在 Active Directory 中管理。在大多數情況下,您可以執行 Cloud Directory Sync 的單一執行個體,藉以將使用者帳戶與群組同步至 GCP,並維護單一 AD FS 執行個體或群體以處理單一登入。

單一樹系、多個網域

單一樹系、多個網域

當樹系中包含多個 Active Directory 網域時,您可以在一或多個網域樹狀結構中整理這些網域。在這兩種情況下,您都可以將完整樹系對應至單一 Cloud Identity 帳戶。然後這個帳戶會提供單一 GCP 機構的基礎,讓您用來管理 GCP 資源。

在多網域環境中,可從網域控制器擷取的資訊與可從全域目錄伺服器查詢的資訊會有所不同。網域控制器只會從本機網域提供資料,而全域目錄伺服器則會從樹系中的所有網域提供資訊的存取權。至關重要的一點是,全域目錄伺服器提供的資料只有部分資料,並缺少某些 LDAP 屬性。這個限制會影響您設定 Cloud Directory Sync 以同步處理群組的方式。

根據您打算對應群組的方式而定,連結多網域樹系與 GCP 會需要一或多個 Cloud Directory Sync 執行個體,但只需要單一 AD FS 執行個體或群體即可處理單一登入。

具有跨樹系信任的多個樹系

具有跨樹系信任的多個樹系

在較大機構中,很少會有多個 Active Directory 樹系的情況,這通常是併購之後的結果。您可以使用雙向的跨樹系信任來合併這些樹系,這樣使用者就能夠跨單一樹系的邊界共用及存取資源。

如果所有樹系都與其他樹系之間保有雙向信任關係,您可以將整個環境對應至單一 Cloud Identity 帳戶。這個帳戶會提供單一 GCP 機構的基礎,讓您用來管理 GCP 資源。

儘管全域目錄伺服器可從多個網域提供資料存取權,其範圍也受限於單一樹系。所以在多樹系環境中,您必須查詢多個網域控制器或全域目錄伺服器,才能取得完整的使用者帳戶清單 (僅為舉例,可能還有其他項目受限)。由於存在這樣的限制,連結多樹系環境與 GCP 會需要每個樹系至少有一個 Cloud Directory Sync 執行個體。跨樹系信任可跨樹系邊界進行使用者驗證,因此如要處理單一登入,單一 AD FS 執行個體或群體就足夠了。

如果您的環境跨越多個樹系而沒有跨樹系信任,但所有與連結 GCP 相關的 Active Directory 網域都透過外部信任連接,則也適用於相同的考量因素。

沒有跨樹系信任的多個樹系

沒有跨樹系信任的多個樹系

在此處所述的環境中,您無法跨樹系邊界驗證或存取資源,單一 AD FS 執行個體或群體也無法為所有樹系的使用者處理單一登入要求。

因此,您無法將缺少跨樹系信任的多個樹系對應至單一 Cloud Identity 帳戶,每個樹系都必須對應至單獨的 Cloud Identity 帳戶,換言之,就是必須執行至少一個 Cloud Directory Sync 執行個體與一個 AD FS 伺服器或群體。

GCP 會為每個 Cloud Identity 帳戶建立單獨的機構。在大部分情況下,您不需要維護多個單獨的機構。您可以選取一個機構,並將其關聯至其他 Cloud Identity 帳戶,有效建立與多個 Active Directory 樹系連結的機構。其他機構會保持不使用。

對應 DNS 網域

DNS 在 Active Directory 與 Cloud Identity 中都扮演重要角色。當您規劃連結 Active Directory 與 GCP 時,要關注的第二個因素是如何在 Active Directory 與 GCP 之間共用或對應 DNS 網域。

在 Active Directory 中使用 DNS 網域

在 Active Directory 樹系中,DNS 網域可在多個位置使用:

  • Active Directory DNS 網域:每個 Active Directory 網域都對應至一個 DNS 網域。這個網域可能是全域的 (例如 corp.example.com),或可能是本機網域名稱 (例如 corp.localcorp.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 網域重疊,也可能是完全不同的網域。

在 GCP 中使用 DNS 網域

GCP 用以進行驗證的 Google Identity Platform 係使用電子郵件地址來識別使用者。這樣的方式不僅可以確保全域中的電子郵件地址皆不重複,也讓  GCP 可以傳送通知訊息至這些地址。

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

在 GCP 中使用 DNS 網域

註冊 G SuiteCloud Identity 帳戶時,您等同於是在建立 Google Identity Platform 可用來進行驗證的私人目錄。您需要將 G Suite 與 Cloud Identity 帳戶關聯至自訂網域,而方法恰與在 Gmail 目錄與 gmail.com 網域間建立關聯的方式相同。可使用的網域有以下數種:

  • 主網域:這個網域會識別 Cloud Identity 目錄,同時也會做為 GCP 中的機構名稱使用。註冊 Cloud Identity 時,您需要指定這個網域名稱。
  • 次要網域:您可以將額外的次要網域與主網域一起關聯至 Cloud Identity 目錄。目錄中的每個帳戶都與主網域或其中一個次要網域相關聯。如果 example.com 是目錄的主網域,而 secondary.example.com 是次要網域,johndoe@example.comjohndoe@secondary.example.com 這兩個帳戶會被視為不同的帳戶。
  • 別名網域:別名網域是主網域的替代網域。也就是說,如果將 alias.example.com 設定為別名網域,johndoe@example.comjohndoe@alias.example.com 是指相同的帳戶。別名網域只能為主網域提供替代名稱,無法為次要網域新增別名網域。

所有網域都必須符合下列條件:

  • 網域必須是有效的全域 DNS 網域名稱。Active Directory 中經常會使用 corp.localcorp.internal 之類的本機網域名稱,但在這裡不允許使用。設定期間,您可能需要各 DNS 區域的管理存取權,才能驗證網域擁有權。
  • example.com 之類的網域只能指單一目錄,但是您可以使用不同的子網域 (例如 subdomain.example.com) 來指不同的目錄。
  • 主要與次要網域應該具有有效的 MX 記錄。如果將訊息傳送至使用這個網域名稱構成的電子郵件地址,這樣才能正確傳遞。

為了順利完成目錄之間的同步處理,Active Directory 網域與 Cloud Identity 使用的網域之間需要一些對應。是否能夠確認正確的對應,端視您如何使用 Active Directory,並且需要更深入地瞭解如何在 Active Directory 樹系中識別使用者帳戶,以及這些帳戶可以如何對應至 Cloud Identity。

對應使用者帳戶

規劃連結 Active Directory 與 GCP 時,要關注的第三個因素是如何在 Active Directory 與 Cloud Identity 之間對應使用者帳戶。

在 Active Directory 中識別使用者帳戶

Active Directory 在內部使用兩個 ID 來專門識別使用者帳戶:

  • objectGUID:這個全域不重複的 ID 會在建立使用者時產生,而且永遠不會變更。
  • objectSIDSID (或稱安全性識別碼),可用來進行所有存取權檢查作業。儘管此 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\user 的格式來合併 NetBIOS 網域名稱和使用者名稱,例如 corp\johndoe。雖然這種命名方式屬於舊有做法,但目前仍相當常見,而且這也是使用者帳戶的唯一必要 ID。

要注意的是,Active Directory 並不採用使用者電子郵件地址 (mail) 來識別使用者,因此在樹系中,這個欄位並非必填,而且可以重複。

這些 ID 全都可以隨時變更。

對應帳戶 ID

將 Active Directory 帳戶對應至 Cloud Identity 帳戶需要每個使用者帳戶的兩項資訊:

  • 您可在同步處理期間使用的穩定、不重複的 ID,用以追蹤哪一個 Active Directory 帳戶對應至哪一個 Cloud Identity 帳戶。就 AD 而言,objectGUID 非常適合這個目的。
  • 網域部分對應至 Cloud Identity 主網域、次要網域或別名網域的電子郵件地址。由於這個電子郵件地址將會在整個 GCP 中使用,因此請確保地址是正確的。從 objectGUID 衍生而出的地址不能使用,而其他自動產生的電子郵件地址也是如此。

在 Active Directory 使用者帳戶中,有兩個欄位是提供 Cloud Identity 電子郵件地址的候選項目:userPrincipalNamemail

按使用者主要名稱對應

若您使用 userPrincipalName 欄位,系統會要求要同步處理的所有帳戶符合兩個條件:

  • UPN 必須是有效的電子郵件地址。做為 UPN 後置字串網域使用的所有網域也必須是 MX 網域,而且必須設定為將傳送至使用者 UPN 的電子郵件傳遞至其電子郵件收件匣。
  • 必須完成 UPN 指派作業。要同步處理的所有使用者帳戶都必須指派 UPN。下列 PowerShell指令可以協助您尋找缺少 UPN 的帳戶:

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

如果符合這兩個條件,您可以將 UPN 安全對應至 Cloud Identity 電子郵件地址。您可以使用其中一個 UPN 後置字串網域做為 Cloud Identity 中的主網域,並將其他任何 UPN 後置字串網域新增為次要網域。

如果不符合其中一個條件,您仍可將 UPN 對應至 Cloud Identity 電子郵件地址,但請注意以下幾點:

  • 如果 UPN 不是有效的電子郵件地址,使用者可能無法收到 GCP 傳送的通知電子郵件,而導致使用者遺失重要資訊。
  • 沒有 UPN 的帳戶將會在同步處理期間遭到忽略。
  • 您可以將同步處理設定為用不同的網域替換 UPN 後置字串網域。但是,當您使用樹系中的多個 UPN 後置字串網域時,這個方法可能會建立重複項目,因為所有 UPN 後置字串網域都將由單一網域取代。對於重複項目而言,只能同步處理單一帳戶。

使用 UPN 對應使用者的一個主要優點在於,UPN 保證在樹系中是不重複的,而且會使用一組收錄的網域,這將有助於避免同步處理可能發生的問題。

按電子郵件地址對應

對於要同步處理的所有帳戶而言,使用 mail 欄位需要符合下列條件:

  • 必須完成電子郵件指派作業。要同步處理的所有使用者帳戶都必須填入 mail 欄位。下列 PowerShell 指令可以協助您尋找此欄位尚未填寫的帳戶:

    Get-ADUser -LDAPFilter "(!mail=*)"
  • 電子郵件地址必須使用一組收錄的網域,而且這些網域全都為您所有。如果您的一些帳戶使用的電子郵件地址參照了合作夥伴公司或消費者電子郵件提供者,則無法使用這些電子郵件地址。

  • 所有電子郵件地址在樹系中都不得重複。由於 Active Directory 不會強制檢查不重複性,因此您可能必須自行檢查或套用自訂政策。

如果所有相關帳戶都符合這些條件,您就能識別這些電子郵件地址使用的各個網域,並將這些網域當做 Cloud Identity 中的主要網域與次要網域。

即便帳戶不符合任一項條件,您還是可以將電子郵件地址對應至 Cloud Identity 電子郵件地址。不過,請注意以下事項:

  • 在同步處理作業期間,系統會忽略沒有電子郵件地址的帳戶,以及所含電子郵件地址使用的網域未連結至 Cloud Identity 目錄的帳戶。
  • 當兩個帳戶共用相同電子郵件地址時,只會同步處理一個帳戶。
  • 您可以設定讓同步處理作業將電子郵件地址的網域替換為不同的網域。這個程序可能會建立重複項目,在這種情況下,只會同步處理一個帳戶。

對應群組

當您規劃連結 Active Directory 與 GCP 時,要關注的第四個因素是是否在 Active Directory 與 GCP 之間同步處理群組以及對應群組的方式。

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

Active Directory 會區分兩種群組:通訊群組與安全性群組。通訊群組可用來管理電子郵件清單。當您要從 Microsoft Exchange 遷移至 G Suite 時,就會需要同步處理通訊群組,這樣 Cloud Directory Sync 就可以同時處理一般與動態通訊群組。但是,在 GCP 的身分與存取權管理中,通訊群組並不是問題,所以本討論會專注於安全性群組。

您可以自行選擇是否要在 Active Directory 與 GCP 之間對應安全性群組。連結使用者帳戶後,您可以直接在 Cloud Identity 中建立及管理群組,這表示 Active Directory 會保持為身分管理的中央系統,而非存取權管理的中央系統。如要將 Active Directory 同時保持為身分管理及存取權管理的中央系統,建議您從 Active Directory 同步處理安全性群組,而非在 Cloud Identity 中管理安全性群組。透過這種方式,您可以設定 Cloud IAM,讓您能夠在 Active Directory 中使用群組成員資格控管誰在 GCP 中具有特定資源的存取權。

Active Directory 中的安全性群組

安全性群組在 Windows 安全性與 Active Directory 存取權管理中扮演了重要的角色。這個角色可以透過三種不同類型的 Active Directory 群組實現:「網域本機群組」、「全域群組」與「通用群組」

AD 中的安全性群組

網域本機群組
這些群組只在單一網域的範圍內具有相關性,無法在其他網域中參照。由於群組的成員清單不需要跨樹系複製,因此對於群組可以包含的成員類型而言,網域本機群組最具有彈性。
全域群組
這些群組會出現在其他網域中,並可在其他網域中參照,但不會複製群組的成員清單,這樣會限制這些群組可以包含的成員類型。這些群組只能包含相同網域中的使用者帳戶及其他全域群組。
通用群組
這些群組與其成員清單可跨樹系複製,因此可在其他網域中參照,除了使用者帳戶與其他通用群組外,也可包含所有網域中的全域群組。

如果您的 Active Directory 樹系只包含單一網域,您可以使用 Cloud Directory Sync 同步處理全部三種類型的安全性群組。如果您的 Active Directory 樹系使用多個網域,群組類型可決定其是否可同步至 Cloud Identity 及同步處理的方式。

由於網域本機與全域群組不會在整個樹系中完全複製,因此全域目錄伺服器會包含群組的不完整資訊。儘管此限制比較謹慎,而且可以協助加快目錄複製,但當您要將此類群組同步至 Cloud Identity 時,還是會造成障礙。具體而言,如果您設定讓 Cloud Directory Sync 使用全域目錄伺服器做為來源,則此工具將能夠從整個樹系的所有網域群找群組,但是只有在與全域目錄伺服器相同網域中的群組才會包含成員資格清單並適合複製。如要同步處理多網域樹系中的網域本機或全域群組,您必須為每個網域執行個別的 Cloud Directory Sync 執行個體。

由於通用群組會在整個樹系中完全複製,因此不受此限制。單一 Cloud Directory Sync 執行個體可從多個網域同步處理通用群組。

在推斷您需要多個 Cloud Directory Sync 執行個體來將多個 Active Directory 網域同步至 Cloud Identity 之前,請記住並非所有群組都需要同步處理。因此,若能瞭解不同類型的安全性群組在整體 Active Directory 樹系中通常是如何使用,會非常值得。

在 Active Directory 中使用安全性群組

資源群組

Windows 根據存取控制清單 (ACL) 使用存取模型。每種資源 (例如檔案或 LDAP 物件) 都有關聯的 ACL 可以控管哪些使用者能夠存取資源。資源與 ACL 受到非常完善的細部控制,因此會有許多資源與 ACL。為了簡化 ACL 的維護,建立「資源群組」來納入經常一起使用及存取的資源是一種很常見的做法。 您可以將資源群組一次新增到所有受影響的 ACL,並透過更改資源群組的成員資格來進一步管理存取權,而不用更改 ACL。

以這種方式納入的資源通常都存在於單一網域。因此,資源群組一般也只會在單一網域中參照,可能是 ACL,或者由其他資源群組參照。由於大多數資源群組都在本機,因此通常會使用 Active Directory 中的網域本機群組實作。

角色與機構群組

資源群組有助於簡化存取權管理,但是在大型環境中,您可能需要將新使用者新增至大量資源群組。因此,資源群組通常會透過「角色群組」或「機構群組」補充。

角色群組會匯總特定角色在機構中需要的權限。 舉例來說,名為「工程說明文件檢視者」的角色群組可能會為成員提供所有工程說明文件的唯讀存取權。事實上,如要達成此目的,您可以建立角色群組,並使該群組成為控制各種說明文件存取權的所有資源群組成員。

機構群組也可以透過類似方式匯總機構部門需要的權限。例如,名為「工程」的機構群組可以授予存取權給工程部門成員通常需要的所有資源。

就技術層面而言,角色群組與資源群組之間並無差異,這兩者通常會一起使用。但是,角色和機構群組可在網域邊界外具有關聯性,這點與資源群組不同。如要允許其他網域中的資源群組參照此類群組,角色與機構群組通常可以使用全域群組實作,這將僅限於單一網域的成員,有時候可透過通用群組來補充,進而允許來自其他網域的成員。

下圖顯示在多網域 Active Directory 環境中常用的巢狀模式。

在多網域 AD 環境中使用的巢狀模式

Cloud Identity 中的群組

在 Cloud Identity 中只有單一類型的群組,其行為模式與 Active Directory 中的通用群組類似。也就是說,群組不會因為已定義於 Cloud Identity 帳戶之中,就受限於該帳戶的範圍內,而是能夠包含其他 Cloud Identity 帳戶中的使用者帳戶。這些群組支援在其他 Cloud Identity 帳戶中參照及處於其巢狀結構中,並且可以跨任何 GCP 機構使用。

與 Active Directory 群組不同的是,Cloud Identity 群組的成員無法間接取得列出同一群組其他成員清單的權限。相反地,若要查詢群組成員,一般都需要明確的授權

在 GCP 中使用群組

GCP 使用依角色提供的存取模型,而非依 ACL 提供的存取模型。角色適用於特定範圍內特定類型的所有資源。例如,「Kubernetes Engine 開發人員」角色能夠完全存取特定專案所有叢集中的 Kubernetes API 物件。有鑑於角色的特性,並不太需要在 GCP 上維護資源群組,更不太需要將資源群組同步至 GCP。

角色群組與機構群組可以讓您輕鬆管理大量使用者的存取權,因此在 GCP 和 Active Directory 中一樣重要。同步處理角色與機構群組有助於將 Active Directory 保持為管理存取權的主要位置。

同步處理角色與機構群組

如果您持續將資源群組實作為網域本機群組,並將角色與機構群組實作為通用群組,便可使用群組類型來確認只會同步處理角色與機構群組。

如果您本來懷疑為每個多網域樹系執行單一 Cloud Directory Sync 執行個體是否足夠,或者是否需要多個 Cloud Directory Sync 執行個體,那麼現在的問題會變成是否要使用全域群組。如果您使用通用群組來實作所有角色與機構群組,那麼單一 Cloud Directory Sync 執行個體就夠了;否則,您的每個網域將需要一個 Cloud Directory Sync 執行個體。

對應群組 ID

將 Active Directory 安全性群組對應至 Cloud Identity 群組需要有通用 ID。在 Cloud Identity 中,這個 ID 必須是網域部分對應至 Cloud Identity 主網域、次要網域或別名網域的電子郵件地址。由於這個電子郵件地址將在整個 GCP 中使用,因此這個地址必須是使用者可以理解的地址。電子郵件地址不需要對應至信箱。

在 Active Directory 中,群組會依其慣用名稱 (cn) 或 Windows 2000 之前的登入名稱 (sAMAccountName) 識別。群組與使用者帳戶類似,也可以擁有電子郵件地址 (mail),但電子郵件地址是群組的選用屬性,Active Directory 不會驗證不重複性。

您有兩個選項可以在 Active Directory 與 Cloud Identity 之間對應群組 ID。

按慣用名稱對應

使用慣用名稱 (cn) 的優點是可以保證名稱一定可用,而且至少在機構單位之內不會重複。但是,慣用名稱並非電子郵件地址,因此需要加上後置字串 @[DOMAIN] 才能轉換成電子郵件地址。

您可以設定 Cloud Directory Sync,使其自動為群組名稱加上後置字串。由於 Active Directory 會確認群組名稱與使用者帳戶名稱不衝突,因此以這種方式衍生的電子郵件地址也不太可能會產生任何衝突。

如果您的 Active Directory 樹系中包含單一網域,請注意以下幾點:

  • 如果不同網域中的兩個群組共用一個慣用名稱,衍生的電子郵件地址將會產生衝突,導致在同步處理期間忽略一個群組。
  • 您只能從單一樹系的網域中同步處理群組。如果使用單獨的 Cloud Directory Sync 執行個體同步處理多個樹系的群組,從慣用名稱衍生的電子郵件地址就不會反映出對應的樹系。這種模稜兩可的情形將會導致 Cloud Directory Sync 執行個體刪除之前由其他 Cloud Directory Sync 執行個體從不同樹系中建立的任何群組。
  • 如果您使用網域替代來對應使用者帳戶,就無法按慣用名稱對應群組。

按電子郵件地址對應

使用電子郵件地址 (mail) 對應群組 ID 表示您必須符合與使用電子郵件對應帳戶 ID 時相同的條件:

  • 必須完成電子郵件指派作業。儘管通訊群組擁有電子郵件地址是一件很平常的事,但安全性群組經常會缺少這個屬性。如要使用電子郵件地址對應 ID,要進行同步處理的安全性群組必須填入 mail 欄位。下列 PowerShell 指令可以協助您找到未填入此欄位的帳戶:

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • 電子郵件地址必須使用一組收錄的網域,而且這些網域全都為您所有。如果您的一些帳戶使用的電子郵件地址參照了合作夥伴公司或消費者電子郵件提供者,則無法使用這些地址。

  • 所有電子郵件地址在樹系中都不得重複。由於 Active Directory 不會強制檢查不重複性,因此您可能必須自行檢查或套用自訂政策。

如果所有相關群組都符合這些條件,您可以識別這些電子郵件地址使用的所有網域,確認在 Cloud Identity 中註冊的 DNS 網域清單包含這些網域。

如果不符合其中一個條件,您仍可將 UPN 對應至 Cloud Identity 電子郵件地址,但請注意以下幾點:

  • 在同步處理期間,沒有電子郵件地址的群組將會遭到忽略,有網域但使用的網域與 Cloud Identity 目錄無關聯的電子郵件地址也會遭到忽略。
  • 當兩個群組共用相同電子郵件地址時,只會同步處理一個群組。

如果您的 Active Directory 樹系中包含多個網域,而且您使用網域替代來對應使用者帳戶,就不支援按電子郵件地址對應群組。

對應機構單位

大多數 Active Directory 網域都大量使用機構單位來按階層分群及整理資源、控管存取權,以及強制執行政策。

在 GCP 中,資料夾與專案的目的相似,但在 GCP 機構中管理的資源種類與在 Active Directory 中管理的資源非常不同。因此,企業的適當 GCP 資料夾階層很可能與 Active Directory 中的機構單位結構明顯不同。因此,將機構單位自動對應至資料夾與專案很難符合實際需求,Cloud Directory Sync 也不支援這種做法。

Cloud Identity 與資料夾無關,而且支援機構單位的概念。機構單位會建立來分群及整理使用者帳戶,這與 Active Directory 類似。但是與 Active Directory 不同的是,機構單位僅適用於使用者帳戶,而不適用於群組。

Cloud Directory Sync 提供將 Active Directory 機構單位同步至 Cloud Identity 機構單位的選項。在 Cloud Identity 僅用來將 Active Directory 身分管理延伸到 GCP 的設定中,通常不需要對應機構單位。

選擇正確的對應

如本文開頭所述,對應 Active Directory 與 GCP 的結構並沒有什麼絕對的最佳做法。為了協助您選擇符合情境的正確對應方法,以下決策圖匯總了在前文中討論的條件。

首先,請參閱下圖來瞭解您將需要多少 Cloud Identity 帳戶、Cloud Directory Sync 執行個體與 AD FS 執行個體或群體。

確認所需群體或執行個體數的決策圖

然後請參閱第二個圖表來識別要在 Cloud Identity 帳戶中設定的網域。

識別要在 Cloud Identity 中設定之網域的決策圖

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁