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

MySQL   |  PostgreSQL   |  SQL Server

本頁面包含開始整合前應先瞭解的資訊。請先詳閱下列資訊 (包括限制)，然後參閱「使用客戶管理的 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)， 才能儲存所有相關的整合物件。
  • 在這個機構單位中，您還需要具備下列權限的管理員帳戶：
    • 建立電腦物件
    • 刪除電腦物件
    • 建立 User 物件
    • 刪除使用者物件
    • 寫入所有屬性
    • 重設密碼
    • 讀取鎖定時間、寫入鎖定時間
  • 此外，我們也建議授予這個管理員帳戶管理 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。請勿在值中加入網域名稱。系統不支援類似 [e-mail] 的項目。
  • ADMINISTRATOR_PASSWORD_VALUE_1：管理員密碼。
  • VALID_AFTER_UTC_VALUE_2：您要使用的第二個世界標準時間值，格式為 YYYY-MM-DDThh:mm:ssZ。例如 2099-07-01T10:30:00Z。
  • ADMINISTRATOR_LOGIN_VALUE_2：要使用的第二位管理員登入資訊，例如 myadmin2。同樣地，請勿在值中加入網域名稱。系統不支援類似 [e-mail] 的項目。
  • ADMINISTRATOR_PASSWORD_VALUE_2：第二位管理員的密碼。

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

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

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

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

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

建立及設定服務帳戶

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

• 您必須啟用 Cloud SQL Admin API。
• 你必須具備下列權限：
  • resourcemanager.projects.setIamPolicy
  • secretmanager.secrets.getIamPolicy
  • secretmanager.secrets.setIamPolicy

  如要與 CMAD 整合，您需要為每個專案建立「每個產品、每個專案」的服務帳戶。使用 gcloud CLI 在專案層級建立帳戶。應將 secretmanager.secrets.getIamPolicy 和 secretmanager.secrets.setIamPolicy 權限授予每個產品和專案的服務帳戶，以存取上一個步驟中建立的密鑰。詳情請參閱「Secret Manager 權限」。

  建議您建立具備所需權限的自訂角色。

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

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

      --project=PROJECT_ID
  

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

  [e-mail]
  

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

  [e-mail]
  

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

  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:[e-mail]" 

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

詳情請參閱 gcloud beta services identity create。

整合 CMAD 的最佳做法

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

整合的先決條件

使用 Active Directory 診斷工具，排解內部部署網域和 Google Cloud 控制台中的 SQL Server 適用的 Cloud SQL 執行個體，在設定 AD 時發生的問題。略過與 Managed Service for Microsoft Active Directory 相關的步驟。

與 CMAD 整合的拓撲

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

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

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

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

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

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

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

限制和替代方案

注意： 如需本節相關資訊，請參閱「不支援整合」。

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

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

注意： 不支援少於八個字元的客戶管理網域 (例如 xyz.com 的七個字元網域)。如要解決這個問題，請建立名稱較長的客戶管理網域。

Active Directory 端點和 TLS 連線

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

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

不支援整合

注意： 如要瞭解部分不支援作業的替代方法，請參閱「限制和替代方法」。

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

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

監控

注意： 下列指標同時支援 Managed Service for Microsoft Active Directory 和 CMAD。

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

cloudsql.googleapis.com/database/active_directory/domain_reachable

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

cloudsql.googleapis.com/database/active_directory/instance_available

後續步驟

• 使用客戶自行管理的 Active Directory (CMAD)
• 使用 Active Directory 診斷工具