IBM Cloud Docs
VMware Solutions のワークロード・ドメイン

VMware Solutions のワークロード・ドメイン

顧客のワークロード仮想マシン(VM)は、顧客のBYOIP(Bring Your Own IP)アドレス空間を持つオーバーレイ仮想化ネットワークを使用している。 それらの IP 範囲を、IBM Cloud® for VMware Solutionsインフラストラクチャーの Active Directory™ (AD) ドメインではなく、お客様のワークロード AD ドメインに関連付けてください。 VMware Solutions インフラストラクチャーの AD ドメインには、vCenter Server インスタンスを管理するためのリソースとユーザー・アカウントのみを保持することをお勧めします。 ワークロード VM のリソースとユーザー・アカウントは、別のフォレストまたはドメインに保持されます。

vCenterNSX ManagerなどのインフラアプライアンスやVMは、IBM Cloudによって割り当てられたIPアドレス空間を持つアンダーレイネットワーク上に配置される。 構成しない限り、オーバーレイ・ネットワーク上のお客様のワークロード VM は、アンダーレイ・ネットワーク上の AD ドメイン・コントローラーに到達できません。 また、アンダーレイ・ネットワーク上のインフラストラクチャー・アプライアンスは、オーバーレイ・ネットワーク上のお客様のワークロード AD ドメイン・コントローラーに到達できません。

VMware Solutions のお客様は通常、VMware Solutions ワークロード・ドメインに以下のいずれかのモデルを使用します。

  • 新規のスタンドアロンの AD フォレストドメイン。
  • 既存のフォレストを信頼する新規 AD フォレスト。
  • フォレストを拡張し、新しいドメインを作成します。
  • AD サイトを使用したドメイン拡張モデル。
  • 拡張ドメイン。

新規のスタンドアロンの AD フォレストドメイン・モデル

このモデルは、信頼関係のないスタンドアロンのフォレスト・ドメインをデプロイします。 このデプロイメント・モデルでは、vCenter Server インスタンスでホストされるワークロードの新規フォレストおよび VMware Solutions ワークロード・ドメインが構成されます。 このドメインは、オンプレミスで実行されている既存の AD とは異なる別個のものです。 このモデルを選択する主な理由は、2 つのフォレスト/ドメイン間のアカウントとリソースを分離するためです。 このモデルでは、顧客はvCenterServerインスタンスでホストされるVMとして、最低2つのドメインコントローラをプロビジョニングする。 これらの VM はオーバーレイ・ネットワークに接続され、新規ドメイン・コントローラーは 1 次ドメイン・コントローラー役割を持ちます。 すべてのユーザー資格情報、サービス・アカウント、およびコンピューター・オブジェクトは、これらのドメイン・コントローラーでホストされるこの IBM Cloud for VMware Solutions ワークロード・ドメインにあります。 2つのADフォレスト間で共有されるものは何もないため、オンプレミスとIBM Cloud間のADネットワーク接続は必要ない。 IBM Cloud for VMware Solutions インフラストラクチャー・ドメインは、システム管理者のユーザー資格情報とサービス・アカウント、およびアンダーレイ接続されたインフラストラクチャー・コンポーネントのリソース・オブジェクトのためにのみ使用されます。 次の図は、このスタンドアロン AD フォレスト・モデルの Active Directory Domain Services トポロジーを示しています。

新しいスタンドアロン AD フォレスト・ドメイン図*
スタンドアロン AD フォレスト・ドメイン図
新しいスタンドアロン AD フォレスト・ドメイン図

「既存のフォレストを信頼する新規 AD フォレスト」モデル

このモデルは、オンプレミスの既存のフォレストを信頼する新規フォレスト・ドメインを、IBM Cloud にデプロイします。 VMware Solutions のワークロード・フォレストドメインで、vCenter Server インスタンスでホストする VM として実行するリソースに、オンプレミスの AD フォレストのユーザー・アカウントを使用する場合は、IBM Cloud で実行する AD フォレストドメインに対して、少なくとも片方向の信頼を確立する必要があります。 この展開モデルでは、IBM Cloud for VMware Solutionsワークロード・フォレスト・ドメインがリソース・オブジェクトが配置されるリソース・ドメインになり、オンプレミス・ドメインがユーザー・アカウント・ドメインになります。 オンプレミスと IBM Cloud の間に AD 接続が必要です。 このモデルでは、両方向の信頼は一般的にデプロイされず、通常、Active Directory の拡張には別のデプロイメント・パターンが使用されます。 IBM Cloud for VMware Solutions インフラストラクチャー・ドメインは、システム管理者のユーザー資格情報とサービス・アカウント、およびアンダーレイ接続されたインフラストラクチャー・コンポーネントのリソース・オブジェクトのためにのみ使用されます。 次の図は、この「信頼する新規フォレスト」モデルによる Active Directory Domain Services トポロジーを示しています。

既存のフォレスト
ADフォレスト
既存のフォレスト図にトラストを設定した新しいADフォレスト

「フォレストの拡張および新規ドメインの作成」モデル

このデプロイメント・モデルでは、オンプレミスの既存の AD フォレストを IBM Cloud まで拡張し、新しい子ドメインを作成します。 vCenter Server インスタンスでホストされる VM として、より多くのドメイン・コントローラーが実行されるようになります。 このデプロイメントは単純かつ柔軟で、以下の利点があります。

  • 追加の信頼関係をセットアップする必要がありません。
  • IBM Cloud のドメイン・コントローラーがアカウントとリソースの両方を処理します。
  • ネットワーク接続の問題に対して、より弾力的です。

このモデルでは、顧客はvCenterServerインスタンスでホストされるVMとして、最低2つのドメインコントローラをプロビジョニングする。 これらの VM はオーバーレイ・ネットワークに接続され、新規ドメイン・コントローラーは子ドメインの 1 次ドメイン・コントローラー役割を持ちます。 すべてのユーザー資格情報、サービス・アカウント、およびリソース・オブジェクトは、これらのドメイン・コントローラーでホストされるこの IBM Cloud for VMware Solutions ワークロードの子ドメインにあります。 しかし、親子関係には双方向の信頼関係が内在しているため、子ドメインのリソースオブジェクトは親ドメインのユーザーを使ってアクセスすることができ、親ドメインのリソースオブジェクトは子ドメインのユーザーを使ってアクセスすることができる。 ネットワーク接続は、ドメインコントローラー間のデータの初期および継続的なレプリケーションのために、データセンターとIBMの間に必要です。 次の図は、この「フォレストの拡張および新規の子ドメインの作成」モデルによる Active Directory Domain Services トポロジーを示しています。

Extend forest and create new domain diagram
Extend forest and create new domain diagram

「AD サイトを使用したドメイン拡張」モデル

このモデルでは、顧客はvCenterServerインスタンスでホストされるVMとして、最低2つのドメインコントローラをプロビジョニングする。 これらの VM はオーバーレイ・ネットワークに接続され、このネットワークはお客様の企業内の既存ドメイン・コントローラーに接続されます。 新規 AD サイトは、新規サイトのリンクとともに既存のフォレスト・ドメインで構成されます。 新規ドメイン・コントローラーが既存のドメインに接続され、新規 AD サイトに移動されます。 AD サイトにはオーバーレイ・サブネットが含まれます。 新規ドメイン・コントローラーは追加ドメイン・コントローラー役割を持ち、既存のドメイン・コントローラーは 1 次ドメイン・コントローラー役割を持ちます。 詳細については、Active Directory サイト トポロジーを理解するを参照してください。 次の図は、この「AD サイトを使用したドメイン拡張」モデルによる Active Directory Domain Services トポロジーを示しています。

AD サイトの
を使用してドメインを拡張する* AD サイトの
を使用してドメインを拡張する* AD サイトのダイアグラムを使用してドメインを拡張する

IBM Cloud for VMware Solutions インフラストラクチャー・ドメインは、システム管理者のユーザー資格情報とサービス・アカウント、およびアンダーレイ接続されたインフラストラクチャー・コンポーネントのリソース・オブジェクトのためにのみ使用されます。 必要に応じて、既存のフォレストは、信頼関係を使用して IBM Cloud for VMware Solutions フォレストにリンクできます。

拡張ドメイン・モデル

この拡張ドメイン・モデルは最も単純なモデルであり、 このモデルを使用すると、アプリケーションへの影響を最小限に抑えるハイブリッド・シナリオで IBM Cloud をシームレスにセットアップして使用することができます。 データ・センターと IBM の間にレイヤー 2 ネットワーク接続が必要であるため、VMware® HCX の理想的なモデルです。 このモデルでは、既存のドメイン・コントローラーを最初はオンプレミスに保持できます。それらのドメイン・コントローラーには、マイグレーションされた VM からレイヤー 2 の拡張ネットワークを使用してアクセスできます。 マイグレーションされる VM のドメインおよび DNS 構成は、マイグレーションのために変更する必要はありません。 必要に応じて、ドメイン・コントローラーは、変更なしで vCenter Server インスタンスにマイグレーションできます。

Active Directory ドメイン・サービスの複雑さによっては、フォレスト・ドメインを IBM Cloud に完全には移行していない場合に、レイヤー 2 のネットワーク拡張を削除すると、実行しなければならない Active Directory Domain Services タスクが増える可能性があります。 AD サイトを使用すると、オンプレミスと IBM Cloud 間のレイヤー 3 ネットワークを介したレプリケーションのトラフィックの制御に役立ちます。 前のセクションで説明されている、AD サイトを使用したドメイン拡張モデルを参照してください。 次の図は、この拡張ドメイン・モデルによる Active Directory Domain Services トポロジーを示しています。

拡張ドメイン図
ドメイン図
拡張ドメイン図

AD ドメインの再構築

ADドメインを再構築することは可能であるが、詳細は本文書の範囲外である。 以下の2種類のリストラを見直す:

  • フォレスト間再構築 - フォレスト間でオブジェクトをマイグレーションする場合は、ソース・ドメイン環境とターゲット・ドメイン環境の両方が存在するので、必要に応じて、マイグレーション中にソース環境にロールバックできます。
  • フォレスト内再構築 - フォレスト内でドメインを再構築する場合、マイグレーションされたアカウントはソース・ドメインに存在しなくなります。

詳細については、ADMTガイド -Active Directoryドメインの移行と再構築(ドキュメントダウンロード)を参照してください。

vCenter Server インスタンスでの AD のベスト・プラクティス・ガイダンス

vCenter Server インスタンスの AD に関する以下のガイダンスを確認してください。

  • サポートされるAD信頼の詳細については、VMware vCenterSingle Sign-onでサポートされるMicrosoftActive Directory信頼を参照してください。
  • vCenter を、すべての vCenter サービスおよびシステム管理者の認証用 ID ソースで有効にします。 この構成は、お客様がシステム管理者ユーザーを追加できるように、VMware Solutions の自動処理機能によって行われます。 VMware サーバー・インスタンスを管理するすべてのシステム管理者は、このドメインのメンバーであるユーザー・アカウントを持っています。
  • VMware vSphere® および NSX インフラストラクチャー・コンポーネントをサポートするシステム管理者の単一アクセス制御ポイントとして機能するドメインを作成します。 この構成は VMware Solutions の自動処理機能によって行われます。
  • 回復力のために、2 つのドメイン・コントローラーをデプロイします。 単一の VSI AD/DNS オプションを選択する場合は、2 つ目の Microsoft® Windows® VSI をプロビジョンして、ドメイン・コントローラーとして構成してください。
  • 既存のドメイン・ネームは変更しないでください。
  • 既存の AD セキュリティー・グループ ic4V-vCenter は変更しないでください。
  • 既存ユーザーの自動処理は変更しないでください。変更するとそのグループ・メンバーシップが変わります。
  • 既存のアドオンサービスアカウントを変更したり、グループメンバーシップを変更したりしないでください。
  • IBM Cloud for VMware Solutions ワークロード・ドメイン・コントローラーをデプロイする場合、アウトバウンドのインターネット・アクセスが提供される NAT ゲートウェイや他のデバイスへのルートを持たないサブネットにそれらをデプロイします。
  • すべてのドメイン・コントローラーで OS セキュリティー・パッチを最新状態に保持します。
  • NSX 分散ファイアウォールを使用して、ドメイン・コントローラーに許可されるポートおよびプロトコルを制限します。
  • リモート・デスクトップ・プロトコル (RDP) などのリモート管理アクセスは、信頼できるネットワークからの場合にのみ許可します。
  • VM の暗号化が必要かどうかを検討します。
  • vSphere クラスターに AD サーバーをデプロイするオプションを選択した場合は、サーバーがコンプライアンスと可用性を確保できるように、Microsoft Windows のライセンスとアクティベーションの情報を入力します。
  • NSX VPN を AD SSO と統合します (該当する場合)。
  • vSphere ESXi ホストを AD SSO と統合します。
  • 職務分離を強化するために、IBM Cloud for VMware Solutions インフラストラクチャー・ドメインの既存の AD セキュリティー・グループの構造を拡張することを検討してください。 この構造の例を以下の表に示します。 個々のユーザー・アカウントは相互に排他的であるため、これらのグループの複数に存在してはなりません。
Active Directoryセキュリティグループ
AD セキュリティー・グループ名 説明 SSO 役割マッピング
NSX エンタープライズ管理者 最大の特権セット。 すべての NSX 操作 (デプロイ、構成、アップグレード) やセキュリティー・ポリシーの管理など、NSX のすべてのコンポーネントの管理を担当する小規模なユーザー・グループが含まれます。 NSX マネージャーで「NSX エンタープライズ管理者」役割に割り当てます。
NSX 管理者 「NSX エンタープライズ管理者」グループのサブセット。 NSX 操作の許可のみを必要とするユーザー用。例えば、仮想アプライアンスをインストールしたり、ポート・グループを構成したりします。 NSX マネージャーで「NSX 管理者」役割に割り当てます。
NSX セキュリティー管理者 「NSX エンタープライズ管理者」グループのサブセット。 NSX セキュリティーの許可のみを必要とするユーザー用。例えば、データ・セキュリティー・ポリシーの定義、ポート・グループの作成、および NSX モジュールのレポートの作成を行います。 NSX Manager の「セキュリティ管理者」ロールに割り当てます。 最初はグローバル・スコープを使用します。
NSX 監査員 「NSX エンタープライズ管理者」グループのサブセット。 NSX 読み取り専用許可を必要とするユーザー用。 NSX Manager の「Auditor」ロールに割り当てます。 最初はグローバル・スコープを使用します。
ESX 管理者 このグループは、ESXi ホストが Active Directory に追加される場合に使用されます。 システム管理者が vSphere クライアントを使用して ESXi に直接接続したり、「root」の代わりに指定したアカウントを使用して ESXi コンソールに SSH で接続したりできるようにします。 ESXi ホストの詳細設定では、デフォルト・グループの名前は「ESX 管理者」です。 このグループ名は変更できます。 その名前を変更する場合、同じ名前の AD セキュリティー・グループも必ず作成してください。 このグループは、各 ESXi ホストの詳細設定 (ConfigurationSoftwareAdvanced SettingsConfig.HostAgent.plugins.hostsvc.esxAdministratorGroup) で定義する必要がありますが、vCenter アプリケーション・レベルの特別な役割や許可は必要ありません。