このセクションでは、テナントの FQDN を介してテナントにアクセスする方法や、証明書と DNS の要件を満たすとともにマルチテナントを有効にすることの重要性について説明します。

マルチテナントの有効化

現在、マスター テナントはプライマリ テナントと呼ばれています。Day 0 の時点で、特別な設定が不要の VMware Identity Manager には使用可能なプライマリ テナントがすでに含まれていますが、これは最小限の構成で保持されるものであり、プライマリ テナントの下にテナントをさらに作成することはできません。マルチテナントを有効にするには、VMware Identity Manager で一連の構成と API 呼び出しを実行する必要があります。マルチテナントを有効にする場合は、プライマリ テナント用に作成されたエイリアス名が必要になります。マルチテナントの有効化の詳細については、マルチテナントの有効化を参照してください。

たとえば、FQDN が「idm1.vmwlab.local」の VMware Identity Manager には、名前が「idm1」のプライマリ テナントがすでにある可能性があります。マルチテナントを有効にする前に、プライマリのエイリアスを作成する必要があります。たとえば、「master-tenant」は、プライマリ テナントが参照されているすべての場所で同じエイリアス名を設定して使用します。

テナントの FQDN

デフォルトでは、VMware Identity Manager で作成されたテナントにアクセスするには、テナント URL(VMware Identity Manager サーバにマップされた単なる FQDN)を使用します。各テナントには独自のテナント FQDN があります。たとえば、ホスト名が idm1.vmwlab.local の単一のノード VMware Identity Manager で、プライマリ テナント名 (idm1) とプライマリ テナント エイリアス (master-tenant) を使用する場合、プライマリ テナントには FQDN の master-tenant.vmwlab.local を使用してアクセスする必要があります。新しいテナント (tenant1) が作成されている場合、このテナントにアクセスするには tenant1.vmwlab.local を使用する必要があります。

すべてのテナントには専用の FQDN が必要です。VMware Identity Manager でテナントを作成するには、テナントの FQDN を VMware Identity Manager サーバの IP アドレスにマップする A タイプの DNS レコードが必要です。クラスタ化された VMware Identity Manager 展開の場合は、すべてのテナントの FQDN に、VMware Identity Manager ロード バランサの IP アドレスにマップする A タイプ レコードを設定する必要があります。

vRealize Automation にも同じモデルが適用されます。vRealize Automation にテナントが関連付けられている場合は、vRealize Automation テナントの FQDN を使用して vRealize Automation テナントにアクセスする必要があります。たとえば、FQDN が idm1.vmwlab.local で、「tenant1」というテナントが含まれている VMware Identity Manager にアクセスするには、tenant1.vmwlab.local を使用するか、この VMware Identity Manager と統合されていて、「tenant1」に関連付けられている vRealize Automation 8.1 の vra1.vmwlab.local を使用します。上記のとおり、vRealize Automation テナントと VMware Identity Manager テナントは 1:1 でマップされるため、プライマリ テナント vRealize Automation には引き続き vra1.vmwlab.local および「tenant1」を使用してアクセスできます。vRealize Automation には tenant1.vra1.vmwlab.local 使用してアクセスする必要があります。

注: VMware Identity Manager の FQDN と vRealize Automation テナントの FQDN は異なります。 VMware Identity Manager インスタンスの場合、テナントの FQDN 形式は、テナント名 (tenant1) の後に VMware Identity Manager のドメイン名 (vmwlab.local) が続いたものになります。たとえば、 tenant1.vmwlab.local です。これは、テナント名の後にドメインが続く形式であるため、クラスタ化された VMware Identity Manager の場合も同じです。 vRealize Automation の場合、 vRealize Automation テナントの FQDN 形式はテナント名 (tenant1) の後に vRealize Automation サーバの FQDN (vra1.vmwlab.local) が続いたものになります( tenant1.vra1.vmwlab.local など)。クラスタ化された vRealize Automation がロード バランサ vra-lb.vmwlab.local の背後に配置されている場合、tenant 1 には tenant1.vra-lb.vmwlab.local 経由でアクセスする必要があります。

VMware Identity Manager と同様に、vRealize Automation テナントの FQDN にも DNS マッピングが必要です。ただし、vRealize Automation の場合は、vRealize Automation テナント の FQDN を vRealize Automation サーバの FQDN にマップする CNAME タイプのレコードを使用する必要があります。クラスタ化された vRealize Automation 展開の場合は、すべての vRealize Automation テナントの FQDN に、vRealize Automation ロード バランサの FQDN を指す CNAME タイプの DNS レコードを設定する必要があります。

テナントを有効にするには、必須の前提条件となる DNS マッピングとは別に、証明書も必須です。VMware Identity Manager サーバと vRealize Automation サーバ、およびそのロード バランサ(展開のアーキテクチャに応じて)には、必須のテナント FQDN をすべて保持する対応する証明書が必要です。

単一ノード セットアップでのテナント FQDN
  • VMware Identity Manager ノード:idm1.vmwlab.local

    vRealize Automation ノード:vra1.vmwlab.local

    プライマリ テナントのエイリアス名︰master-tenant

    テナント:tenant-1、tenant-2

テナント名 VMware Identity Manager テナントの FQDN vRealize Automation テナントの FQDN
master-tenant https://master-tenant.vmwlab.local https://vra1.vmwlab.local
tenant-1 https://tenant-1.vmwlab.local https://tenant-1.vra1.vmwlab.local
tenant-2 https://tenant-2.vmwlab.local https://tenant-2.vra1.vmwlab.local
クラスタ化されたセットアップでのテナント FQDN
  • VMware Identity Manager ロード バランサ:idm-lb.vmwlab.local

    VMware Identity Manager ノード:idm1.vmwlab.local, idm2.vmwlab.localidm3.vmwlab.local

    vRealize Automation ロード バランサ:vra-lb.vmwlab.local

    vRealize Automation ノード:vra1.vmwlab.local, vra2.vmwlab.localvra3.vmwlab.local

    プライマリ テナントのエイリアス名︰master-tenant

    テナント:tenant-1、tenant-2

テナント名 VMware Identity Manager テナントの FQDN vRealize Automation テナントの FQDN
master-tenant https://master-tenant.vmwlab.local https:// vra-lb.vmwlab.local
tenant-1 https://tenant-1.vmwlab.local https://tenant-1.vra-lb.vmwlab.local
tenant-2 https://tenant-2.vmwlab.local https://tenant-2.vra-lb.vmwlab.local
注: マルチテナントを有効にした後に VMware Identity Manager にアクセスするには、テナントの FQDN を使用する必要があります。古い FQDN とホスト名(idm1.vmwlab.local、idm2.vmwlab.local、idm3.vmwlab.local、および idm-lb.vmwlab.local)は無効になります。

必須の証明書の要件

VMware Identity Manager および vRealize Automation の展開タイプに応じて、対応するサーバ証明書自体にすべてのテナントの FQDN を含める必要があります。テナントごとに独自のテナント FQDN が形成されるため( VMware Identity Manager テナントの FQDN と vRealize Automation テナントの FQDN)、作成される各テナントのテナント FQDN を VMware Identity Manager および vRealize Automation の両方の証明書の一部として追加する必要があります。 VMware Identity Manager でマルチテナントを有効にする場合は、プライマリ テナントが新しいエイリアス名を取得し、プライマリ テナントの FQDN が変更されたときに、 VMware Identity Manager 証明書も更新する必要があります。
注:
  • VMware Identity Manager の証明書を変更してマルチテナントの有効化やテナント作成の有効化を行うと、サービスが停止し、ダウンタイムが発生します。VMware Identity Manager の証明書が変更されると、サービスのダウンタイムが発生します。認証のために VMware Identity Manager と統合された製品またはサービスは、ダウンタイム中に VMware Identity Manager 認証ログインを使用できません。また、VMware Identity Manager の証明書を変更するには、すべての製品またはサービスを再信頼する必要があり、これによっても製品のダウンタイムが発生します。
  • 作成されて vRealize Automation に関連付けられた新しいテナントごとに vRealize Automation 証明書を変更する必要もあり、これによって vRealize Automation のサービスにダウンタイムが発生します。
  • vRealize AutomationVMware Identity Manager、および VMware Identity Manager と統合された他の製品またはサービスでサービスのダウンタイムが発生するのを回避するには、通常、ワイルドカード証明書を使用することをお勧めします。新しいテナントの場合、VMware Identity Manager 証明書または vRealize Automation 証明書を変更すると、vRealize Automation にダウンタイムが生じます。
  • ワイルドカード証明書を使用しない場合は、必要なすべての証明書にテナント FQDN ごとに特定の SAN エントリが作成されます。
  • vRealize Suite Lifecycle Manager Locker サービスは、VMware Identity Manager および vRealize Automation サーバ ノードで証明書を管理する際に役立ちます。vRealize Suite Lifecycle Manager を使用すると、VMware Identity Manager 証明書を置換するときに、すべての製品で VMware Identity Manager 証明書の再信頼が自動的に実行されます。
  • vRealize Suite Lifecycle Manager 外部の製品またはサービスは手動で処理します。Locker サービスではロード バランサ証明書の更新は処理されません。ユーザーが手動で処理する必要があります。ロード バランサの証明書が変更されるたびに、同じ証明書を製品で再信頼する必要があります。
    • VMware Identity Manager の場合、vRealize Suite Lifecycle ManagerVMware Identity Manager 証明書の更新操作または置換操作を行うと、VMware Identity Manager サーバの証明書が更新される前に、VMware Identity Manager ロード バランサの証明書が確実に再信頼されます。そのため、最初に VMware Identity Manager ロード バランサの証明書を手動で変更してから、vRealize Suite Lifecycle Manager Locker サービス経由で VMware Identity Manager 証明書の更新または置換を行います。
    • vRealize Automation 8.x では、SSL が vRealize Automation ロード バランサで終了している場合に、ロード バランサの証明書が手動で変更されたときは、vRealize Automation 8.x 製品カードの下にある [ロード バランサの再信頼] をクリックして、vRealize Automation でロードバランサの証明書を再信頼する必要があります。詳細については、vRealize Suite Lifecycle Manager のその他の製品でのインストール後の作業を参照してください。

必須の DNS 要件

単一ノードの VMware Identity Manager の場合は、VMware Identity Manager サーバの IP アドレスに対してテナントの FQDN を強調表示する A タイプの DNS レコードが必要です。クラスタ化された VMware Identity Manager の場合は、テナント FQDN が VMware Identity Manager ロード バランサの IP アドレスを指すように A タイプの DNS レコードを指定する必要があります。

vRealize Automation で単一ノードを使用する場合は、vRealize Automation テナントの FQDN が vRealize Automation サーバの FQDN を指すように CNAME タイプの DNS レコードを指定する必要があります。クラスタ化された vRealize Automation の場合は、vRealize Automation テナントの FQDN が vRealize Automation ロード バランサの FQDN を指すように CNAM タイプの FQDN DNS レコードを指定する必要があります。

マルチテナントの要件

図 1. 単一ノードの VMware Identity Manager と vRealize Automation
図 2. VMware Identity Manager と vRealize Automation の両方のクラスタ
図 3. vIDM(単一)および vRA(クラスタ化)
図 4. VMware ID(クラスタ化)と vRealize Automation(単一)