Cloud SQL 中的代管 Microsoft AD 總覽

Managed Service for Microsoft Active Directory (Managed Microsoft AD) 可讓您使用 Active Directory 身分，管理 SQL Server 適用的 Cloud SQL 執行個體的驗證和授權。將執行個體加入 Managed Microsoft AD 網域後，您就能使用 Windows 驗證登入，並將雲端資料庫與地端部署 Active Directory 網域連結。

開始整合前，請先詳閱本文件中的必要條件、拓撲和限制。查看這項資訊後，請參閱「搭配使用 Cloud SQL 與 Managed Microsoft AD」。

與 Managed Microsoft AD 整合的優點

Managed Microsoft AD 提供驗證、授權等功能。舉例來說，將執行個體加入 Managed Microsoft AD 網域後，您就能使用 Windows 驗證機制，以 AD 身分登入。

將 SQL Server 適用的 Cloud SQL 與 AD 網域整合，還能享有雲端與地端部署 AD 網域整合的優勢。

整合必要條件

您可以與 Managed Microsoft AD 整合，為執行個體新增 Windows 驗證支援。不過，在整合之前，Google Cloud 專案必須符合下列條件：

建立及設定服務帳戶

您必須為每個要與 Managed Microsoft AD 整合的專案，建立每項產品和專案的服務帳戶。請使用 gcloud 或控制台，在專案層級建立帳戶。應將專案的 managedidentities.sqlintegrator 角色授予各產品、各專案服務帳戶。詳情請參閱「gcloud projects set-iam-policy」。

如果您使用 Google Cloud 控制台，Cloud SQL 會自動為您建立服務帳戶，並提示您授予managedidentities.sqlintegrator角色。

如要使用 gcloud 建立服務帳戶，請執行下列指令：

gcloud beta services identity create --service=sqladmin.googleapis.com \
    --project=PROJECT_NUMBER

該指令會傳回服務帳戶名稱，格式如下：

    service-PROJECT_NUMBER@gcp-sa-cloud-sql.

以下是服務帳戶名稱範例：

    service-333445@gcp-sa-cloud-sql.

您必須具備現有權限，才能授予整合所需的權限。如要瞭解必要權限，請參閱「必要權限」。

執行下列指令，授予整合所需的權限。如果 Managed Microsoft AD 位於其他專案，AD_PROJECT_ID 應為包含 Managed Service for Microsoft Active Directory 執行個體的專案，而服務帳戶的 SQL_PROJECT_NUMBER 應為包含 SQL Server 執行個體的專案：

gcloud projects add-iam-policy-binding AD_PROJECT_ID \
--member=serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql. \
--role=roles/managedidentities.sqlintegrator

另請參閱 gcloud beta services identity create。

與 Managed Microsoft AD 整合的最佳做法

規劃整合時，請查看下列事項：

在相同區域中建立 SQL Server 執行個體和代管 AD 執行個體，可提供最低的網路延遲和最佳效能。因此，請盡可能在同一個區域中設定 SQL Server 執行個體和 AD 執行個體。此外，無論是否在同一區域設定，都請設定主要和備用區域，以提高可用性。

與 Managed Microsoft AD 整合的拓撲

SQL Server 適用的 Cloud SQL 不支援網域本機群組。不過，您可以：

  • 直接在 SQL Server 中新增全域群組或個別使用者登入資訊
  • 如果所有群組和使用者都屬於同一個樹系，請使用通用群組

如果支援網域本機群組，則可將個別使用者帳戶、全域和通用群組新增為網域本機群組 (保護 SQL Server 的存取權) 的子項。這樣一來，您就能將網域本機群組新增為 SQL Server 登入。在 SQL Server 適用的 Cloud SQL 中，您可以啟用類似功能，詳情請參閱本節。

選項 1：將使用者帳戶和群組新增為 SQL Server 登入

如果您有多個網域、多個樹系和多個全域群組，可以直接將所有個別使用者帳戶、全域和通用群組新增為 SQL Server 的登入帳戶。如需選項 1 的範例，請參閱下圖：

AD 拓撲，選項 1。

方法 2：在其中一個網域中定義通用群組

如果網域位於同一個樹系中，您可以在其中一個網域定義通用群組。接著，您可以將所有個別使用者帳戶、全域和通用群組新增為該定義通用群組的子項，並將定義的通用群組新增為 SQL Server 登入。如需選項 2 的範例，請參閱下圖：

AD 拓撲，選項 2。

限制和替代方案

與 Managed Microsoft AD 整合時，須遵守下列限制：

  • 不支援網域本機群組，但您可以直接在 SQL Server 中新增全域群組或個別使用者登入資訊。或者，如果所有群組和使用者都屬於同一個樹系，您可以使用通用群組。
  • 一般來說，透過 Google Cloud 控制台建立的新使用者會獲派CustomerDbRootRole角色，該角色具有下列 SQL Server Agent 固定資料庫角色：SQLAgentUserRole。不過，直接透過 SQL Server 建立的使用者 (例如 Managed Microsoft AD 使用者) 無法取得這個角色，也無法使用 SQL Server Agent，因為必須授予這個角色的 MSDB 資料庫受到保護。
  • 部分受限作業可能會導致下列錯誤：「Could not obtain information about Windows NT group/user」(無法取得 Windows NT 群組/使用者的相關資訊)。這類受限作業的其中一個例子，是使用者透過信任關係連結的網域建立登入資訊。另一個例子是，將權限授予透過信任關係連結的網域使用者。在這種情況下，重試作業通常會成功。如果重試失敗，請關閉連線並開啟新連線。
  • Windows 上的 SQL Server 不支援完整網域名稱 (FQDN)。因此，建立 SQL Server 登入時，請使用網域名稱 (簡稱)，而非 FQDN。舉例來說，如果您的網域名稱是 ad.mydomain.com，請為 ad\user 建立 SQL Server 登入資訊，而非 ad.mydomain.com\user。
  • 如要存取 SQL Server 執行個體，請一律使用 FQDN。例如，您可以使用類似 private.myinstance.us-central1.myproject.cloudsql.mydomain.com 的 FQDN。系統不支援 NetBIOS 名稱，也不支援省略 DNS 尾碼的任何簡稱。
  • 無法透過 Google Cloud 控制台管理以 Active Directory 使用者和群組為基礎的 SQL Server 登入。
  • 在 Cloud SQL 中，如果 SQL Server 執行個體是在 2021 年 3 月 12 日當天或之前建立，則無法與 Managed Microsoft AD 整合。
  • Windows 驗證不適用於外部信任。錯誤訊息可能如下：「目標主體名稱不正確。Cannot generate SSPI context." 此外，根據 Microsoft 的建議，請使用樹系信任，而非外部信任，進行 Kerberos 驗證。

Active Directory 端點和 TLS 連線

如果您使用 Windows 驗證，且想在不信任伺服器憑證的情況下建立 TLS 連線，則必須在執行個體啟用 Windows 驗證後輪替憑證。

如果連線失敗，且其中一個憑證是在 2025 年 3 月 15 日前建立，請再次輪替伺服器憑證，然後重新連線。

不支援整合

與 Managed Microsoft AD 整合時，不支援下列功能：

  • 網域本機群組。
  • 使用者從透過信任關係連結的網域，捨棄 SQL Server 登入。您可以使用受管理網域中的使用者，或透過 sqlserver 登入執行這項操作。
  • NTLM 驗證。
  • 使用透過信任關係連結的網域 IP 位址登入。
  • 名稱過長 (超過 63 個字元) 的執行個體。

後續步驟