本頁面由 Cloud Translation API 翻譯而成。

透過 Cloud SQL 使用代管的 Microsoft AD

MySQL | PostgreSQL | SQL Server

本頁說明如何使用 Cloud SQL 執行下列操作：

與 Managed Service for Microsoft Active Directory (也稱為 Managed Microsoft AD) 整合。
使用 AD 使用者連線至執行個體。

與代管 Microsoft AD 整合的 Cloud SQL 執行個體除了支援 SQL 驗證，也支援 Windows 驗證。

事前準備

在 Google Cloud 控制台中，選取專案名稱。
請確認您已為 Google Cloud 專案啟用計費功能。瞭解如何確認您已啟用專案的計費功能。
安裝並初始化 gcloud CLI。
確認使用者帳戶具備 Cloud SQL Admin 角色。前往「IAM」頁面。
查看整合的必要條件。

建立使用 Windows 驗證的執行個體

您可以在建立執行個體時整合 Managed Microsoft AD，為執行個體啟用 Windows 驗證。如要整合，請選擇執行個體要加入的網域。如果加入網域失敗，執行個體建立作業也會失敗。

準備建立使用 Windows 驗證的執行個體時，請先參閱提示，以及限制和替代方案。

只要執行個體同時具備私人 IP，即可支援公開 IP；執行個體必須啟用私人 IP。然後，只要公開 IP 和私人 IP 皆可使用，您就能選擇使用其中一種 IP 連線至執行個體。

注意：使用 Windows 驗證建立執行個體後，系統會額外建立一個 Cloud SQL for SQL Server 登入帳戶。登入資訊的格式為 [domain]\sql_[letters-and-digits]。舉例來說，Cloud SQL 可能會建立名為 AD\sql_1a1a6145bc1aaaa 的登入項目。登入作業是在代管 AD 網域中進行。您可以忽略登入要求。你無法移除這項設定。不過，如果停用執行個體的 Windows 驗證，系統會自動刪除登入資訊。

以下是建立與 Managed Microsoft AD 整合執行個體的選項。

控制台

前往 Google Cloud 控制台的「Cloud SQL Instances」頁面。

前往 Cloud SQL 執行個體
點選「建立執行個體」。
按一下「Choose SQL Server」(選取 SQL Server)。
輸入執行個體名稱。請勿在執行個體名稱中加入敏感資訊或個人識別資訊，因為外部使用者可以看見此名稱。您不需要在執行個體名稱中包含專案 ID，系統會在適當地方 (例如在記錄檔中) 自動加入。
輸入「'sqlserver'」使用者的密碼。
設定執行個體的區域。請參閱「與 Managed Microsoft AD 整合的最佳做法」。
在「設定選項」部分中，設定所需選項 (但請等到下一個步驟再設定驗證選項)。
按一下「驗證」。加入代管 Active Directory 網域的下拉式選單會列出先前在專案中新增的代管 Microsoft AD 網域。
從加入受管理 Active Directory 網域的下拉式選單中，選取網域。
選取完設定選項後，按一下「建立」。Cloud SQL 會自動為您建立每個產品和每個專案的服務帳戶。如果帳戶沒有適當的角色，系統會提示您授予 managedidentities.sqlintegrator 角色。

gcloud

下列指令會建立與 Managed Microsoft AD 整合的執行個體，因此會啟用 Windows 驗證。如要瞭解建立執行個體的基本指令，請參閱建立執行個體。

在 gcloud 指令中指定 --active-directory-domain=DOMAIN 參數。舉例來說，請指定下列項目： --active-directory-domain=ad.mydomain.com

以下是 gcloud 指令的原型：

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

Terraform

如要建立與 Managed Microsoft AD 整合的執行個體，請使用 Terraform 資源。

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

REST

您可以使用 REST API 建立與 Managed Microsoft AD 整合的執行個體。為 domain 欄位指定網域，例如 subdomain.mydomain.com，如以下要求原型所示：

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

使用 Windows 驗證更新執行個體

您可以更新現有執行個體的網域，變更或新增網域。

如需更新執行個體的一般資訊，請參閱編輯執行個體。

如果執行個體目前已加入受管理 AD 網域，系統會先將執行個體從該網域取消加入，再加入新網域。如果更新失敗，執行個體可能無法再加入任何網域。

控制台

前往 Google Cloud 控制台的「Cloud SQL Instances」頁面。

前往 Cloud SQL 執行個體
如要開啟執行個體的「總覽」頁面，請按一下執行個體名稱。
按一下 [編輯]。
按一下「驗證」。「加入 Active Directory 網域」下拉式選單會列出先前在專案中新增的代管 Microsoft AD 網域。
從加入受管理 Active Directory 網域的下拉式選單中，為執行個體選取新的 (替代) 網域。
按一下 [Save] (儲存) 套用您的變更。

gcloud

以下是更新現有執行個體的指令原型。這項指令會新增或取代網域。將 --active-directory-domain=DOMAIN 傳遞至指令，如下所示：

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

REST

您可以使用 REST API 更新現有執行個體。在 domain 欄位中指定網域，例如 subdomain.mydomain.com。以下是要求的原型：

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

與其他專案中的代管 AD 網域整合

您可以將執行個體與不同專案中的 Managed Microsoft AD 網域整合。

注意：如要整合不同專案中的 AD 網域，必須使用 gcloud 指令或 Cloud SQL REST API。目前無法使用 Google Cloud 控制台執行這項操作。

規劃整合時，請先查看限制。

啟用網域對等互連

請先啟用網域對等互連，讓網域可供所有必要的專案使用，再繼續執行下列各節的步驟。

如要查看其他專案中已可用的網域清單，可以指定下列項目：

`gcloud active-directory peerings list`

詳情請參閱列出網域對等互連。

gcloud active-directory peerings list 指令需要 managedidentities.peerings.list 權限。下列角色具備這項權限：

roles/managedidentities.peeringViewer
roles/managedidentities.viewer

詳情請參閱「使用身分與存取權管理功能控管存取權」一文。

建立服務帳戶

針對每個含有要整合的 Cloud SQL for SQL Server 執行個體的專案，重複執行這些步驟。

查看建立服務帳戶的背景資訊。
使用類似下列的指令建立服務帳戶。指定包含 SQL Server 適用的 Cloud SQL 執行個體的專案 ID：
```
gcloud beta services identity create --service=sqladmin.googleapis.com \
--project=[PROJECT_ID]
```
在具有代管 Microsoft AD 執行個體的專案中，授予 managedidentities.sqlintegrator 角色。指定包含 Managed Microsoft AD 執行個體的專案 ID：
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator
```

啟用跨專案 Windows 驗證

您可以使用 gcloud 指令或 Cloud SQL REST API，與其他專案中的 AD 網域整合。無論選擇哪一種做法，您都必須指定完整的網域資源名稱。

建立或更新 Cloud SQL for SQL Server 執行個體時，請指定完整網域資源名稱。支援的格式有兩種：

projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

以下是使用 gcloud 的範例：

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

如果您使用簡短的網域資源名稱 (例如 DOMAIN_NAME)，系統會假設您的代管 Microsoft AD 網域與 SQL Server 適用的 Cloud SQL 執行個體位於相同專案。

整合不同專案的限制

如果您要與其他專案中的受管理 AD 網域整合，請注意下列限制：

最多 10 個網路可與 SQL Server 適用的 Cloud SQL 執行個體共用一個位於不同專案的代管 Microsoft AD 執行個體。
Google Cloud 主控台僅支援位於同一專案中的受管理 Microsoft AD 執行個體。您可以使用 gcloud 指令或 Cloud SQL REST API 整合，不必使用 Google Cloud 控制台。
如果使用 VPC Service Controls，Cloud SQL for SQL Server 執行個體和受管理 Microsoft AD 執行個體必須位於同一服務範圍內。

此外，如果執行個體與不同專案中的受管理 AD 網域整合，Google Cloud 控制台中顯示的完整網域名稱 (FQDN) 可能不正確。具體來說，在該執行個體的「總覽」頁面中，「連線至這個執行個體」下方可能會有以斜線分隔的字串，您可以忽略這些字串。舉例來說，不正確的 FQDN 可能會顯示為：

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

在這種情況下，正確的 FQDN 為：

private.myinstance.myregion.myproject.cloudsql.mydomain.com

從執行個體中移除 Windows 驗證

您可以從現有執行個體移除 Windows 驗證，進而移除受管理 Microsoft AD 整合。

控制台

前往 Google Cloud 控制台的「Cloud SQL Instances」頁面。

前往 Cloud SQL 執行個體
如要開啟執行個體的「總覽」頁面，請按一下執行個體名稱。
按一下 [編輯]。
按一下「驗證」。加入代管 Active Directory 網域的下拉式選單會列出先前在專案中新增的代管 Microsoft AD 網域。
從下拉式選單中，為執行個體選取「沒有網域/稍後加入」。
詳閱執行個體重新啟動的相關訊息，然後按一下「關閉」。
按一下 [Save] (儲存) 套用您的變更。

gcloud

如要從網域中移除執行個體，進而移除 Windows 驗證，請使用空白網域值。也就是說，在指令中，請為 --active-directory-domain 參數使用空白值，如下所示：

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

REST

您可以使用 REST API 從網域中移除執行個體。在 domain 欄位中指定空白值，如下所示：

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

與使用者連線至執行個體

如果是 SQL Server 適用的 Cloud SQL，預設使用者為 sqlserver。

將執行個體與受管理 Microsoft AD 整合後，即可使用 sqlserver 使用者連線至執行個體，方法如下：

根據 Windows 使用者或群組建立 SQL Server 登入，如下所示：
```
CREATE LOGIN [domain\user_or_group] FROM WINDOWS
```
使用 Windows 驗證功能和執行個體 DNS 名稱登入執行個體。以下是可指定的執行個體 DNS 名稱範例：
- 如要透過私人 IP 連線，請按照下列步驟操作：
```
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- 如要透過公開 IP 連線：
```
public.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- 如要透過 Cloud SQL 驗證 Proxy 連線 (另請參閱下文)：
```
proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
如果您使用執行個體 IP 位址，必須設定 Kerberos 用戶端，支援 IP 主機名稱。Cloud SQL 不支援透過信任關係連線的網域登入。

搭配 Windows 驗證使用 Cloud SQL 驗證 Proxy

您可以搭配代管的 Microsoft AD 整合功能使用 Cloud SQL 驗證 Proxy。

開始前，請先詳閱：

Windows 驗證步驟

如要瞭解啟動 Cloud SQL 驗證 Proxy 的背景資訊，請參閱「啟動 Cloud SQL 驗證 Proxy」。

如要使用 Windows 驗證，您必須在通訊埠 1433 上執行 Cloud SQL 驗證 Proxy。如要將預先定義的服務主體名稱 (SPN) 項目對應至 Cloud SQL 驗證 Proxy 位址，請使用：

proxy.[instance].[location].[project].cloudsql.[domain]

在本機執行 Cloud SQL 驗證 Proxy

如果您在本機執行 Cloud SQL 驗證 Proxy，請使用主機檔案將下列項目對應至 127.0.0.1：

proxy.[instance].[location].[project].cloudsql.[domain]

舉例來說，您可以在主機檔案中新增下列內容 (例如 c:\windows\system32\drivers\etc\hosts)：

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

在該範例中，您可以使用下列指令執行 Cloud SQL 驗證 Proxy，並在 127.0.0.1:1433 上提供該 Proxy：

cloud-sql-proxy.exe --credentials-file credential.json project:name

在非本機執行 Cloud SQL 驗證 Proxy

如要在非本機執行 Cloud SQL Auth Proxy，請按照「在本機執行 Cloud SQL Auth Proxy」一文中的操作說明，但使用主機檔案中的不同項目。

具體來說，如果非本機主機是 MyOtherHost，您可以在主機檔案中加入下列內容：

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

排解用戶端 NTLM 回退問題

如果您使用 Windows 驗證和執行個體 IP 位址登入執行個體，則必須設定 Kerberos 用戶端，才能支援 IP 主機名稱。

Cloud SQL 不支援 NTLM 驗證，但部分 Kerberos 用戶端可能會嘗試改用 NTLM 驗證。如本節所述，如果您嘗試使用 SQL Server Management Studio (SSMS) 連線，並發生下列錯誤訊息，很可能是 NTLM 回退所致：

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM 是一組 Microsoft 驗證安全通訊協定，另請參閱「NTLM 回退的原因」。

驗證 Windows 用戶端的 NTLM 回溯

在 Windows 中，如要確認 NTLM 回退是否導致錯誤，請按照下列步驟操作：

使用所需的內部部署憑證登入 (請勿使用「以...身分執行」)。
開啟命令提示字元。
執行 klist purge。
在 SSMS 中，嘗試使用 Windows 驗證連線至 SQL Server。
執行 klist，並確認是否已為 "MSSQLSvc/<address>:1433 @ domain" 核發支援單。
如果沒有這類票證，錯誤可能就是 NTLM 回退所致。
如果有這類票證，請確認 SQL Server 驅動程式不會強制執行 NTLM 驗證。此外，請檢查是否透過群組原則強制執行 NTLM 驗證。

驗證 Linux 用戶端的 NTLM 備用機制

從 Ubuntu 16.04 開始，如要確認 NTLM 回退是否導致錯誤，請按照本節中的步驟操作。步驟與其他 Linux 發行版本類似。

設定 Kerberos 驗證

設定 Kerberos 用戶端：
```
sudo apt-get install krb5-user
```
系統提示輸入預設領域時，請以大寫字母輸入內部部署網域名稱。

執行下列指令，安裝 SQL Server 指令列工具：

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
sudo apt-get update
sudo apt-get install mssql-tools unixodbc-dev

使用 Windows 驗證連線

執行 kinit 工具，如下所示：kinit <user_account>
如要透過 Windows 驗證連線，請執行： /opt/mssql-tools/bin/sqlcmd -S <address >>
執行 klist 指令，並檢查是否已核發以下項目的票證："MSSQLSvc/<address>:1433 @ domain"
如果未核發票證，上述錯誤可能表示有問題導致 NTLM 回退。

NTLM 回退的原因

回退至 NTLM 是用戶端設定錯誤，可能與下列情況有關：

根據預設，如果主機名稱是 IP 位址，Windows 不會嘗試對主機進行 Kerberos 驗證。如要從受管理網域啟用 Kerberos 驗證，請嘗試這篇 Microsoft 說明文件所述的方法。如果您必須使用 FQDNS，這個方法就不適用於內部部署憑證。
透過外部信任進行 Kerberos 驗證無法運作。請改用樹系信任關係，詳情請參閱這篇文章。
Kerberos 驗證需要名稱字尾路由，才能在其他樹系中尋找服務。請嘗試這裡所述的方法。
如果服務未註冊 SPN，Kerberos 驗證將無法運作。如要使用 Windows 驗證連線，請只使用從 Google Cloud 控制台取得的 FQDN 或 IP 位址。

內部部署 AD 使用者：建立 Windows 登入帳戶

您可以使用內部部署 AD 使用者，為 SQL Server 適用的 Cloud SQL 建立 Windows 登入。

舉例來說，您可以使用在 Google Cloud 專案的虛擬私有雲 (VPC) 中執行的 Windows VM 上執行的 SQL Server Management Studio (SMSS) 進行連線。

在這種情況下，SQL Server 適用的 Cloud SQL 僅支援 Kerberos 通訊協定，如果是以 Kerberos 為基礎的 Windows 驗證，用戶端必須解析地端 AD 和 Managed Microsoft AD 的 DNS 名稱。

設定單向或雙向信任關係

首先，請決定要使用單向或雙向信任關係。

然後，按照建立信任關係的操作說明，在內部部署 AD 網域和 Managed Microsoft AD 網域之間建立信任關係。

在內部部署 AD 網域和 Managed Microsoft AD 網域之間建立信任關係後，請完成下列步驟。舉例來說，這些步驟會使用在 Windows VM 上執行的 SQL Server Management Studio (SSMS)，並託管在您 Google Cloud 專案的虛擬私有雲中：

建立 Windows VM。
- 建立 VM，並使用Managed Microsoft AD 支援的 Windows 版本。
- 在代管 Managed Microsoft AD 網域的專案中建立 VM。如果共用虛擬私有雲是授權網路，您也可以在任何服務專案中建立 VM。
- 在虛擬私有雲網路上建立 VM，該網路是 Managed Microsoft AD 網域的授權網路，且已為 Cloud SQL 設定私人服務存取權。
將 Windows VM 加入代管的 Microsoft AD 網域。
在 Windows VM 上安裝 SSMS。
在 VPC 網路中解析內部部署網域。
- 在 Windows VM 執行的授權網路上，按照「解決非代管 Microsoft AD 物件的查詢」頁面上的步驟，啟用內部部署 DNS 解析。該頁面的步驟是先決條件，可讓內部部署使用者透過 Kerberos 進行 Windows 驗證。
為內部部署使用者建立 Windows 登入帳戶。
- 請按照建立登入帳戶的操作說明，為內部部署使用者建立 Windows 登入帳戶。舉例來說，指定類似下列的指令：
```
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
```
按照應用程式專屬的操作說明，登入 SQL Server 適用的 Cloud SQL 執行個體，以登入內部部署使用者。舉例來說，如果您使用 SQL Server Management Studio，請參閱這些操作說明。

如果登入 Cloud SQL for SQL Server 執行個體時發生問題，請執行下列驗證：

按照建立與內部部署網域的信任關係一文的操作說明，驗證內部部署網路和專案授權 VPC 的防火牆設定。
驗證內部部署信任關係的「名稱後置字元路由」。
確認您可從執行 SSMS 的 Windows VM 執行下列 DNS 解析作業：
- nslookup fqdn-for-managed-ad-domain
- nslookup fqdn-for-on-premises-ad-domain
- nslookup fqdn-for-cloud-sql-server-instance

提示

只要執行個體同時具備私人 IP，即可支援公開 IP。您必須為執行個體啟用私人 IP。然後，只要公開 IP 和私人 IP 皆可使用，您就能選擇使用其中一種連線至執行個體。
建立執行個體 (包括做為替代執行個體) 前，請視需要參閱下列內容：
- 瞭解如何使用私人 IP
- 設定公開 IP
支援 Terraform。
如果收到下列任一錯誤訊息，請確認您已符合整合的所有必要條件：
- 「找不到每個產品/專案的服務帳戶」
- 「Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain」(權限不足，無法與 Microsoft Active Directory 網域代管服務整合)
如果收到「找不到網域」錯誤訊息，請確認網域名稱 (區分大小寫) 正確無誤。
如果透過信任關係連線的網域無法進行 Windows 驗證，請確認受管理網域的使用者是否能進行 Windows 驗證。如果可以，請按照下列步驟操作：
1. 確認您使用的是 DNS 名稱。透過信任關係連結的網域不支援 IP 位址。
2. 請確認您已完成建立內部部署網域信任的所有步驟，包括開啟所有防火牆通訊埠。
3. 驗證信任關係。
4. 確認信任關係的方向是否允許網域 (透過信任關係連線) 的使用者在受管理網域中進行驗證。
5. 確認透過信任關係連線的網域已設定名稱後置字元路由。
6. 確認信任關係是否正常運作，而不使用 SQL Server 適用的 Cloud SQL：
  1. 建立 Windows VM。
  2. 將其加入代管的 Microsoft AD 網域。
  3. 例如，嘗試以透過信任關係連線的網域使用者身分執行記事本。
7. 重新啟動用戶端 VM，然後重新測試 Windows 驗證。
您可能會嘗試建立 SQL Server 登入，但隨後收到下列錯誤：「Windows NT user or group domain\name not found. 再次檢查名稱。這可能是因為系統不支援網域本機群組；如適用，請改用通用群組。
如果使用者是透過信任關係連線的網域發出，SQL Server 查詢可能會導致下列錯誤：「無法取得 Windows NT 群組/使用者資訊」。舉例來說，如果您是從透過信任關係連線的網域建立登入資訊，就可能會發生這個錯誤。如果您要將權限授予透過信任關係連線的網域登入，也可能會發生這個錯誤。在這些情況下，通常可以重試作業。如果重試失敗，請關閉連線並開啟新連線。
如果收到「無法取得 Windows NT 群組/使用者相關資訊」錯誤訊息，請使用 Cloud SQL for SQL Server 執行個體的 Cloud Logging 記錄檔 active_directory.log，檢查與內部部署網域的網路連線。這個檔案包含下列診斷資訊，可協助您瞭解內部部署網域的連線變更：

注意： 檔案中的時間戳記為當地時間。
- Cloud SQL for SQL Server 執行個體信任的內部部署網域。舉例來說，下列記錄顯示從沒有信任網域到兩個新信任網域的變更，這些網域的 NetBIOS 名稱為 ONPREM 和 CHILD：
```
2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]
```
  如果未列出內部部署網域，或系統將其記錄為不受信任，請檢查與 Managed AD 網域的信任關係是否存在，以及是否已通過驗證。如果代管 AD 網域與內部部署網域之間存在單向信任關係，您可能無法看到內部部署網域信任的其他內部部署網域。
- 可連線和無法連線的內部部署網域，使用來自 Cloud SQL for SQL Server 執行個體的標準 Ping 進行測試。舉例來說，以下記錄顯示從沒有可連線網域變更為兩個新的可連線網域，即 onprem.com 和 child.onprem.com：
```
2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]
```
  如果網域未列在可觸及性記錄中，請先確認該網域已記錄為信任的網域。否則系統不會檢查可存取性。我們一律會在具有內部部署執行個體的專案與 Google Cloud 專案之間建立虛擬私有雲對等互連。即使多一個虛擬私有雲對等互連，也會產生遞移對等互連連線，而 Cloud SQL 不支援這類連線。我們建議改用 VPN 通道，將內部部署網域連線至 Cloud SQL。地端專案與含有 SQL Server 適用的 Cloud SQL 執行個體專案之間，最多只能有一個對等互連連線。 Google Cloud
- 從 Cloud SQL for SQL Server 執行個體對內部部署網域發出的 Microsoft 遠端程序呼叫 (MSRPC) Ping 成功和失敗記錄。舉例來說，以下記錄顯示從沒有 MSRPC 可 Ping 網域，變更為有兩個新的 MSRPC 可 Ping 網域，分別是 ONPREM 和 CHILD：
```
2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]
```
  MSRPC ping 會納入額外診斷資訊，但可能無法在某些設定上運作。您還是可以透過前兩項診斷程序，驗證內部部署網域連線。
如果 SQL Server 查詢導致「The login is from an untrusted domain」(登入來自不受信任的網域) 錯誤，請注意，透過信任關係連線的網域使用者無法使用 IP 位址。此外，下列動作可能可以解決這個問題：
- 如果 IP 位址用於連線受管理網域的使用者，請按照這些操作說明操作。
- 請避免使用任何 Proxy，並一律使用相同的 DNS 名稱連線至 SQL Server 適用的 Cloud SQL，因為您會在 Google Cloud 控制台中看到該名稱。
- 清除現有的 Kerberos 票證。如果您最近有用戶端連線至 Cloud SQL for SQL Server 執行個體，且該執行個體已停止並啟動，就可能發生上述錯誤。此外，如果停用 Windows 驗證，然後重新啟用 SQL Server 適用的 Cloud SQL 執行個體，也可能會發生錯誤。如果用戶端使用 Windows 憑證快取，請鎖定及解除鎖定用戶端工作站，或執行 klist purge。
嘗試啟用 Windows 驗證時，可能會出現「This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory」(這個執行個體必須是近期建立，才能支援 Microsoft Active Directory 的受管理服務) 錯誤。請注意下列有關這項錯誤的資訊：
- 在 Cloud SQL 中，如果 Cloud SQL for SQL Server 執行個體是在 2021 年 3 月 12 日當天或之前建立，就無法與受管理 Microsoft AD 整合。
- 在某些情況下，如果您建立 Cloud SQL for SQL Server 執行個體，但未在建立時啟用 Managed Microsoft AD，也可能會收到相同錯誤。請先參閱本節中的其他提示，然後建立新執行個體，並在建立執行個體時啟用代管 Microsoft AD。
嘗試建立 Cloud SQL for SQL Server 執行個體時，可能會發生「This instance does not support Managed Service for Microsoft Active Directory.」錯誤。如果收到這則錯誤訊息，可能是因為專案不受支援，請嘗試使用其他專案。
如果執行個體持續發生 Windows 驗證問題 (無論執行個體最近是否更新)，請嘗試取消加入受管理的 Active Directory 網域，然後重新加入。如要這麼做，請使用更新程序取消加入網域，然後重新加入網域。這麼做不會移除資料庫中現有的 Windows 驗證使用者或登入資訊。不過，移除 Windows 驗證會導致執行個體重新啟動。
使用 AD 診斷工具，排解內部部署網域和 Cloud SQL for SQL Server 執行個體在 Google Cloud 控制台中的 AD 設定問題。

疑難排解

按一下表格中的連結，即可查看詳細資料：

如果發生這個錯誤...	可能原因如下：	請嘗試以下做法：
`Per-product, per-project service account not found.`	服務帳戶名稱有誤。	在服務帳戶頁面中，確認您已為正確的使用者專案建立服務帳戶。
`Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain.`	服務帳戶缺少 `managedidentities.sqlintegrator` 角色。	在「IAM 與管理」頁面中，將 `managedidentities.sqlintegrator` 角色新增至服務帳戶。
`Domain not found`。	網域不存在或輸入錯誤。	確認網域名稱正確無誤。須區分大小寫。
`The domain is busy with another operation. Please retry.`	另一個 Cloud SQL 執行個體正在對同一個受管理 Active Directory 網域執行作業。	重試作業。如果您要對連線至相同網域的 Cloud SQL 執行個體執行批次更新，請限制平行執行的更新數量。
`The operation completed but an update to Active Directory failed. You may experience issues with Windows Authentication on this instance, please see https://cloud.google.com/sql/docs/sqlserver/configure-ad for tips`。	無法在受管理的 Active Directory 網域執行必要更新。	如果 Windows 驗證發生問題，請嘗試取消加入受管理的 Active Directory 網域，然後重新加入。如要這麼做，請使用更新程序取消加入網域，然後重新加入網域。這麼做不會移除資料庫中任何現有的 Windows 驗證使用者或登入資訊。不過，移除 Windows 驗證會導致執行個體重新啟動。
`This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory.`	在 Cloud SQL 中，如果 Cloud SQL for SQL Server 執行個體是在 2021 年 3 月 12 日當天或之前建立，就無法與 Managed Microsoft AD 整合。	請在 2021 年 3 月 12 日後建立的執行個體上嘗試作業。

後續步驟

確認您已詳閱總覽頁面，包括限制和不支援的功能。該頁面也提供其他說明文件的連結。

透過 Cloud SQL 使用代管的 Microsoft AD 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

事前準備

建立使用 Windows 驗證的執行個體

控制台

gcloud

Terraform

REST

使用 Windows 驗證更新執行個體

控制台

gcloud

REST

與其他專案中的代管 AD 網域整合

啟用網域對等互連

建立服務帳戶

啟用跨專案 Windows 驗證

整合不同專案的限制

從執行個體中移除 Windows 驗證

控制台

gcloud

REST

與使用者連線至執行個體

搭配 Windows 驗證使用 Cloud SQL 驗證 Proxy

Windows 驗證步驟

在本機執行 Cloud SQL 驗證 Proxy

在非本機執行 Cloud SQL 驗證 Proxy

排解用戶端 NTLM 回退問題

驗證 Windows 用戶端的 NTLM 回溯

驗證 Linux 用戶端的 NTLM 備用機制

設定 Kerberos 驗證

使用 Windows 驗證連線

NTLM 回退的原因

內部部署 AD 使用者：建立 Windows 登入帳戶

設定單向或雙向信任關係

設定 Windows VM 並建立 Windows 登入資訊

解決與內部部署 AD 使用者相關的問題

提示

疑難排解

後續步驟

透過 Cloud SQL 使用代管的 Microsoft AD