您可以將 Cloud SQL for SQL Server 與 Managed Service for Microsoft Active Directory (也稱為 Managed Microsoft AD) 整合。
本頁面提供開始整合前應先查看的資訊。詳閱下列資訊 (包括限制) 後,請參閱「透過 Cloud SQL 使用代管的 Microsoft AD」。
與 Managed Microsoft AD 整合的好處
您可以透過 Managed Microsoft AD 執行驗證、授權等作業。舉例來說,將執行個體加入代管的 Microsoft AD 網域後,您就能使用 Windows 驗證機制,搭配以 AD 為基礎的身分登入。
將 SQL Server 適用的 Cloud SQL 與 AD 網域整合,可進一步整合雲端與貴機構內部 AD 網域。
整合前置條件
您可以整合受管理的 Microsoft AD,為執行個體新增 Windows 驗證支援。不過,在整合前,您必須為Google Cloud 專案執行下列操作:
- 代管的 Microsoft AD 網域。如要瞭解如何設定網域,請參閱「建立網域」。
- 內部部署的 AD 網域需要受管理的 AD 信任關係。請參閱「建立單向信任關係」和「使用內部 AD 使用者建立 Cloud SQL 的 Windows 登入資訊」。
- 如以下各節所述,每項產品、每個專案專屬的服務帳戶 (請參閱「建立服務帳戶」)。
建立及設定服務帳戶
您需要為每個要與 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 整合的最佳做法
規劃整合時,請查看下列事項:
- 整合前置條件
- 與不同專案中的受管理 AD 網域整合
- 代管型 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 登入。在 Cloud SQL for SQL Server 中,您可以啟用類似的功能,如本節所述。
選項 1:將使用者帳戶和群組新增為 SQL Server 的登入帳戶
如果您有多個網域和樹系,且有多個全域群組,您可以直接將所有個別使用者帳戶,以及全域和通用群組新增為 SQL Server 的登入帳戶。請參閱下圖,瞭解選項 1 的示例:
方法 2:在其中一個網域中定義通用群組
如果您的網域位於同一個林中,您可以在其中一個網域中定義通用群組。接著,您可以將所有個別使用者帳戶,以及全域和通用群組,新增為該已定義通用群組的子項,然後將已定義的通用群組新增為 SQL Server 登入帳戶。請參閱下圖,瞭解做法 2 的示例:
限制和替代方案
與 Managed Microsoft AD 整合時,適用下列限制:
- 不支援網域本機群組,但您可以直接在 SQL Server 中新增全域群組或個別使用者登入資訊。或者,如果所有群組和使用者都屬於同一個林,您也可以使用通用群組。
- 一般來說,透過 Google Cloud 主控台建立的新使用者會指派
CustomerDbRootRole
角色,該角色具有以下 SQL Server 代理程式固定資料庫角色:SQLAgentUserRole
。不過,直接透過 SQL Server 建立的使用者 (例如受管理的 Microsoft AD 使用者) 無法獲得此角色,也無法使用 SQL Server Agent,因為必須授予此角色的 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 執行個體。
- 瞭解如何在內部部署網域和受管理的 Microsoft AD 網域之間 建立信任關係。
- 查看如何 查看已整合的執行個體。