このページでは、顧客管理の Microsoft Active Directory(顧客管理の AD(CMAD)とも呼ばれます)を使用する方法について説明します。
- Cloud SQL for SQL Server を CMAD と統合する。
- Active Directory(AD)ユーザーでインスタンスに接続する。
CMAD と統合される Cloud SQL インスタンスは、SQL 認証に加えて Windows 認証もサポートします。
始める前に
- Google Cloud コンソールで、プロジェクト名を選択します。
- Google Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法はこちらです。
- gcloud CLI をインストールして初期化します。
- ユーザー アカウントに Cloud SQL 管理者のロールがあることを確認します。Identity and Access Management(IAM)ページに移動します。
- 統合の前提条件を確認します。
- Active Directory レプリケーションが正しく機能していることを確認します。適切に実装されていない場合、CMAD 統合で問題が発生する可能性があります。
Windows 認証を使用してインスタンスを作成する
インスタンスの作成時に CMAD と統合して、そのインスタンスに対して Windows 認証を有効にできます。統合するには、インスタンスが参加するドメインを選択します。ドメインへの参加に失敗すると、インスタンスを作成できません。
Windows 認証を使用してインスタンスを作成するにあたっては、ヒントや制限事項と代替案を確認してください。
パブリック IP を使用することもできますが、Cloud SQL インスタンスはプライベート IP にもアクセスできる必要があります。
次のいずれかのオプションを使用して、CMAD と統合され、Windows 認証が有効なインスタンスを作成します。インスタンスを作成する基本的なコマンドについては、インスタンスの作成をご覧ください。
gcloud
CMAD を使用してインスタンスを作成するには、次のコマンドを実行します。
gcloud sql instances create INSTANCE_NAME \ --database-version=DATABASE_VERSION \ --root-password=PASSWORD \ --active-directory-domain=DOMAIN \ --active-directory-mode=CUSTOMER_MANAGED_ACTIVE_DIRECTORY \ --active-directory-organizational-unit="OU=CLOUD_OU,DC=DC1,DC=DC2" \ --active-directory-secret-manager-key=projects/PROJECT_ID/secrets/SECRET_NAME \ --active-directory-dns-servers=IP1,IP2 \ --cpu=CPU \ --memory=MEMORY \ --network=NETWORK
次のように置き換えます。
- INSTANCE_NAME: 作成する Cloud SQL for SQL Server インスタンスの名前。
- DATABASE_VERSION: 使用するデータベース バージョン(例:
SQLSERVER_2019_STANDARD)。 - DOMAIN: 使用するドメイン名(
myaddomain.comなど)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが配置されるプロジェクト ID。
- SECRET_NAME: 使用するシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。 - CPU: インスタンスに割り当てる CPU の量。
- MEMORY: インスタンスに割り当てるメモリ容量。
- NETWORK: インスタンスが接続されるネットワークの名前(例:
projects/my-gcp-project-123/global/networks/my-production-vpc)。
REST v1
CMAD を使用してインスタンスを作成するには、users:insert メソッドで POST リクエストを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
次のように置き換えます。
- DATABASE_VERSION: 使用するデータベース バージョン(例:
SQLSERVER_2019_STANDARD)。 - INSTANCE_NAME: 作成する Cloud SQL for SQL Server インスタンスの名前。
- REGION: インスタンスを配置するリージョン(例:
us-central1)。 - PASSWORD: インスタンスのパスワード。
- MACHINE_TYPE: インスタンスに使用するマシンタイプ(例:
db-n1-standard-8)。 - NETWORK: インスタンスが接続されるネットワークの名前(例:
projects/my-gcp-project-123/global/networks/my-production-vpc)。 - DOMAIN: 使用するドメイン名(
myaddomain.comなど)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが配置されるプロジェクト ID。
- SECRET_NAME: 使用するシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{
"databaseVersion":"DATABASE_VERSION",
"name":"INSTANCE_NAME",
"region":"REGION",
"rootPassword":"PASSWORD",
"settings":{
"tier":"MACHINE-TYPE",
"ipConfiguration":{
"privateNetwork":"NETWORK"
},
"activeDirectoryConfig":{
"domain":"DOMAIN"
"mode": "CUSTOMER_MANAGED_ACTIVE_DIRECTORY",
"organizational_unit":"OU=CLOUDOU,DC=DC1,DC=DC2"
"admin_credential_secret_name":"projects/PROJECT_ID/secrets/SECRET_NAME"
"dns_servers":"IP1,IP2"
}
}
}
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
"status": "RUNNING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"startTime": "2023-06-14T18:48:35.499Z",
"operationType": "CREATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_NAME",
"selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
REST v1beta4
CMAD を使用してインスタンスを作成するには、users:insert メソッドで POST リクエストを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
次のように置き換えます。
- DATABASE_VERSION: 使用するデータベース バージョン(例:
SQLSERVER_2019_STANDARD)。 - INSTANCE_NAME: 作成する Cloud SQL for SQL Server インスタンスの名前。
- REGION: インスタンスを配置するリージョン(例:
us-central1)。 - PASSWORD: インスタンスのパスワード。
- MACHINE_TYPE: インスタンスに使用するマシンタイプ(例:
db-n1-standard-8)。 - NETWORK: インスタンスが接続されるネットワークの名前(例:
projects/my-gcp-project-123/global/networks/my-production-vpc)。 - DOMAIN: 使用するドメイン名(
myaddomain.comなど)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが配置されるプロジェクト ID。
- SECRET_NAME: 使用するシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{
"databaseVersion":"DATABASE_VERSION",
"name":"INSTANCE_NAME",
"region":"REGION",
"rootPassword":"PASSWORD",
"settings":{
"tier":"MACHINE-TYPE",
"ipConfiguration":{
"privateNetwork":"NETWORK"
},
"activeDirectoryConfig":{
"domain":"DOMAIN"
"mode": "CUSTOMER_MANAGED_ACTIVE_DIRECTORY",
"organizational_unit":"OU=CLOUDOU,DC=DC1,DC=DC2"
"admin_credential_secret_name":"projects/PROJECT_ID/secrets/SECRET_NAME"
"dns_servers":"IP1,IP2"
}
}
}
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
"status": "RUNNING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"startTime": "2023-06-14T18:48:35.499Z",
"operationType": "CREATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_NAME",
"selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
Windows 認証を使用してインスタンスを更新する
ドメインの変更や追加を行うと、既存のインスタンスのドメインを更新できます。
インスタンスの更新に関する一般的な情報については、インスタンスの編集をご覧ください。
インスタンスが現在 CMAD ドメインに参加している場合、新しいドメインに参加する前に、元のドメインからインスタンスが除外されます。更新に失敗すると、インスタンスがどのドメインにも参加していない状態になる場合があります。
gcloud
既存のインスタンスを更新するコマンドの例を次に示します。このコマンドは、ドメインを追加または置換します。次のように --active-directory-domain=DOMAIN をコマンドに渡します。
gcloud sql instances patch INSTANCE_NAME \ --active-directory-domain=DOMAIN \ --active-directory-mode=CUSTOMER_MANAGED_ACTIVE_DIRECTORY \ --active-directory-organizational-unit="OU=CLOUDOU,DC=DOMAIN,DC=COM" \ --active-directory-secret-manager-key=projects/PROJECT_ID/secrets/SECRET_NAME \ --active-directory-dns-servers=IP1,IP2
次のように置き換えます。
- INSTANCE_NAME: 更新する Cloud SQL for SQL Server インスタンスの名前。
- DOMAIN: 使用するドメイン名(例:
myaddomain.com)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが存在するプロジェクト ID。
- SECRET_NAME: インスタンスに関連付けられたシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
REST v1
CMAD インスタンスを更新するには、users:insert メソッドで PATCH リクエストを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- DOMAIN: 使用するドメイン名(例:
myaddomain.com)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが存在するプロジェクト ID。
- SECRET_NAME: インスタンスに関連付けられたシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{
"settings":{
"activeDirectoryConfig":{
"domain":"DOMAIN"
"mode": "CUSTOMER_MANAGED_ACTIVE_DIRECTORY",
"organizational_unit":"OU=CLOUDOU,DC=DC1,DC=DC2"
"admin_credential_secret_name":"projects/PROJECT_ID/secrets/SECRET_NAME"
"dns_servers":"IP1,IP2"
}
}
}リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
REST v1beta4
CMAD インスタンスを更新するには、users:insert メソッドで PATCH リクエストを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- DOMAIN: 使用するドメイン名(例:
myaddomain.com)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが存在するプロジェクト ID。
- SECRET_NAME: インスタンスに関連付けられたシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{
"settings":{
"activeDirectoryConfig":{
"domain":"DOMAIN"
"mode": "CUSTOMER_MANAGED_ACTIVE_DIRECTORY",
"organizational_unit":"OU=CLOUDOU,DC=DC1,DC=DC2"
"admin_credential_secret_name":"projects/PROJECT_ID/secrets/SECRET_NAME"
"dns_servers":"IP1,IP2"
}
}
}リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
Managed Service for Microsoft Active Directory と CMAD 間の移行
Managed Microsoft AD との統合から CMAD との統合にインスタンスを移行するには、次の gcloud CLI コマンドを使用します。
gcloud sql instances patch INSTANCE_NAME \ --active-directory-domain=DOMAIN \ --active-directory-mode=CUSTOMER_MANAGED_ACTIVE_DIRECTORY \ --active-directory-organizational-unit="OU=CLOUDOU,DC=DOMAIN,DC=COM" \ --active-directory-secret-manager-key=projects/PROJECT_ID/secrets/SECRET_NAME \ --active-directory-dns-servers=IP1,IP2
次のように置き換えます。
- INSTANCE_NAME: 変更する Cloud SQL for SQL Server インスタンスの名前。
- DOMAIN: 使用するドメイン名(例:
myaddomain.com)。 - CUSTOMER_MANAGED_ACTIVE_DIRECTORY: ドメインのモードを示します。ドメインが Google によって作成され、所有されている場合は、
MANAGED_ACTIVE_DIRECTORYを入力します。ドメインがユーザーによって作成され、所有されている場合は、CUSTOMER_MANAGED_ACTIVE_DIRECTORYを入力します。 - CLOUD_OU: 使用する組織部門の名前。例:
CLOUDOU組織部門は必要な数だけ入力できます。 - DC1: 組織部門の識別名に使用される最初のドメイン コンポーネント。例:
DOMAINドメイン コンポーネントは必要な数だけ入力できます。 - DC2: 組織部門の識別名に使用される 2 番目のドメイン コンポーネント。例:
COM--active-directory-organizational-unitフラグの完全な値は、"OU=CLOUDOU,DC=DOMAIN,DC=COM"のようになります。ドメイン コンポーネントは必要なだけ入力できます。 - PROJECT_ID: インスタンスが存在するプロジェクト ID。
- SECRET_NAME: インスタンスに関連付けられたシークレット。
- IP1: 使用する最初の DNS サーバーの IP アドレス(例:
10.20.30.40)。必要な数の IP アドレスを入力できます。 - IP2: 使用する 2 番目の DNS サーバーの IP アドレス(例:
20.30.40.50)。必要な数の IP アドレスを入力できます。
ユーザーを使ってインスタンスに接続する
Cloud SQL for SQL Server の場合、デフォルト ユーザーは sqlserver です。
インスタンスを CMAD と統合した後、次のように 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
詳細については、Windows 認証を使用する Cloud SQL Auth Proxy を使うをご覧ください。
- プライベート IP 経由で接続する例を示します。
インスタンス IP アドレスを使用する場合は、IP ホスト名をサポートするように Kerberos クライアントを構成する必要があります。Cloud SQL では、信頼関係を介して接続されたドメインからの IP アドレスを使用したログインはサポートされていません。
Windows 認証を使用する Cloud SQL Auth Proxy を使う
CMAD 統合を使用する Cloud SQL Auth Proxy を使用できます。
始める前に、以下を確認してください。
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 フォールバックが原因である可能性があります。
NTLM は、認証用の Microsoft セキュリティ プロトコルのセットです。詳しくは、NTLM フォールバックの理由をご覧ください。
Windows クライアントの NTLM フォールバックの確認
Windows ターミナルで、NTLM フォールバックがエラーの原因となっていることを確認するには、次の操作を行います。
- 使用するオンプレミス認証情報でログインします。
"Run as..."コマンドは使用しないでください。 - コマンド プロンプトを開きます。
klist purgeを実行します。- SSMS から、Windows 認証を使用して SQL Server に接続してみます。
klistを実行して、返されたエラーに対して発行されたチケットがあるかどうかを確認します。- 該当するチケットがない場合、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
- Windows 認証で接続するには、次のコマンドを実行します。
/opt/mssql-tools/bin/sqlcmd -S
- klist コマンドを実行して、次の返信メッセージのチケットが発行されたかどうかを確認します。
MSSQLSvc/:1433 @ domain
- チケットが発行されていない場合、前述のエラーは NTLM フォールバックを引き起こす問題があることを示唆します。
NTLM フォールバックの理由
NTLM へのフォールバックはクライアントの構成ミスで、次の条件と関連する場合があります。
- デフォルトでは、ホスト名が IP アドレスの場合、Windows はホストの Kerberos 認証を試行しません。IP アドレスの Kerberos 認証を有効にするには、Microsoft のドキュメントに記載されている方法を試してください。
- 外部の信頼を介した Kerberos 認証は機能しません。代わりにフォレストの信頼関係を使用します。
- Kerberos 認証では、別のフォレスト内のサービスを検出するために、名前サフィックス ルーティングが必要になります。2 つのドメイン間に信頼関係を設定するで説明されている方法を試してください。
- サービスに SPN が登録されていない場合は、Kerberos 認証は機能しません。Windows 認証に接続するには、 Google Cloud コンソールから取得した FQDN または IP アドレスのみを使用します。
オンプレミス AD ユーザーの Windows ログインを作成する
オンプレミス ユーザーの Windows ログインを作成する方法については、CREATE LOGIN の手順をご覧ください。たとえば、次のようなコマンドを指定します。
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
Cloud SQL で CMAD を使用する際のヒント
- パブリック IP を持つインスタンスは、プライベート IP も持つ場合に限りサポートされます。インスタンスに対してプライベート IP を有効にする必要があります。その後、パブリック IP とプライベート IP の両方が使用可能である限り、インスタンスへの接続にどちらを使用するか選択できます。
- インスタンス(代替インスタンスを含む)を作成する前に、次の点を確認してください。
- 信頼関係を介して接続されたドメインからの Windows 認証が失敗する場合は、顧客管理ドメインのユーザーに対して Windows 認証が動作することを確認します。動作している場合は、次の手順を行います。
- DNS 名を使用したことを確認します。信頼関係を使用して接続されたドメインでは、IP アドレスはサポートされません。
- すべてのファイアウォール ポートの開放など、2 つのドメイン間の信頼関係の設定の手順を完了していることを確認します。
- 信頼を確認します。
- 信頼の方向により、信頼関係を介して接続されたドメインのユーザーが認証できることを確認します。
- ディレクトリ同期用にルーティング不可能なドメインを準備するの手順に沿って操作します。
- Cloud SQL for SQL Server を使用しないで信頼が機能することを確認します。
- Windows VM を作成します。
- CMAD ドメインに参加させます。
- たとえば、信頼関係を通じて接続されているドメインのユーザーとして、メモ帳を実行してみます。
- クライアント VM を再起動し、Windows 認証を再テストします。
- SQL Server ログインを作成しようとすると、次のエラーが表示されることがあります。
このエラーは、ドメイン ローカル グループがサポートされていないことが原因で発生する可能性があります。該当する場合は、グローバル グループまたはユニバーサル グループを代わりに使用します。
- SQL Server のクエリにより次のエラーが発生した場合は、信頼関係を介して接続されているドメインのユーザーには IP アドレスの使用がサポートされていないことに留意してください。
次の操作でこの問題を解決できる場合があります。
- マネージド ドメインからのユーザーの接続に IP アドレスを使用する場合は、Microsoft のドキュメントの手順に沿って操作してください。
- Cloud SQL for SQL Server への接続には、プロキシは利用せず、 Google Cloud コンソールで表示される名前と同じ DNS 名を常に使用してください。
インスタンスが最近更新されたかどうかにかかわらず、Windows 認証で継続的に問題が発生している場合は、ドメインへの参加を解除した後に再度参加させてください。この操作を行うには、更新手順を使用して、ドメインへの参加を解除した後に再度参加させてください。この操作を行っても、データベースにある既存の Windows 認証ユーザーまたはログインは削除されません。ただし、Windows 認証を削除すると、インスタンスは再起動されます。 - AD 診断ツールを使用して、 Google Cloud コンソールで顧客管理のドメインと Cloud SQL for SQL Server インスタンスの AD の設定の問題をトラブルシューティングします。Managed Microsoft AD に関連する手順をスキップします。
トラブルシューティング
次の表に、一般的なエラー メッセージとその対処方法を示します。
| エラー: | 次のような問題が考えられます... | 次のことを試します... |
|---|---|---|
Per-product, per-project Service Account (P4 SA) not found for project. |
サービス アカウント名が正しくありません。 | [サービス アカウント] ページで、正しいユーザー プロジェクトのサービス アカウントが作成されていることを確認します。 |
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-cmad for tips. |
CMAD ドメインで必要な更新を実施できませんでした。 | Windows 認証で問題が発生した場合は、CMAD ドメインへの参加を解除した後に再度参加させてください。この操作を行うには、更新手順を使用して、ドメインへの参加を解除した後に再度参加させてください。この操作を行っても、データベースにある既存の Windows 認証ユーザーまたはログインは削除されません。ただし、Windows 認証を削除すると、インスタンスは再起動されます。 |
This instance would need new network architecture to support Active
Directory. See https://cloud.google.com/sql/docs/sqlserver/configure-cmad." |
このインスタンスは新しいネットワーク アーキテクチャを使用していません。 | インスタンスを新しいネットワーク アーキテクチャにアップグレードします。 |
Admin credential secret name / Organizational unit / DNS Server
names is required or Invalid Admin credential secret name /
OrganizationalUnit / DNS Server names provided. |
管理者認証情報、組織部門、DNS サーバーは必須パラメータです。 | これらのパラメータを指定してリクエストを再試行します。 |
Integration failed due to insufficient permissions. The Service
Agent for this project must be granted the secretmanager.secrets.getIamPolicy
and secretmanager.secrets.setIamPolicy permissions on the provided admin
credential key in Secret Manager. |
このプロジェクトのサービス エージェントに必要な権限がありません。 | secretmanager.secrets.getIamPolicy 権限と secretmanager.secrets.setIamPolicy 権限を含むカスタムロールを作成し、このプロジェクトのサービス エージェントに割り当てます。詳細については、Secret Manager のロールと権限をご覧ください。 |