最初にゲートウェイなしで、または 1 つのタイプのゲートウェイのみを使用して Horizon Cloud ポッドを Microsoft Azure にデプロイした場合、[ポッドの編集] ワークフローを使用して、後からゲートウェイ構成をポッドに追加できます。このワークフローは、ポッドの詳細ページから起動します。

ヒント: コンソールは動的です。ポッドの現在の構成や環境全体の構成に基づいて、意味のある適切なワークフローおよびトグルやフィールドのみが、ユーザー インターフェイスで利用できるようになります。

ユーザーの Horizon Cloud on Microsoft Azure 環境に記載されているように、ポッドには内部/外部のゲートウェイ構成のどちらか 1 つまたは両方を設定できます。このワークフローを使用して、ポッドにまだないタイプを追加できます。ポッドを編集してゲートウェイ構成を追加するのと同時に、そのゲートウェイに対して 2 要素認証設定を指定することもできます。

重要： これらの手順を使用してポッドを変更するときは、次の点に注意してください。
  • 外部ゲートウェイ構成を最初に設定した後は、外部ゲートウェイのロード バランサの IP 設定を変更できないことに注意してください。外部ゲートウェイ構成を追加するときに、ゲートウェイのロード バランサ用にパブリック IP アドレスではなくプライベート IP アドレスを使用するように選択できます。デフォルトでは、パブリック IP アドレスを使用します。
  • テナントが Universal Broker を使用するように構成され、ブローカ設定で 2 要素認証が有効になっている場合、フリート内のすべてのポッドの外部ゲートウェイで同じ 2 要素認証タイプを設定する必要があります。
  • システムがポッドの構成を変更している場合、変更が完了するまでは次の制限が適用されます。
    • ポッドでは管理タスクを実行できません。
    • ポッドによってサービスが提供される、デスクトップまたはリモート アプリケーションにセッションを接続していないエンド ユーザーは、接続を試みると失敗します。
    • ポッドによってサービスが提供されるセッションを接続しているエンド ユーザーに対して、それらのアクティブなセッションが切断されることになります。データの損失は発生しません。構成の変更が完了した後に、これらのユーザーは再接続できます。

前提条件

注： ポッドの高可用性が有効になっていて、ポッド マネージャ仮想マシンの 1 つがオフラインの場合、システムによってポッドへのゲートウェイの追加が妨げられます。 [保存して終了] をクリックすると、このメッセージが表示されます。ゲートウェイを追加するには、Microsoft Azure ポータルを使用してオフラインのポッド マネージャ仮想マシンをオンラインに戻す必要があります。

Microsoft Azure の既存のポッドにゲートウェイ構成を追加するときに、[ポッドの編集] ウィザードのフィールドの入力を完了するには、Unified Access Gateway 構成の前提条件に記載されている情報を入力する必要があります。ゲートウェイを追加しているときと同時に 2 要素認証の設定も行う場合は、2 要素認証構成でデプロイする際の前提条件に記載されている情報を入力する必要があります。外部ゲートウェイ構成を追加し、独自のサブスクリプションを使用する場合はそのサブスクリプション情報も必要です。追加するゲートウェイに使用する VNet が VNet の要件を満たしていることを確認します。これらの VNet 要件については、Microsoft Azure で必要な仮想ネットワークを構成するを参照してください。

重要： 証明書チェーン内のすべての証明書が有効期限内である必要があります。 Unified Access Gateway 仮想マシンでは、任意の中間証明書を含む、チェーン内のすべての証明書が有効期限内である必要があります。チェーン内のいずれかの証明書が期限切れの場合、後で Unified Access Gateway 構成に証明書がアップロードされる際に予期しない障害が発生する可能性があります。

手順

  1. コンソールで [設定] > [キャパシティ] に移動し、ポッドの名前をクリックしてその詳細ページを開きます。
  2. ポッドの詳細ページで、[編集] をクリックします。
  3. [サブスクリプション] の手順で、外部ゲートウェイ構成を追加し、ポッドとは別のサブスクリプションを使用する場合は、[外部ゲートウェイに別のサブスクリプションを使用] を有効にして、サブスクリプション情報を入力します。
  4. [ゲートウェイ設定] の手順に到達するまで [次へ] をクリックします。
    この手順には、外部ゲートウェイ構成のセクションと、内部ゲートウェイ構成のセクションが含まれています。ユーザー インターフェイスには、ポッドの現在の構成と、すでに存在するゲートウェイ設定が反映されます。
  5. 外部ゲートウェイを追加するには、[外部 UAG を有効にしますか? ] トグルをオンに切り替えて、[外部 UAG] セクションのフィールドに入力します。
    オプション 説明
    [外部ゲートウェイを有効にしますか?] ポッドに外部ゲートウェイ構成があるかどうかを制御します。外部構成を使用すると、企業のネットワークの外部にいるユーザーがデスクトップおよびアプリケーションにアクセスできるようになります。ポッドには、このアクセスを提供する Microsoft Azure ロード バランサ リソースと Unified Access Gateway インスタンスが含まれています。
    注： デフォルトの有効になっている設定にしておくことをお勧めします。

    このトグルをオフにすると、クライアントは、コネクタ アプライアンスがポッド マネージャに直接統合された Workspace ONE Access を介して接続するか、クライアントがポッド マネージャのロード バランサに直接接続するか、内部ゲートウェイ構成を介して接続する必要があります。これらのうち、クライアントがポッドに統合された Workspace ONE Access を介して接続する、またはクライアントがロード バランサに直接接続する最初の 2 つのシナリオでは、デプロイ後にいくつかの手順が必要になります。これらのシナリオでは、ポッドがデプロイされた後、ポッド マネージャ仮想マシンで SSL 証明書を直接構成するの手順に従って、SSL 証明書をポッド マネージャ仮想マシンにアップロードします。

    [FQDN] ourOrg.example.com のような、必要な完全修飾ドメイン名 (FQDN) を入力します。これは、ポッド デプロイヤがゲートウェイの Unified Access Gateway インスタンスの構成で指定するドメイン名です。このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。

    Horizon Cloud は、外部ゲートウェイ構成に指定されたこの FQDN がパブリックに解決可能であることを想定します。[パブリック IP アドレスを有効にしますか? ] トグルをオフに切り替えてファイアウォールまたは NAT セットアップから IP アドレスを指定した場合、ファイアウォール内または NAT セットアップ内の IP アドレスにこの FQDN が割り当てられていることを確認する必要があります。この FQDN は、ゲートウェイへの PCoIP 接続に使用されます。

    重要： この FQDN には、アンダー スコアを含めることはできません。このリリースでは、FQDN にアンダー スコアが含まれていると、 Unified Access Gateway インスタンスへの接続が失敗します。
    [DNS アドレス] オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力します。

    Unified Access Gateway インスタンスのデプロイ先となる VNet トポロジの外部にある 2 要素認証サーバで 2 要素認証を使用するようにこの外部 Unified Access Gateway 構成を構成する場合は、その認証サーバのホスト名を解決できる DNS サーバのアドレスを指定します。たとえば、2 要素認証サーバがオンプレミスにある場合は、その認証サーバの名前を解決できる DNS サーバのアドレスを入力します。

    デプロイの前提条件で説明されているように、Horizon Cloud on Microsoft Azure のデプロイに使用される VNet トポロジは、Unified Access Gateway インスタンスのデプロイ中に、また、その進行中の操作のために、外部の名前解決を提供する DNS サーバと通信できる必要があります。

    デフォルトでは、インスタンスがデプロイされる VNet で構成されている DNS サーバが使用されます。

    [DNS アドレス] にアドレスを指定すると、デプロイされた Unified Access Gateway インスタンスは、VNet の構成の DNS サーバ情報に加えてこれらのアドレスを使用します。

    [ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンド ユーザー アクセス用のネットワークのルーティングを解決するために使用する、追加のゲートウェイへのカスタム ルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証サーバとの通信などにネットワーク ルーティングを解決できるようにするために使用されます。

    このポッドをオンプレミスの認証サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway インスタンスがそのサーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの認証サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルト ルートのゲートウェイ アドレスをカスタム ルートとして入力することになります。この Horizon Cloud on Microsoft Azure デプロイで使用している Express ルートまたは VPN 構成からデフォルト ルートのゲートウェイ アドレスを取得します。

    形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタム ルートを指定します（例：192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2）。

    [ポッドの NTP サーバの継承] このトグルはデフォルトで有効になっており、Unified Access Gateway インスタンスは、ポッド マネージャ インスタンスに指定されているのと同じ NTP サーバを使用します。このトグルを有効にしておくことを強くお勧めします。

    ポッド マネージャ インスタンス、Unified Access Gateway インスタンス、および Active Directory サーバに同じ NTP サーバを使用することがベスト プラクティスです。タイム スキューは、これらのインスタンスが異なる NTP サーバを使用する場合に発生する可能性があります。このようなタイム スキューにより、後でゲートウェイがデスクトップおよびアプリケーションに対してエンド ユーザー セッションを認証しようとしたときに、エラーが発生する可能性があります。

    このトグルを有効にして、外部ゲートウェイをポッドの VNet とは別の専用の VNet にデプロイする場合は、ポッド マネージャ インスタンスに指定された NTP サーバに、外部ゲートウェイのデプロイ用に選択した仮想ネットワークからアクセスできることを確認します。
    [仮想マシン モデル] Unified Access Gateway インスタンスに使用するモデルを選択します。このポッドに指定した Microsoft Azure サブスクリプションが、選択したモデルの 2 台の仮想マシンのキャパシティを確実に満たすようにする必要があります。
    重要： 現在のサービス リリースでは、サブスクリプション内でゲートウェイ構成がデプロイされた後、これらのインスタンスで使用される仮想マシン モデルを簡単に変更することはできません。デプロイ後に仮想マシン モデルを変更するには、ゲートウェイ構成を削除して再デプロイする必要があります。ポッドあたりのセッション数が 2,000 にまで拡大することが想定される環境では、 F8s_v2 を使用します。 VMware Horizon Cloud Service on Microsoft Azure サービスの制限で説明したように、 A4_v2 仮想マシン モデルが十分に機能するのは、ポッドでのアクティブなセッション数が 1,000 を超えないことが分かっている PoC（概念実証）環境、パイロット環境、または小規模な環境のみとなります。
    [証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするために、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づいたものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間証明書、ルート CA 証明書、プライベート キーを含む、完全な証明書チェーンが含まれている必要があります。
    [Blast Extreme TCP ポート] Unified Access Gateway 構成内の Blast Extreme TCP 設定で使用する TCP ポートを選択します。この設定は、クライアントから送信されるデータ トラフィックに対し Unified Access Gateway 上の Blast Secure Gateway 経由の Blast Extreme に関連しています。ポート 8443 は、より効率的で、パフォーマンスが向上し、Unified Access Gateway インスタンスでのリソース使用率が低いため、推奨されます。このような理由により、ウィザードのデフォルト値は 8443 です。もう 1 つの選択肢である 443 は、効率が低く、パフォーマンスが低下して、インスタンスで CPU の輻輳が発生し、エンドユーザー クライアントでトラフィックの遅延が見られる可能性があります。443 の選択肢は、組織でクライアント側の制限が設定されている場合（組織で 443 送信のみが許可されているなど）にのみ使用する必要があります。
    注： Blast Extreme に使用される UDP ポートは、この設定の影響を受けず、常に UDP 8443 です。
    [暗号スイート] ほとんどの場合、デフォルト設定を変更する必要はありませんが、Unified Access Gateway には、クライアントと Unified Access Gateway アプライアンス間の通信の暗号化に使用される暗号化アルゴリズムをオプションで指定するためのこの機能が用意されています。

    画面上のリストから少なくとも 1 つの暗号スイートを選択する必要があります。画面上のリストには、Horizon Cloud on Microsoft Azure 環境で許可されている暗号スイートが表示されます。

    このゲートウェイの Microsoft ロード バランサの設定を指定します。

    オプション 説明
    [パブリック IP アドレスを有効にしますか?] このゲートウェイのロード バランシング タイプがプライベートとして構成されるか、パブリックとして構成されるかを制御します。オンに切り替えると、デプロイされた Microsoft Azure ロード バランサ リソースがパブリック IP アドレスで構成されます。オフに切り替えると、Microsoft Azure ロード バランサ リソースがプライベート IP アドレスで構成されます。
    重要： このリリースでは、外部ゲートウェイのロード バランシング タイプを後でパブリックからプライベートに、またはプライベートからパブリックに変更することはできません。この変更を行う唯一の方法は、デプロイされたポッドからゲートウェイ構成を完全に削除してから、ポッドを編集して逆の設定で追加することです。

    このトグルをオフに切り替えると、[Horizon FQDN のパブリック IP アドレス] フィールドが表示されます。
    [Horizon FQDN のパブリック IP アドレス] デプロイされた Microsoft Azure ロード バランサをパブリック IP アドレスで構成しないことを選択した場合、[FQDN] フィールドで指定した FQDN を割り当てる IP アドレスを指定する必要があります。エンド ユーザーの Horizon Client は、ゲートウェイへの PCoIP 接続にこの FQDN を使用します。デプロイヤは、この IP アドレスを Unified Access Gateway 構成の設定で構成します。

    外部ゲートウェイのネットワーク設定を指定します。

    オプション 説明
    [別の仮想ネットワークを使用] このトグルは、外部ゲートウェイをポッドの VNet とは別の専用の VNet にデプロイするかどうかを制御します。

    次の行は、さまざまなケースを示しています。

    注： ウィザードの最初のステップで外部ゲートウェイに別のサブスクリプションを使用するように指定した場合、このトグルはデフォルトで有効になっています。その場合は、ゲートウェイの VNet を選択する必要があります。

    このトグルをオンにして、[ポッドの NTP サーバの継承] トグルをオンに切り替える場合は、ポッド マネージャ インスタンスに指定された NTP サーバに、外部ゲートウェイのデプロイ用に選択した仮想ネットワークからアクセスできることを確認します。
    [別の仮想ネットワークを使用] - オフ トグルをオフに切り替えると、外部ゲートウェイがポッドの VNet にデプロイされます。この場合は、DMZ サブネットを指定する必要があります。
    • [DMZ サブネット] - ポッドのセットアップ ウィザード手順で [既存のサブネットを使用] を有効にすると、[DMZ サブネット] には [仮想ネットワーク] に対して選択された VNet 上で使用可能なサブネットが表示されます。ポッドの DMZ サブネットに使用する既存のサブネットを選択します。
      重要： 接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ中またはポッドの操作中に予期しない結果が発生する可能性があります。
    • [DMZ サブネット (CIDR)] - 前のウィザード手順で [既存のサブネットを使用] がオフになっている場合、DMZ（非武装地帯）ネットワークのサブネットを CIDR 表記で入力します。このネットワークは、Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリック ロード バランサに接続するように構成されます。
    [別の仮想ネットワークを使用] — 有効 トグルを有効にすると、外部ゲートウェイが専用の VNet にデプロイされます。この場合、使用する VNet を選択してから、必要な 3 つのサブネットを指定する必要があります。[既存のサブネットを使用] トグルを有効にして、指定した VNet で事前に作成したサブネットから選択します。そうでない場合は、サブネットを CIDR 表記で指定します。
    重要： 接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ プロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。

    この場合、ゲートウェイの VNet とポッドの VNet がピアリングされます。ベスト プラクティスは、サブネットを事前に作成し、ここで CIDR エントリを使用しないことです。ポッドの VNet またはサブスクリプションとは別の専用の VNet またはサブスクリプションを使用して外部 Unified Access Gateway 構成でデプロイする場合の前提条件を参照してください。

    • 管理サブネット - ゲートウェイの管理サブネットに使用するサブネットを指定します。少なくとも /27 の CIDR が必要です。このサブネットにはサービス エンドポイントとして Microsoft.SQL サービスが構成されている必要があります。
    • バックエンド サブネット - ゲートウェイのバックエンド サブネットに使用するサブネットを指定します。少なくとも /27 の CIDR が必要です。
    • フロントエンド サブネット - Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリック ロード バランサに接続するように構成されるフロントエンド サブネットのサブネットを指定します。
  6. （オプション） [デプロイ] セクションで、トグルを使用して、必要に応じてデプロイヤが外部ゲートウェイ構成のリソースを展開する既存のリソース グループを選択します。
    このトグルは、ウィザードの最初のステップで外部ゲートウェイに別のサブスクリプションを使用するように指定した場合に表示されます。トグルを有効にすると、リソース グループを検索して選択するフィールドが表示されます。
  7. 内部ゲートウェイを追加するには、[内部 UAG を有効にしますか? ] トグルをオンに切り替えて、[内部 UAG] セクションのフィールドに入力します。
    オプション 説明
    [内部ゲートウェイを有効にしますか?] ポッドに内部ゲートウェイ構成があるかどうかを制御します。内部構成は、企業のネットワーク内に存在するユーザーが HTML Access (Blast) でデスクトップおよびアプリケーションに接続するときに信頼されたアクセスを提供します。ポッドには、このアクセスを提供する Azure ロード バランサ リソースと Unified Access Gateway インスタンスが含まれています。デフォルトでは、このゲートウェイのロード バランシング タイプはプライベートです。ロード バランサは、プライベート IP アドレスで構成されます。
    [FQDN] サービスへのアクセスでエンド ユーザーが使用する完全修飾ドメイン名 (FQDN) を入力します（例：ourOrg.example.com）。このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。
    重要： この FQDN には、アンダー スコアを含めることはできません。このリリースでは、FQDN にアンダー スコアが含まれていると、 Unified Access Gateway インスタンスへの接続が失敗します。
    [DNS アドレス] オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力します。

    Unified Access Gateway インスタンスのデプロイ先となる VNet トポロジの外部にある 2 要素認証サーバで 2 要素認証を使用するようにこの内部 Unified Access Gateway 構成を構成する場合は、その認証サーバのホスト名を解決できる DNS サーバのアドレスを指定します。たとえば、2 要素認証サーバがオンプレミスにある場合は、その認証サーバの名前を解決できる DNS サーバのアドレスを入力します。

    デプロイの前提条件で説明されているように、Horizon Cloud on Microsoft Azure のデプロイに使用される VNet トポロジは、Unified Access Gateway インスタンスのデプロイ中に、また、その進行中の操作のために、外部の名前解決を提供する DNS サーバと通信できる必要があります。

    デフォルトでは、インスタンスがデプロイされる VNet で構成されている DNS サーバが使用されます。

    [DNS アドレス] にアドレスを指定すると、デプロイされた Unified Access Gateway インスタンスは、VNet の構成の DNS サーバ情報に加えてこれらのアドレスを使用します。

    [ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンド ユーザー アクセス用のネットワークのルーティングを解決するために使用する、追加のゲートウェイへのカスタム ルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証サーバとの通信などにネットワーク ルーティングを解決できるようにするために使用されます。

    このポッドをオンプレミスの認証サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway インスタンスがそのサーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの認証サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルト ルートのゲートウェイ アドレスをカスタム ルートとして入力することになります。この環境で使用している Express ルートまたは VPN 構成からデフォルト ルートのゲートウェイ アドレスを取得します。

    形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタム ルートを指定します（例：192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2）。

    [ポッドの NTP サーバの継承] このトグルはデフォルトで有効になっており、Unified Access Gateway インスタンスは、ポッド マネージャ インスタンスに指定されているのと同じ NTP サーバを使用します。このトグルを有効にしておくことを強くお勧めします。

    ポッド マネージャ インスタンス、Unified Access Gateway インスタンス、および Active Directory サーバに同じ NTP サーバを使用することがベスト プラクティスです。タイム スキューは、これらのインスタンスが異なる NTP サーバを使用する場合に発生する可能性があります。このようなタイム スキューにより、後でゲートウェイがデスクトップおよびアプリケーションに対してエンド ユーザー セッションを認証しようとしたときに、エラーが発生する可能性があります。
    [仮想マシン モデル] Unified Access Gateway インスタンスに使用するモデルを選択します。このポッドに指定した Microsoft Azure サブスクリプションが、選択したモデルの 2 台の仮想マシンのキャパシティを確実に満たすようにする必要があります。
    重要： 現在のサービス リリースでは、サブスクリプション内でゲートウェイ構成がデプロイされた後、これらのインスタンスで使用される仮想マシン モデルを簡単に変更することはできません。デプロイ後に仮想マシン モデルを変更するには、ゲートウェイ構成を削除して再デプロイする必要があります。ポッドあたりのセッション数が 2,000 にまで拡大することが想定される環境では、 F8s_v2 を使用します。 VMware Horizon Cloud Service on Microsoft Azure サービスの制限で説明したように、 A4_v2 仮想マシン モデルが十分に機能するのは、ポッドでのアクティブなセッション数が 1,000 を超えないことが分かっている PoC（概念実証）環境、パイロット環境、または小規模な環境のみとなります。
    [証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするために、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づいたものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間証明書、ルート CA 証明書、プライベート キーを含む、完全な証明書チェーンが含まれている必要があります。
    [Blast Extreme TCP ポート] Unified Access Gateway 構成内の Blast Extreme TCP 設定で使用する TCP ポートを選択します。この設定は、クライアントから送信されるデータ トラフィックに対し Unified Access Gateway 上の Blast Secure Gateway 経由の Blast Extreme に関連しています。ポート 8443 は、より効率的で、パフォーマンスが向上し、Unified Access Gateway インスタンスでのリソース使用率が低いため、推奨されます。このような理由により、ウィザードのデフォルト値は 8443 です。もう 1 つの選択肢である 443 は、効率が低く、パフォーマンスが低下して、インスタンスで CPU の輻輳が発生し、エンドユーザー クライアントでトラフィックの遅延が見られる可能性があります。443 の選択肢は、組織でクライアント側の制限が設定されている場合（組織で 443 送信のみが許可されているなど）にのみ使用する必要があります。
    注： Blast Extreme に使用される UDP ポートは、この設定の影響を受けず、常に UDP 8443 です。
    [暗号スイート] ほとんどの場合、デフォルト設定で十分ですが、Unified Access Gateway には、クライアントと Unified Access Gateway アプライアンス間の通信の暗号化に使用される暗号化アルゴリズムを指定するためのこの機能が用意されています。

    画面上のリストから少なくとも 1 つの暗号スイートを選択する必要があります。画面上のリストには、Horizon Cloud on Microsoft Azure 環境で許可されている暗号スイートが表示されます。
  8. 追加しているいずれかのゲートウェイのセクションで、オプションで 2 要素認証を使用するようにエンド ユーザーのデスクトップを構成する場合は、Horizon Cloud ポッドのゲートウェイでの 2 要素認証の有効化の手順に従います。
  9. [Azure リソース タグ] セクションで、ポッドの他のリソース グループで指定されているものとは異なるゲートウェイ関連のリソース グループのリソース タグを指定する場合は、[ポッド タグの継承] を無効にして、表示されるフィールドにタグを指定します。
    [Azure リソース タグ] フィールドの説明については、 第 1 世代テナント - Horizon Cloud ポッドのゲートウェイ構成の指定を参照してください。ポッドの両方のタイプのゲートウェイには同じタグのセットが使用されます。
  10. [保存して終了] をクリックします。
    ワークフローの開始を確認するよう求める確認メッセージが表示されます。
  11. [はい] をクリックしてワークフローを開始します。

結果

ゲートウェイの要素をシステムがデプロイ完了するまで、ポッドのサマリ ページにおけるその構成タイプのセクションには、保留中 ステータスが表示されます。また、システムがゲートウェイをデプロイするアクションを完了するまで、追加の [ポッドを編集] ワークフロー関連のアクティビティを実行することはできません。

ワークフローが完了すると、ステータスには 準備完了 と表示され、ロード バランサの FQDN がページに表示されます。

注： Microsoft Azure China のポッドに対してこのワークフローを実行する場合、プロセスが完了するまでに 1 時間以上かかることがあります。このプロセスは地理的なネットワークの問題の影響を受け、バイナリがクラウドの制御プレーンからダウンロードされるときにダウンロードの速度が低下することがあります。

次のタスク

重要： エンド ユーザーが新たに追加されたゲートウェイの使用を開始できるようにするには、次のタスクを実行する必要があります。
  • 新しく追加されたゲートウェイ構成の場合、構成でデプロイされるロード バランサをデプロイ ウィザードで入力した FQDN にマッピングする CNAME レコードが DNS サーバにあることを確認します。詳細については、DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法を参照してください。
  • 追加されたゲートウェイに 2 要素認証を指定した場合は、次のタスクを実行する必要があります。
    • ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。

      このシナリオでは、ゲートウェイ展開と同じ VNet トポロジ内で 2 要素認証サーバにアクセスできないため、Unified Access Gateway インスタンスは、そのロード バランサ アドレスを使用してそのサーバとの接続を試みます。その通信トラフィックを許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に 2 要素認証サーバの構成でクライアントまたは登録されたエージェントとして指定されているようにします。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

    • 同じ VNet トポロジ内で 2 要素認証サーバにアクセスできる場合は、Microsoft Azure でのデプロイの Unified Access Gateway インスタンス用に作成された適切な NIC からの通信を許可するように 2 要素認証サーバを構成します。

      ネットワーク管理者が、展開に使用される Azure VNet トポロジとそのサブネットに対する 2 要素認証サーバのネットワーク可視性を決定します。2 要素認証サーバは、ネットワーク管理者が 2 要素認証サーバにネットワークの可視性を与えたサブネットに対応する Unified Access Gateway インスタンスの NIC の IP アドレスからの通信を許可する必要があります。

      Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドとそのゲートウェイが更新を完了した後にアクティブになります。

      実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと 2 要素認証サーバ間の通信トラフィックをサポートするには、これらの 4 つの NIC の IP アドレスがそのサーバ構成でクライアントまたは登録されたエージェントとして指定されていることを確認します。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

    これらの IP アドレスの取得方法については、必要な Horizon Cloud ポッドのゲートウェイ情報での 2 要素認証システムの更新を参照してください。