Cloud SQL 中的代管 Microsoft AD 總覽

您可以將 SQL Server 適用的 Cloud SQL 與 Managed Service for Microsoft Active Directory (也稱為 Managed Microsoft AD) 整合。

本頁面包含開始整合前應先瞭解的資訊。請先詳閱下列資訊，包括限制，然後參閱「搭配使用 Cloud SQL 與 Managed Microsoft AD」。

整合代管的 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.iam.gserviceaccount.com

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

    service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

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

如要授予整合所需的權限，請執行下列指令。如果 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.iam.gserviceaccount.com \
--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 代理程式固定資料庫角色：SQLAgentUserRole。不過，透過 SQL Server 直接建立的使用者 (例如 Managed Microsoft AD 使用者) 無法獲得這個角色，也無法使用 SQL Server 代理程式，因為必須授予這個角色的 MSDB 資料庫受到保護。
  • 部分受限作業可能會導致下列錯誤：「無法取得 Windows NT 群組/使用者資訊」。舉例來說，如果網域透過信任關係連線，使用者就無法從這些網域建立登入資訊。另一個例子是授予透過信任關係連線的網域使用者權限。在這種情況下，通常重試作業就能成功。如果重試失敗，請關閉連線並開啟新連線。
  • Windows 上的 SQL Server 不支援完整網域名稱 (FQDN)。因此，建立 SQL Server 登入時，請使用網域名稱 (簡短名稱)，而非完整網域名稱。舉例來說，如果網域名稱是 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 個字元) 的執行個體。

後續步驟