顧客管理の Active Directory（CMAD）の概要

MySQL | PostgreSQL | SQL Server

このページには、統合を開始する前に確認すべき情報が記載されています。以下の情報（制限事項を含む）を確認後、顧客管理の Active Directory を使用するをご覧ください。

Cloud SQL for SQL Server は、顧客管理の Microsoft Active Directory（顧客管理の AD（CMAD））と統合できます。

認証、認可などは CMAD を介して行うことができます。たとえば、CMAD ドメインにインスタンスを参加させると、AD ベースの ID で Windows 認証を使用してログインできるようになります。Cloud SQL for SQL Server を AD ドメインと統合すると、 Google Cloud をオンプレミスの AD ドメインと統合できるという利点もあります。

始める前に

インスタンスに Windows 認証のサポートを追加して、CMAD と統合できます。ただし、統合を行う前に、Google Cloud プロジェクトで次のことを行う必要があります。

認証が機能するには、Cloud SQL インスタンスと関連するすべての Active Directory ドメインのネットワーク接続を確立している必要があります。これらのドメインには、インスタンスが参加するプライマリドメインと、Cloud SQL for SQL Server にアクセスする必要があるユーザーを含む信頼できるドメインまたは子ドメインが含まれます。これを行うには、Cloud SQL インスタンスとすべてのドメインコントローラの間で、53、88、135、389、445、464、3268、3269、49152～65535 のポート（TCP と UDP の両方）が開いていることを確認してください。
関連するすべての統合オブジェクトを保存するために、組織部門（OU）を作成する必要があります。
- この OU 内には、次の権限を持つ管理者アカウントも必要です。
  - コンピュータオブジェクトの作成
  - コンピュータオブジェクトの削除
  - ユーザーオブジェクトの作成
  - ユーザーオブジェクトの削除
  - すべてのプロパティの書き込み
  - パスワードの再設定
  - 読み取りロックアウト時間、書き込みロックアウト時間
- また、この管理者アカウントに DNS レコードを管理する権限を付与することをおすすめします（たとえば、DnsAdmins グループに追加するなど）。
  これらの権限を付与しなくても、統合は成功します。ただし、インスタンスに接続するには、ユーザーを使用してインスタンスに接続するで説明されているように、必要な DNS レコードを手動で作成する必要があります。
  
  別の方法として、インスタンスの IP アドレスを使用して接続することもできますが、これには制限事項があり、信頼できるドメインからの接続では機能しません。
次の JSON 形式を使用して、管理者の認証情報を Secret Manager のシークレットに保存する必要があります。
```
    {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }
    
```
次のように置き換えます。
- VALID_AFTER_UTC_VALUE_1: 使用する 1 番目の UTC 値（YYYY-MM-DDThh:mm:ssZ 形式）。例: 2099-07-01T10:30:00Z。
- ADMINISTRATOR_LOGIN_VALUE_1: 使用する 1 番目の管理者ログイン（例: myadmin）。値にドメイン名を含めないでください。myadmin@my-domain-name.com のようなエントリはサポートされていません。
- ADMINISTRATOR_PASSWORD_VALUE_1: 管理者のパスワード。
- VALID_AFTER_UTC_VALUE_2: 使用する 2 番目の UTC 値（YYYY-MM-DDThh:mm:ssZ 形式）。例: 2099-07-01T10:30:00Z。
- ADMINISTRATOR_LOGIN_VALUE_2: 使用する 2 番目の管理者のログイン（例: myadmin2）。同様に、値にドメイン名を含めないでください。myadmin2@my-domain-name.com のようなエントリはサポートされていません。
- ADMINISTRATOR_PASSWORD_VALUE_2: 2 番目の管理者のパスワード。
このファイルには、伝播の遅延に関する問題を軽減したり、事前の計画されたローテーションに対応したりするために、複数の認証情報エントリを含めることができます。

validAfterUTC フィールドは省略可能です。指定しない場合、認証情報は常に有効であると見なされます。これらの認証情報は Secret Manager で永続的に利用できるようにし、認証情報をローテーションする場合は自動化を使用してパスワードを更新することをおすすめします。

シークレットはインスタンスの作成後に削除できますが、以降のオペレーション（クローン作成やリードレプリカの追加など）では、新しいインスタンスがドメインに参加しなくなることに注意してください。

また、元のインスタンスを削除すると、CMAD 内でコンピュータアカウントなどのオブジェクトが孤立します。
顧客管理の Active Directory の DNS サーバー（通常はドメインコントローラ）の IP アドレスのリストを用意します。これらのサーバーには静的 IP アドレスを使用することをおすすめします。
プロダクトごと、プロジェクトごとのサービスアカウントを割り当てます。

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

必要な権限を持つサービスアカウントを作成するには、次のことを確認します。

Cloud SQL Admin API を有効にする必要があります。
次の権限が必要です。
CMAD と統合する各プロジェクトに、プロダクトごと、プロジェクトごとのサービスアカウントが必要です。プロジェクトレベルでアカウントを作成するには、gcloud CLI を使用します。プロダクトごと、プロジェクトごとのサービスアカウントには、前の手順で作成したシークレットに対する secretmanager.secrets.getIamPolicy 権限と secretmanager.secrets.setIamPolicy 権限を付与する必要があります。詳細については、Secret Manager の権限をご覧ください。

必要な権限を持つカスタムロールを作成することをおすすめします。

gcloud CLI でサービスアカウントを作成するには、次のコマンドを実行します。

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

このコマンドは、次の形式でサービスアカウント名を返します。

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com

サービスアカウント名の例を次に示します。

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

統合に必要な権限を付与するには、次のコマンドを実行します。

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

さらに、次のコマンドを実行します。

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

詳細については、gcloud beta services identity create をご覧ください。

CMAD との統合に関するベストプラクティス

CMAD と統合する際は、次の手順を完了することをおすすめします。

統合の前提条件

Active Directory 診断ツールを使用して、 Google Cloud コンソールでオンプレミスドメインと Cloud SQL for SQL Server インスタンスの AD の設定に関する問題をトラブルシューティングします。Managed Service for Microsoft Active Directory に関連する手順はスキップします。

CMAD との統合のトポロジ

Cloud SQL for SQL Server は、ドメインローカルグループをサポートしていません。ただし、次の代替策を利用できます。

グローバルグループまたは個々のユーザーのログインを SQL Server に直接追加する。
すべてのグループとユーザーが同じフォレストに属している場合は、ユニバーサルグループを使用する。

Cloud SQL for SQL Server は、ログインとしてドメインローカルグループをサポートしていません。ドメインユーザーに権限を付与するには、このセクションで説明するように、グローバルグループまたはユニバーサルグループを使用する必要があります。

オプション 1: SQL Server へのログインとしてユーザーアカウントとグループを追加する

複数のドメインが複数のフォレストにあり、複数のグローバルグループが存在する場合は、すべての個々のユーザーアカウント、グローバルグループとユニバーサルグループを SQL Server へのログインとして直接追加できます。次の図にオプション 1 の例を示します。

CMAD トポロジ、オプション 1。

オプション 2: いずれかのドメインでユニバーサルグループを定義する

ドメインが同じフォレストにある場合は、いずれかのドメインでユニバーサルグループを定義できます。次に、すべての個々のユーザーアカウント、グローバルグループとユニバーサルグループをその定義済みのユニバーサルグループの子として追加し、定義済みのユニバーサルグループを SQL Server ログインとして追加します。次の図にオプション 2 の例を示します。

CMAD トポロジ、オプション 2。

制限事項と代替策

CMAD と統合する場合は、次の制限事項が適用されます。

プライベート接続に Private Service Connect（PSC）を使用する Cloud SQL for SQL Server インスタンスはサポートされていません。代わりにプライベートサービスアクセス（PSA）を使用してください。
ドメインローカルグループはサポートされていませんが、グローバルグループまたは個々のユーザーログインを SQL Server で直接追加できます。または、すべてのグループとユーザーが同じフォレストに属している場合は、ユニバーサルグループを使用できます。
信頼できるドメインが他にもあり、そこからユーザー名を使用して SQL Server インスタンスにアクセスする場合は、双方向の信頼関係を介して接続する必要があります。一方向の信頼関係と外部の信頼関係はサポートされていません。
通常、 Google Cloud コンソールで作成された新規ユーザーには CustomerDbRootRole ロールが割り当てられます。このロールには、SQLAgentUserRole の SQL Server エージェントの固定データベースロールが含まれます。ただし、CMAD ユーザーなど、SQL Server で直接作成されたユーザーには、このロールを付与することや、SQL Server エージェントを使用することはできません。これは、このロールを付与する必要がある MSDB データベースが保護されているためです。
SQL Server で完全修飾ドメイン名（FQDN）はサポートされていません。そのため、SQL Server ログインを作成するときは、FQDN ではなくドメイン名（短縮名）を使用します。たとえば、ドメイン名が ad.mydomain.com の場合、ad.mydomain.com\user ではなく ad\user の SQL Server ログインを作成します。
SQL Server インスタンスにアクセスするには、常に FQDN を使用します。たとえば、private.myinstance.us-central1.myproject.cloudsql.mydomain.com のような FQDN を使用できます。NetBIOS 名はサポートされていません。DNS サフィックスを省略した場合は短縮名も使用できません。
Active Directory ユーザーとグループに基づく SQL Server ログインは、 Google Cloud コンソールで管理できません。
Windows 認証は外部の信頼関係では機能しません。次のようなエラーが返されます。
```
  "The target principal name is incorrect. Cannot generate SSPI context."
  
```
また、Microsoft の推奨事項に関連して、Kerberos 認証には外部の信頼関係ではなくフォレスト間の信頼関係を使用してください。
常に最新バージョンのシークレットが使用されます。シークレットは有効である必要があり、破棄できません。

Active Directory エンドポイントと TLS 接続

Windows 認証を使用していて、サーバー証明書を信頼せずに TLS 接続を確立する場合は、インスタンスで Windows 認証を有効にした後に証明書をローテーションする必要があります。

接続に失敗し、証明書のいずれかが 2025 年 3 月 15 日より前に作成された場合は、サーバー証明書を再度ローテーションして、接続を再試行する必要があります。

統合でサポートされていない機能

CMAD と統合する場合、次の機能はサポートされていません。

ドメインローカルグループ。
NTLM 認証。
信頼関係を介して接続されたドメインの IP アドレスを使用したログイン。
長い（63 文字を超える）名前のインスタンス。

モニタリング

次の指標を使用して、CMAD のステータスと健全性をモニタリングできます。

cloudsql.googleapis.com/database/active_directory/domain_reachable

この指標は、Cloud SQL インスタンスから CMAD に到達できるかどうかを報告します。ネットワークに関する問題のトラブルシューティングに役立ちます。

cloudsql.googleapis.com/database/active_directory/instance_available