Cloud SQL で Managed Microsoft AD を使用する

MySQL | PostgreSQL | SQL Server

このページでは、Cloud SQL を使用して次のことを行う方法について説明します。

Managed Service for Microsoft Active Directory（Managed Microsoft AD とも呼ばれます）と統合する。
AD ユーザーでインスタンスに接続する。

Managed Microsoft AD と統合される Cloud SQL インスタンスは、SQL 認証に加えて Windows 認証もサポートします。

始める前に

Google Cloud Console で、プロジェクト名を選択します。
Google Cloud プロジェクトの課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法。
gcloud CLI をインストールして初期化します。
ユーザーアカウントに Cloud SQL Admin ロールがあることを確認します。IAM ページに移動します。
統合の前提条件を確認します。

Windows 認証を使用してインスタンスを作成する

インスタンスの作成時に Managed Microsoft AD と統合して、そのインスタンスに対して Windows 認証を有効にできます。統合するには、インスタンスが参加するドメインを選択します。ドメインの参加に失敗すると、インスタンスを作成できません。

Windows 認証を使用してインスタンスを作成するにあたっては、ヒントや制限事項と代替案を確認してください。

パブリック IP を持つインスタンスは、プライベート IP も持っている場合に限りサポートされます。インスタンスに対してプライベート IP を有効にする必要があります。そのため、パブリック IP とプライベート IP の両方が使用可能である限り、インスタンスへの接続にどちらを使用するか選択できます。

注: Windows 認証を使用してインスタンスを作成すると、追加の Cloud SQL for SQL Server ログインが作成されます。ログインの形式は、[domain]\sql_[letters-and-digits] です。たとえば、Cloud SQL は AD\sql_1a1a6145bc1aaaa という名前のログインを作成します。ログインは Managed AD ドメイン内にあります。ログインは無視できます。削除はできません。ただし、インスタンスの Windows 認証を無効にすると、このログインは自動的に削除されます。

Managed Microsoft AD と統合されたインスタンスを作成するオプションは次のとおりです。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
[インスタンスを作成] をクリックします。
[SQL Server を選択] をクリックします。
インスタンスの名前を入力します。インスタンス名には機密情報や個人を特定できる情報を含めないでください。インスタンス名は外部から閲覧可能です。インスタンス名にプロジェクト ID を含める必要はありません。これは、必要に応じて自動的に（ログファイルなどに）作成されます。
'sqlserver' ユーザーのパスワードを入力します。
インスタンスのリージョンを設定します。Managed Microsoft AD と統合するためのベストプラクティスをご覧ください。
[構成オプション] セクションで、必要なオプションを設定します（ただし、認証オプションについては次の手順まで待ちます）。
[認証] をクリックします。Managed Active Directory ドメインに参加するためのプルダウンメニューには、以前にプロジェクトに追加された Managed Microsoft AD ドメインが一覧表示されます。
Managed 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 リソースを使用します。

cloud_sql/sqlserver_instance_active_directory/main.tf

GitHub で表示フィードバック

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 認証を使用してインスタンスを更新する

ドメインの変更や追加を行うと、既存のインスタンスのドメインを更新できます。

インスタンスの更新に関する一般的な情報については、インスタンスの編集をご覧ください。

インスタンスが現在 Managed AD ドメインに参加している場合、新しいドメインに参加させる前に、先に参加しているドメインからそのインスタンスを外します。更新に失敗すると、インスタンスがどのドメインにも参加できなくなる場合があります。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
[編集] をクリックします。
[認証] をクリックします。[Join an Active Directory domain] プルダウンメニューには、以前にプロジェクトに追加された Managed Microsoft AD ドメインが一覧表示されます。
Managed Active Directory ドメインに参加するためのプルダウンメニューから、インスタンスの新しい（置換する）ドメインを選択します。
[保存] をクリックして変更を適用します。

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 コンソールを使用することはできません。

統合を計画する際は、制約を確認してください。

ドメインピアリングを有効にする

以下のセクションの手順に進む前に、ドメインピアリングを有効にします。これにより、Cloud SQL for SQL Server インスタンスを含むすべての必要なプロジェクトでドメインを使用できるようになります。

すでに利用可能な他のプロジェクトのドメインを一覧表示するには、以下を指定します。

`gcloud active-directory peerings list`

詳細については、ドメインピアリングの一覧表示をご覧ください。

gcloud active-directory peerings list コマンドには、managedidentities.peerings.list 権限が必要です。この権限は次のロールに含まれています。

roles/managedidentities.peeringViewer
roles/managedidentities.viewer

詳しくは、IAM によるアクセス制御をご覧ください。

サービスアカウントを作成する

統合する Cloud SQL for SQL Server インスタンスを含むプロジェクトごとに、上記の手順を繰り返します。

サービスアカウント作成のバックグラウンド情報を確認します。
次のようなコマンドを使用して、サービスアカウントを作成します。Cloud SQL for SQL Server インスタンスを含むプロジェクトの ID を指定します。
```
gcloud beta services identity create --service=sqladmin.googleapis.com \
--project=[PROJECT_ID]
```
Managed 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 インスタンスの作成または更新時に、完全なドメインリソース名を指定します。次の 2 つの形式がサポートされています。

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 など）を使用する場合、システムは Managed Microsoft AD ドメインが Cloud SQL for SQL Server インスタンスと同じプロジェクトにあると仮定します。

別のプロジェクトとの統合の制約

別のプロジェクトのマネージド AD ドメインと統合する場合は、次の制約が適用されます。

Cloud SQL for SQL Server インスタンスを含む最大 10 個のネットワークで、別のプロジェクトにある 1 つの Managed Microsoft AD インスタンスを共有できます。
Google Cloud コンソールでは、同じプロジェクト内にあるマネージド Microsoft AD インスタンスのみがサポートされます。Google Cloud コンソールを使用する代わりに、gcloud コマンドまたは Cloud SQL REST API を使用して統合できます。
VPC Service Controls を使用する場合、Cloud SQL for SQL Server インスタンスと Managed Microsoft AD インスタンスは同じ境界内に配置する必要があります。

また、インスタンスを別のプロジェクトのマネージド AD ドメインと統合している場合、そのインスタンスの Google Cloud コンソールに表示される完全修飾ドメイン名（FQDN）が不正確になる場合があります。具体的には、そのインスタンスの [概要] ページの [このインスタンスとの接続] で、FQDN にスラッシュで区切られた文字列が含まれていることがありますが、無視してかまいません。たとえば、不正確な FQDN は次のように表示されます。

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

その場合、正確な FQDN は次のようになります。

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

インスタンスから Windows 認証を削除する

既存のインスタンスから Windows 認証（および Managed Microsoft AD 統合）を削除できます。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
[編集] をクリックします。
[認証] をクリックします。Managed Active Directory ドメインに参加するためのプルダウンメニューには、以前にプロジェクトに追加された Managed Microsoft AD ドメインが一覧表示されます。
プルダウンメニューから、インスタンスに [ドメインなし / 後で参加] を選択します。
インスタンスの再起動に関するメッセージを読み、[閉じる] をクリックします。
[保存] をクリックして変更を適用します。

gcloud

ドメインからインスタンスを削除し、したがって Windows 認証を削除するには、そのドメインに対して空白値を使用します。つまり、コマンドでは次のように --active-directory-domain パラメータに空白値を使用します。

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

REST

REST API を使用すると、ドメインからインスタンスを削除できます。次のように、domain フィールドに空白値を指定します。

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

ユーザーを使ってインスタンスに接続する

Cloud SQL for SQL Server の場合、デフォルトユーザーは sqlserver です。

インスタンスを Managed Microsoft AD と統合した後、次のように sqlserver ユーザーを使用してインスタンスに接続できます。

次のように、Windows ユーザーまたはグループに基づいて SQL Server ログインを作成します。
```
CREATE LOGIN [domain\user_or_group] FROM WINDOWS
```
インスタンスの DNS 名で、Windows 認証を使用してインスタンスにログインします。指定するインスタンスの DNS 名の例を次に示します。
- プライベート IP 経由で接続するには:
```
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- パブリック IP 経由で接続するには:
```
public.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Cloud SQL Auth Proxy 経由で接続するには（以下もご覧ください）:
```
proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
インスタンス IP アドレスを使用する場合は、IP ホスト名をサポートするように Kerberos クライアントを構成する必要があります。Cloud SQL では、信頼関係を介して接続されたドメインからのログインはサポートされていません。

Windows 認証を使用する Cloud SQL Auth Proxy を使う

Managed Microsoft AD 統合を使用する Cloud SQL Auth プロキシを使用できます。

始める前に、次を確認してください。

Windows 認証の手順

Cloud SQL Auth Proxy の起動の背景的情報については、Cloud SQL Auth Proxy を起動するをご覧ください。

Windows 認証では、ポート 1433 で Cloud SQL Auth Proxy を実行する必要があります。事前定義されたサービスプリンシパル名（SPN）エントリを Cloud SQL Auth Proxy アドレスにマッピングするには、次のコマンドを使用します。

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

Cloud SQL Auth Proxy をローカルで動作させる

Cloud SQL Auth Proxy をローカルで動作させる場合は、hosts ファイルを使用して、以下を 127.0.0.1 にマッピングします。

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

たとえば、以下を hosts ファイル（c:\windows\system32\drivers\etc\hosts など）に追加できます。

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

次の例では、このコマンドを使用して Cloud SQL Auth Proxy を動作させ、127.0.0.1:1433 で使用できるようにします。

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

Cloud SQL Auth Proxy をローカル以外で動作させる

Cloud SQL Auth Proxy をローカル以外で動作させる場合は、Cloud SQL Auth Proxy をローカルで動作させるの手順で操作しますが、hosts ファイルの別のエントリを使用します。

具体的には、ローカル以外のホスト（MyOtherHost など）の場合は、以下を hosts ファイルに追加できます。

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

クライアントでの NTLM フォールバックのトラブルシューティング

Windows 認証とインスタンス IP アドレスを使用してインスタンスにログインする場合は、IP ホスト名をサポートするように Kerberos クライアントを構成する必要があります。

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 フォールバックがエラーの原因となっていることを確認するには:

任意のオンプレミス認証情報でログインします（「Run as...」は使用しないでください）。
コマンドプロンプトを開きます。
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 のドキュメントに記載されている方法を試してください。FQDN を使用する必要がある場合、この方法はオンプレミス認証情報では機能しません。
外部の信頼を介した Kerberos 認証は機能しません。こちらで説明されているように、代わりにフォレスト間の信頼を使用してください。
Kerberos 認証では、別のフォレスト内のサービスを検出するために、名前サフィックスルーティングが必要になります。こちらに記載されている方法を試してください。
サービスに SPN が登録されていない場合は、Kerberos 認証は機能しません。Windows 認証に接続するには、Google Cloud コンソールから取得した FQDN または IP アドレスのみを使用します。

オンプレミス AD ユーザー: Windows ログインの作成

オンプレミス AD ユーザーを使用して、Cloud SQL for SQL Server への Windows ログインを作成できます。

たとえば、Google Cloud プロジェクトの Virtual Private Cloud（VPC）でホストされている Windows VM で動作している SQL Server Management Studio（SMSS）を使用して接続できます。

このコンテキストでの Windows 認証では、Cloud SQL for SQL Server は Kerberos プロトコルのみをサポートします。Kerberos ベースの Windows 認証では、クライアントはオンプレミスの AD と Managed Microsoft AD の DNS 名を解決する必要があります。

一方向または双方向の信頼を構成する

最初に、一方向または双方向の信頼関係を使用するかどうかを決定します。

その後、オンプレミス AD ドメインと Managed Microsoft AD ドメイン間の信頼を確立する手順を行います。

オンプレミス AD ドメインと Managed Microsoft AD ドメインの間で信頼を確立したら、次の手順を行います。例として、以下の手順では Google Cloud プロジェクトの VPC でホストされている Windows VM で動作している SQL Server Management Studio（SSMS）を使用します。

Windows VM を作成します。
- Managed Microsoft AD でサポートされている Windows のバージョンで VM を作成します。
- Managed Microsoft AD ドメインをホストするプロジェクト内に VM を作成します。承認済みネットワークである共有 VPC がある場合は、任意のサービスプロジェクト内に VM を作成することもできます。
- Managed Microsoft AD ドメインの承認済みネットワークであり、Cloud SQL の限定公開サービスアクセスを構成している VPC ネットワークに VM を作成します。
Windows VM を Managed Microsoft AD ドメインに参加させます。
Windows VM に SSMS をインストールします。
VPC ネットワーク内のオンプレミスドメインを解決します。
- Windows VM が動作している承認済みネットワークから、非マネージド Microsoft AD オブジェクトに関するクエリを解決するページの手順に沿って、オンプレミスの DNS 解決を有効にします。このページの手順は、Kerberos ベースの Windows 認証がオンプレミスユーザーで機能するための前提条件です。
オンプレミスユーザーの Windows ログインを作成します。
- オンプレミスユーザーの Windows ログインを作成する方法については、ログインの作成の手順をご覧ください。たとえば、次のようなコマンドを指定します。
```
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
```
オンプレミスユーザーをログインさせるためのアプリケーション固有の手順に沿って、Cloud SQL for SQL Server インスタンスにログインします。たとえば、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 がサポートされています。
次のいずれかのエラーが表示された場合は、統合の前提条件がすべて満たされていることを確認してください。
- 「Per-Product Per-Project Service Account is not found」
- 「Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain」
「Domain not found」というエラーが表示された場合は、ドメイン名の大文字と小文字が正しいことを確認してください。
信頼関係を介して接続されたドメインからの Windows 認証が失敗する場合は、マネージドドメインのユーザーに対して Windows 認証が動作することを確認します。その場合は次の手順を行います。
1. DNS 名を使用したことを確認します。信頼関係を使用して接続されたドメインでは、IP アドレスはサポートされません。
2. すべてのファイアウォールポートの開放など、オンプレミスドメインとの信頼の作成のすべての手順に沿っていることを確認します。
3. 信頼を確認します。
4. 信頼の方向により、信頼関係を介して接続されたドメインのユーザーがマネージドドメインで認証できることを確認します。
5. 信頼関係を介して接続されているドメインに名前サフィックスルーティングが設定されていることを確認します。
6. Cloud SQL for SQL Server を使用しないで信頼が機能することを確認します。
  1. Windows VM を作成します。
  2. Managed Microsoft AD ドメインに Windows VM を参加させます。
  3. たとえば、信頼関係を通じて接続されているドメインのユーザーとして、メモ帳を実行してみます。
7. クライアント VM を再起動し、Windows 認証を再テストします。
SQL Server ログインを作成しようとすると、「Windows NT user or group domain\name not found. Check the name again」というエラーが発生する場合があります。このエラーは、ドメインローカルグループがサポートされていないことが原因で発生する可能性があります。該当する場合は、グローバルグループまたはユニバーサルグループを代わりに使用します。
信頼関係を介して接続されたドメインからユーザーが SQL Server クエリを発行すると、「Could not obtain information about Windows NT group/user」というエラーが発生する可能性があります。このエラーは、たとえば、信頼関係を介して接続されたドメインからログインを作成する場合に発生することがあります。このエラーは、信頼関係を介して接続されたドメインからログインに権限を付与した場合にも発生することがあります。このようなケースでは、多くの場合、オペレーションの再試行は成功します。再試行に失敗した場合は、接続を閉じてから新しい接続を開きます。
「Windows NT グループ/ユーザーに関する情報を取得できませんでした」というエラーが表示された場合は、Cloud Logging で Cloud SQL for SQL Server インスタンスのログファイル active_directory.log を使用して、オンプレミスドメインへのネットワーク接続を確認します。このファイルには、オンプレミスドメインへの接続性変更に関する次の診断が含まれています。

注: ファイル内のタイムスタンプは現地時間です。
- Cloud SQL for SQL Server インスタンスによって信頼されているオンプレミスドメイン。たとえば、次のログは、信頼されているドメインがない状態から、NetBIOS 名としての 2 つの新しい信頼できるドメイン（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 ドメインに信頼が存在し、検証されているかどうかを確認します。Managed AD ドメインとオンプレミスドメインの間に一方向の信頼関係がある場合、オンプレミスドメインが信頼する他のオンプレミスドメインが表示されない可能性があります。
- Cloud SQL for SQL Server インスタンスからの通常の ping を使用して、到達可能な、または到達不可能なオンプレミスドメイン。たとえば、次のログは、到達可能なドメインがない状態から、2 つの新しい到達可能ドメイン（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 プロジェクトの間には、常に VPC ピアリングが 1 つ存在します。VPC ピアリングがもう 1 つ存在すると推移的ピアリング接続が形成されますが、Cloud SQL ではサポートされていません。代わりに、VPN トンネルを使用してオンプレミスドメインを Cloud SQL に接続することをおすすめします。オンプレミスプロジェクトと Cloud SQL for SQL Server インスタンスとの Google Cloud プロジェクトの間には、ピアリング接続が 1 つだけ必要です。
- Cloud SQL for SQL Server インスタンスからオンプレミスドメインへの Microsoft リモートプロシージャコール（MSRPC）ping の成功と失敗。たとえば、次のログは、MSRPC ping 対象ドメインがない状態から、2 つの新しい 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 は追加の診断として含まれており、一部の構成では機能しない場合がありますが、最初の 2 つの診断を通じて、オンプレミスドメインの接続性を確認できます。
SQL Server のクエリにより「The login is from an untrusted domain」というエラーが発生した場合は、信頼関係を介して接続されているドメインのユーザーには IP アドレスの使用がサポートされていないことに留意してください。また、次の操作によってこの問題を解決できる場合があります。
- マネージドドメインからのユーザーの接続に IP アドレスを使用する場合は、こちらの手順を行ってください。
- Cloud SQL for SQL Server への接続には、プロキシは利用せず、Google Cloud Console で表示される名前と同じ DNS 名を常に使用してください。
- 既存の Kerberos チケットを削除します。上記のエラーは、クライアントが最近 Cloud SQL for SQL Server インスタンスに接続しており、そのインスタンスが停止して起動した場合に発生する可能性があります。あるいは、Cloud SQL for SQL Server インスタンスに対して Windows 認証を無効にしてから再度有効にすると、このエラーが発生する場合があります。クライアントが Windows 認証情報キャッシュを使用する場合は、クライアントのワークステーションのロックとロック解除を行うか、klist purge を実行します。
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 と統合することはできません。
- Cloud SQL for SQL Server インスタンスを作成し、作成時に Managed Microsoft AD を有効にしない場合、同じエラーが発生することがあります。このセクションの他のヒントを確認したら、新しいインスタンスを作成して、インスタンスの作成時に Managed Microsoft AD を有効にします。
Cloud SQL for SQL Server インスタンスを作成しようとすると、「このインスタンスは Microsoft Active Directory のマネージドサービスをサポートしていません」というエラーが発生する可能性があります。このエラーが発生する場合は、プロジェクトがサポート対象外である可能性があります。別のプロジェクトをお試しください。
インスタンスが最近更新されたかどうかにかかわらず、Windows 認証で継続的に問題が発生している場合は、Managed Active Directory ドメインの参加を解除して、再度参加させてください。この操作を行うには、更新手順を使用して、ドメインの参加を解除して、再度ドメインに参加させてください。この操作を行っても、データベースにある既存の Windows 認証ユーザーまたはログインは削除されません。ただし、Windows 認証を削除すると、インスタンスが再起動されます。
AD 診断ツールを使用して、Google Cloud コンソールでオンプレミスドメインと Cloud SQL for SQL Server インスタンスの 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 インスタンスが、同じ Managed 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`	Managed Active Directory ドメインで必要な更新を実施できません。	Windows 認証で問題が発生した場合は、Managed 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 で Managed Microsoft AD を使用する

始める前に

Windows 認証を使用してインスタンスを作成する

コンソール

gcloud

Terraform

REST

Windows 認証を使用してインスタンスを更新する

コンソール

gcloud

REST

別のプロジェクトのマネージド AD ドメインと統合する

ドメイン ピアリングを有効にする

サービス アカウントを作成する

プロジェクト間の Windows 認証を有効にする

別のプロジェクトとの統合の制約

インスタンスから Windows 認証を削除する

コンソール

gcloud

REST

ユーザーを使ってインスタンスに接続する

Windows 認証を使用する Cloud SQL Auth Proxy を使う

Windows 認証の手順

Cloud SQL Auth Proxy をローカルで動作させる

Cloud SQL Auth Proxy をローカル以外で動作させる

クライアントでの NTLM フォールバックのトラブルシューティング

Windows クライアントの NTLM フォールバックの確認

Linux クライアントの NTLM フォールバックの確認

Kerberos 認証の設定

Windows 認証との接続

NTLM フォールバックの理由

オンプレミス AD ユーザー: Windows ログインの作成

一方向または双方向の信頼を構成する

Windows VM を設定して Windows ログインを作成する

オンプレミス AD ユーザーに関連する問題を解決する

ヒント

トラブルシューティング

次のステップ

ドメインピアリングを有効にする

サービスアカウントを作成する