このページは Cloud Translation API によって翻訳されました。

顧客管理の 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 ドメインと統合すると、オンプレミスの AD ドメインとの Google Cloud 統合という利点もあります。

始める前に

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

認証が機能するには、Cloud SQL インスタンスが関連するすべての Active Directory ドメインにネットワーク接続されている必要があります。これには、インスタンスが参加するプライマリドメインと、Cloud SQL for SQL Server にアクセスする必要があるユーザーを含む信頼できるドメインまたは子ドメインが含まれます。これを有効にするには、Cloud SQL インスタンスとすべてのドメインコントローラの間で、次のポート（TCP と UDP の両方）が開いていることを確認してください。53、88、135、389、445、464、3268、3269、49152～65535。
関連するすべての統合オブジェクトを保存するには、組織部門（OU）を作成する必要があります。
- この OU 内には、次の権限を持つ管理者アカウントも必要です。
  - コンピュータオブジェクトを作成する
  - コンピュータオブジェクトを削除する
  - User オブジェクトを作成する
  - ユーザーオブジェクトを削除する
  - すべてのプロパティを書き込む
  - パスワードを再設定
  - 読み取りロックアウト時間、書き込みロックアウト時間
- また、この管理者アカウントに 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: 使用する最初の UTC 値（YYYY-MM-DDThh:mm:ssZ 形式）。たとえば、2099-07-01T10:30:00Z などです。
- ADMINISTRATOR_LOGIN_VALUE_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 ロールが割り当てられます。このロールには、次の SQL Server エージェントの固定データベースロール（SQLAgentUserRole）が含まれます。ただし、CMAD ユーザーなど、SQL Server で直接作成されたユーザーは、このロールを付与する、または SQL Server Agent を使用することはできません。これは、このロールを付与する必要がある MSDB データベースが保護されているためです。
完全修飾ドメイン名（FQDN）は SQL Server でサポートされていません。そのため、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