您可以將 SQL Server 適用的 Cloud SQL 與 Managed Service for Microsoft Active Directory (也稱為代管的 Microsoft AD) 整合。
本頁面包含開始整合前應先瞭解的資訊。請先詳閱下列資訊，包括限制，然後參閱「透過代管的 Microsoft AD 使用 Cloud SQL」。
整合代管 Microsoft AD 的優點
透過 Managed Microsoft AD，您可以進行驗證、授權等操作。舉例來說，將執行個體加入代管的 Microsoft AD 網域後，您就能使用 Windows 驗證和 AD 型身分登入。
將 SQL Server 適用的 Cloud SQL 與 AD 網域整合，還能享有額外優勢，也就是將雲端與地端 AD 網域整合。
整合的先決條件
您可以與 Managed Microsoft AD 整合，為執行個體新增 Windows 驗證支援。不過，整合前，您的Google Cloud 專案必須符合下列條件：
- 代管的 Microsoft AD 網域。如要瞭解如何設定網域，請參閱「建立網域」。
- 內部部署 AD 網域需要受管理 AD 信任。請參閱「建立單向信任關係」和「使用內部部署 AD 使用者建立 Windows 登入 Cloud SQL 的帳戶」。
- 如以下各節所述，每個產品和專案都有專屬的服務帳戶；請參閱「建立服務帳戶」。
建立及設定服務帳戶
您需要為每個要與受管理 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如要授予整合所需的權限，您必須具備現有權限。 如要瞭解必要權限，請參閱「必要權限」。
如要授予整合所需的權限，請執行下列指令。如果受管理 Microsoft AD 位於不同專案中，AD_PROJECT_ID 應包含 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 整合的最佳做法
規劃整合時，請查看下列事項：
- 整合的先決條件
- 與其他專案中的代管 AD 網域整合
- Managed Microsoft AD 說明文件
- 在其他區域部署網域控制站
- 使用 AD 診斷工具，排解 Google Cloud 控制台中內部部署網域和 Cloud SQL for SQL Server 執行個體的 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 的範例，請參閱下圖：
方法 2：在其中一個網域中定義通用群組
如果網域位於同一樹系，您可以在其中一個網域中定義通用群組。然後將所有個別使用者帳戶，以及全域和通用群組，新增為所定義通用群組的子項，並將定義的通用群組新增為 SQL Server 登入。如要瞭解選項 2 的範例，請參閱下圖：
限制和替代方案
整合 Managed Microsoft AD 時，請注意下列限制：
- 系統不支援網域本機群組，但您可以在 SQL Server 中直接新增全域群組或個別使用者登入資訊。或者，如果所有群組和使用者都屬於同一個樹系，您可以使用通用群組。
- 一般來說，透過 Google Cloud 控制台建立的新使用者會獲派
CustomerDbRootRole角色，該角色具有以下 SQL Server Agent 固定資料庫角色：SQLAgentUserRole。不過，透過 SQL Server 直接建立的使用者 (例如受管理 Microsoft AD 使用者) 無法獲得這個角色，也無法使用 SQL Server 代理程式，因為必須授予這個角色的 MSDB 資料庫受到保護。 - 部分受限制的作業可能會導致下列錯誤：「無法取得 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 驗證功能無法搭配外部信任使用。錯誤可能如下：「目標主體名稱不正確。 無法產生 SSPI 環境。此外，根據Microsoft 的建議，請使用樹系信任關係，而非外部信任關係，進行 Kerberos 驗證。
Active Directory 端點和 TLS 連線
如果您使用 Windows 驗證，並想建立 TLS 連線，但不想信任伺服器憑證，則必須在執行個體上啟用 Windows 驗證後，輪替憑證。
如果連線失敗，且您的憑證是在 2025 年 3 月 15 日前建立，請再次輪替伺服器憑證，然後再試一次。
不支援整合
與受管理 Microsoft AD 整合時，不支援下列功能：
- 網域本機群組。
- 使用者透過信任關係連線的網域，會捨棄 SQL Server 登入。您可以透過受管理網域中的使用者，或透過
sqlserver登入執行這項操作。 - NTLM 驗證。
- 使用透過信任關係連線的網域 IP 位址登入。
- 名稱過長 (超過 63 個字元) 的執行個體。
後續步驟
- 請參閱 建立 Managed Microsoft AD 網域的快速入門導覽課程。
- 準備建立整合式 Cloud SQL 執行個體。
- 瞭解如何在本機網域和 Managed Microsoft AD 網域之間 建立信任關係。
- 查看如何 檢視整合的執行個體。