客戶管理的 Active Directory (CMAD) 總覽

本頁面包含開始整合前應先瞭解的資訊。請先詳閱下列資訊 (包括限制)，再參閱「使用客戶自行管理的 Active Directory」。

您可以將 SQL Server 適用的 Cloud SQL 與客戶自行管理的 Microsoft Active Directory (也稱為客戶自行管理的 AD (CMAD)) 整合。

您可以使用 CMAD 進行驗證、授權等操作。舉例來說，將執行個體加入 CMAD 網域後，您就能使用 Windows 驗證，透過 AD 型身分登入。將 SQL Server 適用的 Cloud SQL 與 AD 網域整合，還有一項額外優點： Google Cloud 與地端部署 AD 網域整合。

事前準備

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

  • 如要進行驗證，Cloud SQL 執行個體必須與所有相關的 Active Directory 網域建立網路連線。包括執行個體加入的主要網域，以及包含需要存取 SQL Server 適用的 Cloud SQL 使用者的任何信任或子網域。如要啟用這項功能，請確保 Cloud SQL 執行個體與所有網域控制站之間已開啟下列連接埠 (TCP 和 UDP)：53、88、135、389、445、464、3268、3269，以及 49152 至 65535。
  • 您必須建立機構單位 (OU)，才能儲存所有相關的整合物件。
    • 您也必須在這個機構單位中，將下列權限委派給管理員帳戶。在 Active Directory Delegation of Control Wizard 中，選取下列項目：
      • 建立電腦物件
      • 刪除電腦物件
      • 建立 User 物件
      • 刪除使用者物件
      • 寫入所有屬性
      • 讀取及寫入網域密碼和鎖定政策 (包括「重設密碼」和「讀取鎖定時間、寫入鎖定時間」)

      下圖是 Active Directory 委派控制精靈中的權限摘要範例 (顯示於 Windows Server 2025)：

      Active Directory 委派控制精靈權限摘要

    • 此外，我們也建議授予這個管理員帳戶管理 DNS 記錄的權限，例如將其新增至 DnsAdmins 群組。

      即使未授予這些權限，整合作業仍會成功。 不過，如要連線至執行個體，您必須手動建立必要的 DNS 記錄，詳情請參閱「使用使用者連線至執行個體」。

      另一種做法是使用執行個體的 IP 位址連線，但這種做法有其限制，且無法用於來自信任網域的連線。

  • 您必須使用下列 JSON 格式，將管理員憑證儲存在 Secret Manager 密鑰中： 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    更改下列內容：

    • VALID_AFTER_UTC_VALUE_1：要使用的第一個世界標準時間值，格式為 YYYY-MM-DDThh:mm:ssZ。例如 2099-07-01T10:30:00Z。
    • ADMINISTRATOR_LOGIN_VALUE_1：您要使用的第一個管理員登入名稱，例如 myadmin。值中不得包含網域名稱。系統不支援類似 myadmin@my-domain-name.com 的項目。
    • ADMINISTRATOR_PASSWORD_VALUE_1：管理員密碼。
    • VALID_AFTER_UTC_VALUE_2：您要使用的第二個世界標準時間值，格式為 YYYY-MM-DDThh:mm:ssZ。例如 2099-07-01T10:30:00Z。
    • ADMINISTRATOR_LOGIN_VALUE_2：要使用的第二位管理員登入資訊，例如 myadmin2。同樣地，請勿在值中加入網域名稱。系統不支援類似 myadmin2@my-domain-name.com 的項目。
    • ADMINISTRATOR_PASSWORD_VALUE_2：第二位管理員的密碼。

    這個檔案可以包含多個憑證項目，以減輕傳播緩慢的問題，或配合預先規劃的輪替作業。

    validAfterUTC 欄位為選填，如未指定，系統會假設憑證一律有效。建議您在 Secret Manager 中永久保留這些憑證，並在輪替憑證時使用自動化功能更新密碼。

    您可以在建立執行個體後刪除密鑰，但請注意，日後執行複製或新增唯讀副本等作業時，新執行個體將無法加入網域。

    此外，刪除原始執行個體後，CMAD 中會留下孤立物件，例如電腦帳戶。

  • 取得客戶自行管理的 Active Directory 的 DNS 伺服器 IP 位址清單，通常是網域控制器。建議為這些伺服器使用靜態 IP 位址。
  • 指派每項產品和專案的服務帳戶。

建立及設定服務帳戶

如要建立具備必要權限的服務帳戶，請確認下列事項：

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

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

      --project=PROJECT_ID

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

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

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

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

如要授予整合所需的權限，請執行下列指令：

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

然後執行下列指令：

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

詳情請參閱 gcloud beta services identity create。

整合 CMAD 的最佳做法

整合 CMAD 時，建議完成下列步驟。

整合的必要條件

使用客戶管理的 Active Directory 診斷工具 排解網域的 Active Directory 設定問題，再與 Cloud SQL 整合。

與 CMAD 整合的拓撲

SQL Server 適用的 Cloud SQL 不支援網域本機群組。不過，您可以使用下列替代方案：

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

SQL Server 適用的 Cloud SQL 不支援將網域本機群組做為登入項目。如要將權限授予網域使用者，請改用全域或通用群組，詳情請參閱本節說明。

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

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

CMAD 拓撲 (選項 1)。

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

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

CMAD 拓撲 (選項 2)。

限制和替代方案

與 CMAD 整合時，須遵守下列限制：

  • 系統不支援使用 Private Service Connect (PSC) 進行私人連線的 SQL Server 適用的 Cloud SQL 執行個體。請改用私人服務連線 (PSA)。
  • 系統不支援網域本機群組，但您可以直接在 SQL Server 中新增全域群組或個別使用者登入資訊。或者，如果所有群組和使用者都屬於同一個樹系，您可以使用通用群組。
  • 如有其他受信任網域，且您打算使用這些網域的使用者名稱存取 SQL Server 執行個體，則必須透過雙向信任連線。不支援單向和外部信任關係。
  • 一般來說，透過 Google Cloud 控制台建立的新使用者會獲派 CustomerDbRootRole 角色，該角色具有以下 SQL Server Agent 固定資料庫角色：SQLAgentUserRole。不過，透過 SQL Server 直接建立的使用者 (例如 CMAD 使用者) 無法獲得這個角色，也無法使用 SQL Server Agent，因為必須授予這個角色的 MSDB 資料庫受到保護。
  • 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 登入。
  • Windows 驗證不適用於外部信任。傳回的錯誤可能如下：
      "The target principal name is incorrect. Cannot generate SSPI context."
    此外，根據Microsoft 的建議，請使用樹系信任關係，而非外部信任關係進行 Kerberos 驗證。
  • 系統一律會使用最新版的密鑰。密鑰必須處於啟用狀態，且無法銷毀。

Active Directory 端點和 TLS 連線

如果您使用 Windows 驗證，並想建立傳輸層安全標準 (TLS) 連線，但不想信任伺服器憑證，則必須在執行個體上啟用 Windows 驗證後，輪替憑證。

如果連線失敗，且您的憑證是在 2025 年 3 月 15 日前建立，請再次輪替伺服器憑證，然後再次嘗試連線。

不支援整合

與 CMAD 整合時，系統不支援下列功能：

  • 網域本機群組。
  • NTLM 驗證。
  • 使用透過信任關係連線的網域 IP 位址登入。
  • 名稱過長 (超過 63 個字元) 的執行個體。

監控

您可以使用下列指標監控 CMAD 狀態和健康度：

cloudsql.googleapis.com/database/active_directory/domain_reachable

這項指標會回報 CMAD 是否可從 Cloud SQL 執行個體存取。這項工具可協助排解網路問題：

cloudsql.googleapis.com/database/active_directory/instance_available

後續步驟