この手順は、Horizon Cloud テナント環境がシングルポッド仲介を使用するように構成されていて、その環境で Omnissa Access を使用する場合に使用します。Horizon Cloud on Microsoft Azure デプロイをクラウド ホスト型の Access 環境と統合することにより、エンド ユーザーは、ポッドでプロビジョニングされた資格のあるデスクトップおよびアプリケーションを Access の単一の統合カタログから認証することができます。
Horizon Cloud は、クラウド ホスト型の Access との統合をサポートします。
この統合を実現するには、Access 環境とポッドをブリッジする Access Connector をデプロイする必要があります。このコネクタを使用すると、エンド ユーザーの資格をポッドから Access に同期できます。
メモ: Access ドキュメントのスクリーンショットは、特定の Access 環境に表示されるユーザー インターフェイス要素とは異なって見える場合があります。
背景情報と用語
-
通常どおり、Horizon Universal Console でユーザーとグループのデスクトップとリモート アプリケーションの割り当てを構成します。
-
ポッドを Access 環境と統合する手順を完了したら、ポッドの割り当て情報を Access に同期します。
-
これにより、デスクトップとアプリケーションが Access 管理コンソールに表示され、エンド ユーザーが Access から割り当てられたリソースに認証できるようになります。
-
割り当て情報を Horizon Cloud から Access 環境に同期する定期的な同期スケジュールを設定できます。
-
Access の以前の名称は Identity Manager でした。コネクタの以前の名称は Identity Manager Connector でした。特に古いコネクタ バージョンを使用している場合は、製品、ドキュメント、およびナレッジベースの記事に以前の名前が引き続き記載されている可能性があります。
-
Access のドキュメントでは、ポッドから Access へのコネクタの同期について説明するときに、資格という用語を使用します。
Horizon Cloud では、割り当てはリソースと資格の組み合わせを表します。
Horizon Universal Console では、ユーザーを割り当てに追加すると、そのユーザーには、ポッドでプロビジョニングされた割り当てのリソースを使用する資格が付与されます。たとえば、専用の VDI デスクトップ割り当てを作成するときなどです。
-
アクセス コンソールが更新され、Horizon Cloud コレクションという用語を使用するウィザードが追加されました。Access ドキュメントと Horizon Cloud ドキュメント(仮想アプリケーションのコレクションと Horizon Cloud コレクション)の両方のフレーズが表示されることがあります。
主要コンポーネントの概要
Horizon Cloud テナント環境がシングルポッド仲介を使用するように構成されている場合は、Microsoft Azure の個々のポッドを Access と統合して、各ポッドからプロビジョニングされたエンドユーザー リソースで Access 機能を使用します。
Microsoft Azure のポッドと Access の統合には、次の主要な概念が含まれます。
- Microsoft Azure にデプロイされたポッド
- Access テナント環境
- 有効な SSL 証明書がポッドのマネージャ仮想マシンにアップロードされていること。この SSL 証明書により、Access Connector は、Access で定義された Horizon Cloud 仮想アプリケーションのコレクションの使用資格とポッドでプロビジョニングされたリソースを同期するときに、ポッドへの信頼された接続を確立できます。
- Access Connector がインストールされ、 と同期するための設定が行われました。 次のリソースに関する情報にアクセスします。
- Active Directory のユーザーおよびグループ
- ポッドの割り当て(ポッドによってプロビジョニングされたリソースとそれらのリソースに対する資格)
- Access がポッドとの SAML 通信を実行できるようにする SAML アーティファクトを設定するための Horizon Universal Console の構成。
統合プロセスの概要
次のリストは、エンド ユーザーが Access を使用してポッドでプロビジョニングされたデスクトップおよびアプリケーションに認証できるようにするためのエンドツーエンドの手順の概要です。
これらの手順を実行する前に、ポッドがすでに Microsoft Azure に展開されており、シングルポッド仲介を使用するように Horizon Cloud テナントが構成されており、Access クラウド テナントがある必要があります。
-
DNS サーバで、ポッド マネージャの Azure ロード バランサの IP アドレスを
mypod1.example.comなどの完全修飾ドメイン名 (FQDN) にマッピングします。この IP アドレスは、ポッドの詳細ページで確認できます。ポッドの詳細ページ内でその IP アドレスを見つける場所については、 ポッド マネージャ仮想マシンでの SSL 証明書の構成の概要 を参照してください。メモ: 2020 年 7 月の四半期ごとのサービス リリース以前は、この IP アドレスはポッドの詳細ページに テナント アプライアンスの IP アドレス というラベルが付いていました。現在のラベルは ポッド マネージャのロード バランサの IP アドレス です。最新のマニフェストのポッドには、デフォルトでポッド マネージャ インスタンス用にデプロイされた Microsoft Azure ロード バランサが含まれており、現在のラベルにはそのポッド アーキテクチャが反映されています。マニフェストのポッドが 1600 未満であっても、ポッド マネージャ仮想マシン用に Microsoft Azure ロード バランサがデプロイされていない場合でも、このペアリング タスクに使用する必要がある IP アドレスは、ポッドの詳細ページのそのラベルの横に表示される IP アドレスです。
-
その FQDN に基づいて信頼される SSL 証明書を取得します。必要な内容の詳細については、次のトピックを参照してください。
- ポッド マネージャ仮想マシンでの SSL 証明書の構成の概要
- ポッド マネージャ仮想マシンで SSL 証明書を構成するための前提条件 注: SSL 証明書をポッドにアップロードするために必要な証明書ファイル形式は、ポッドのゲートウェイ構成で使用される PEM ファイル形式とは異なります。
-
ポッド マネージャ仮想マシンでの SSL 証明書の直接構成の説明に従って、その SSL 証明書をポッド マネージャ仮想マシンにアップロードします。
重要: ポッドに接続を試みる Access Connector に提示するように説明どおりに構成された SSL 証明書がポッドにない場合、コネクタは信頼されていないネットワーク接続を確立しないため、資格とリソースを同期するためにポッドに接続しようとすると失敗します。ポッドに正常に接続するには、ポッドの SSL 証明書が Connector によって信頼されている必要があります。基準を満たす SSL 証明書をポッドにアップロードするまで、Access をポッドに正常に統合することはできません。
-
Horizon Cloud ポッドと Active Directory 環境の両方と通信できるネットワークに Access Connector アプライアンスを展開します。コネクタの目的は、ポッドのリソースと資格を同期すること、および Active Directory 環境のユーザーとグループを同期することです。
以下の 「統合手順を開始する前に必要なもの」というタイトルのセクションから始まるコネクタ関連のすべての前提条件を確認します。
重要: また、そのコネクタで構成する信頼性のあるタイム ソースが、ポッドに対して構成されている NTP サーバと一致することも確認する必要があります。タイム ソースが一致しない場合、同期の問題が発生する可能性があります。ポッドの詳細ページには、ポッドの構成済み NTP サーバが表示されます。Horizon Universal Console の [キャパシティ] ページからポッドの詳細ページを開くことができます。
-
状況に適した Access 製品ドキュメントの説明に従って、統合のための Access の前提条件を満たしていることを確認します。以下の「 統合手順を開始する前に必要なもの」というタイトルのセクションを参照してください。
Access ドキュメントの 『リソースのセットアップ 』ガイドの Horizon Cloud と統合するための前提条件を参照してください。
-
Access 製品の情報の説明に従って、Horizon Cloud 環境から Access 環境へのデスクトップを有効にします。
Access ドキュメントのAccess での Horizon Cloud テナントの構成ページを参照してください。
-
Access ドキュメントの手順を実行する場合は、次の重要な点に注意してください
- Access アクセス用にポッドを構成する以下の手順 8 を完了するまで、コレクションを同期しないでください。
- Horizon Cloud テナント情報を入力するための アクセス 画面の ホスト フィールドで、ポッド マネージャ仮想マシンに到達するために、DNS サーバでポッド マネージャの Azure ロード バランサ IP アドレスにマッピングした FQDN を指定します。
この FQDN は、 ポッド マネージャ仮想マシンでの SSL 証明書の直接構成の説明に従って、ポッドに直接アップロードした SSL 証明書と一致する必要があります。
-
-
構成済みの Access 環境をポッドの ID 管理プロバイダとして使用できるようにする設定を入力します。関連するアクセス テナント情報を使用して Horizon Cloud ポッドを構成する手順を参照してください。
-
Access クラウド テナントで、コレクションを手動で同期して、次の手順で確認できるようにします。Access 管理コンソールで、コレクションを見つけて 同期 をクリックします。
-
デスクトップおよびアプリケーションへのエンド ユーザー アクセスを確認するには、Access にエンド ユーザーとしてログインし、カタログからデスクトップとアプリケーションを起動します。Access のデスクトップ割り当てへのエンド ユーザー アクセスの確認を参照してください。
統合が動作していることを確認したら、オプションでエンド ユーザーに Access を介してデスクトップおよびアプリケーションの認証とアクセスを強制できます。「 エンド ユーザーにアクセスを強制する」を参照してください。
統合手順を開始する前に必要なもの
Access を使用してポッドが提供するデスクトップまたは RDS ベースのリモート アプリケーションへのエンド ユーザー アクセスを検証する手順まで、統合プロセスをエンドツーエンドで完全に完了するには、次の要件が整っていることを確認します。
-
ポッド マネージャ仮想マシンでの SSL 証明書の構成の概要およびポッド マネージャ仮想マシンで SSL 証明書を構成するための前提条件で説明されているように、ポッド マネージャの Azure ロード バランサの IP アドレスを完全修飾ドメイン名 (FQDN) にマッピングする DNS サーバのエントリが必要です。
SSL 証明書で使用する FQDN を、Horizon Universal Console のポッドの詳細ページの ポッド マネージャのロード バランサの IP アドレス ラベルの横に表示される IP アドレスに解決する必要があります。
たとえば、次のスクリーンショットに示すポッドがあり、ポッドへのアクセス接続の目的で、
mypod-a.example.comの FQDN をそのポッドの FQDN として使用するとします。
この例では、DNS で、
mypod-a.example.comを図に示す IP アドレス 192.168.21.4 にマッピングします。mypod-a.example.com 192.168.21.4[Access] 画面で Horizon Cloud テナント情報を入力する手順を実行するときに、その [Access] 画面の [Host ] フィールドにこの FQDN を指定します。
-
ポッドの詳細ページを使用してポッド マネージャ自体にアップロードした、信頼できる有効な SSL 証明書を持つ完全に構成されたポッド。証明書のアップロードの詳細については、 ポッド マネージャ仮想マシンでの SSL 証明書の構成の概要を参照してください。
-
ポッドに対して構成された VDI デスクトップ割り当て、セッション デスクトップ割り当て、またはリモート アプリケーション割り当て。
-
組織の構成済み Access クラウド テナントへのアクセス。
クラウド ホスト型の Access を使用する場合、ポッドとそのテナントを統合するには、Access Connector アプライアンスが必要です。このコネクタは、ユーザーとグループの資格に関する情報を仮想デスクトップに送信し、アプリケーションを Access テナントに送信します。コネクタ アプライアンスを Active Directory ネットワークにインストールする必要があります。Access Cloud のドキュメントに記載されている手順および Horizon Cloud と Access を統合するための展開シナリオで説明されている手順に従います。このリリースに必要なコネクタのバージョンについては、 製品の相互運用性マトリックスを参照してください。
コネクタに構成されている信頼性のあるタイム ソースが、ポッドに構成されている NTP サーバと一致していることを確認します。
メモ: 既存の統合および Access コネクタ アプライアンスがある場合のベスト プラクティスは、ポッドを最新のポッド ソフトウェア レベルに更新する前にコネクタを更新することです。
-
Access ドキュメント ページの 「統合の前提条件」の説明に従って、構成されている Access 環境が Horizon Cloud リソースとの統合のためのすべての前提条件を満たしていることを確認します。
関連するアクセス テナント情報を使用した Microsoft Azure での Horizon Cloud ポッドの構成
Microsoft Azure のポッドを Access と統合するには、適切な Access 情報を使用してポッドを構成する必要があります。この情報を構成するには、Horizon Universal Console を使用します。
前提条件
ポッド マネージャ仮想マシンでの SSL 証明書の直接構成の説明に従って、その FQDN に基づく SSL 証明書がポッド マネージャ仮想マシンにアップロードされていることを確認します。その SSL 証明書は、DNS サーバでポッド マネージャの Azure ロード バランサの IP アドレスにマッピングした FQDN に基づいている必要があります。
Access 環境が、ポッドでプロビジョニングされたエンド ユーザー リソースと資格を Access に同期するために、その FQDN を使用するように構成されていることを確認します。
次の情報があることを確認します。
-
Access テナントからの SAML ID プロバイダ (IdP) メタデータ URL。
Access 管理コンソールの SAML メタデータを使用して、環境の SAML IdP メタデータ URL を取得します。
Access Cloud のドキュメント ページ Horizon Cloud テナントでの SAML 認証の構成を参照してください。
そのページの ID プロバイダ (IdP) メタデータ リンクをクリックすると、ブラウザのアドレス バーに URL が通常
https://AccessFQDN/SAAS/API/1.0/GET/metadata/idp.xmlの形式で表示されます。ここで、AccessFQDN は Access 環境の完全修飾ドメイン名 (FQDN) です。 -
Horizon Cloud に接続するためにエンド ユーザーが接続先に指定する FQDN。
手順
-
Horizon Universal Console で、設定**> ID 管理** の順に移動し、新規 をクリックします。
-
次のオプションを構成します。
設定 説明 メタデータ URL へのアクセス Access テナントの SAML ID プロバイダ (IdP) メタデータ URL を入力します。通常、このメタデータ URL は https://WS1AccessFQDN/SAAS/API/1.0/GET/metadata/idp.xmlという形式であり、WS1AccessFQDN は Access 環境の FQDN です。SSO トークンのタイムアウト SSO トークンがタイムアウトになるまでの時間を分単位で入力します。事前入力されたシステムのデフォルト値はゼロ (0) です。 場所 場所の 1 つを選択して、 ポッド ドロップダウンをフィルタして、その場所に関連付けられているポッドのセットを表示します。 ポッド この構成を適用するポッドを選択します。 データセンター ドロップダウンには、Horizon Cloud ポッドのマニフェスト バージョンに関連する数値が表示されます。デフォルトのままにします。 クライアント アクセスの FQDN Horizon Cloud に接続するためにエンド ユーザーが接続先に指定する FQDN を入力します。 Workspace ONE リダイレクト また、エンド ユーザーのアクセスを Access を経由させるように構成している場合、このトグルを はい に設定して、エンド ユーザーのクライアントを自動的に Access 環境にリダイレクトすることができます。エンドユーザーのアクセスを強制的に Access を経由させるオプションの設定については、 エンドユーザーに Access を経由させるを参照してください。 自動リダイレクトが YES に構成されている場合、エンドユーザー クライアントでクライアントが Horizon Cloud に接続しようとしたときに、Access を介して認証を強制するように構成すると、クライアントはポッドに統合されている Access 環境に自動的にリダイレクトされます。 トグルを NO に設定すると、自動リダイレクトは有効になりません。 自動リダイレクトが無効で、強制アクセスが構成されている場合、クライアントは代わりに情報メッセージをユーザーに表示します。詳細については、「 エンド ユーザーが Access を経由するように強制する」を参照してください。 注: アクセス リダイレクトは、ここで構成する ID 管理プロバイダの 1 つに対してのみ有効にできます。別の構成でトグルがすでに はい に設定されている場合に、そのトグルを はいに設定しようとすると、エラー メッセージが表示されます。 -
[保存] をクリックします。
タスクの結果
緑色のステータスは、構成が成功したことを示します。
次のタスク
Access クラウド テナントで、資格のあるデスクトップとアプリケーションを手動で同期します。Access 管理コンソールで、この Horizon Cloud ポッドに定義されているコレクションを見つけて、 同期 をクリックします。
重要：
- Horizon Cloud でリソースまたは資格が変更されるたびに、同期を実行して変更を Access に伝達する必要があります。
- また、そのコネクタで構成する信頼性のあるタイム ソースが、ポッドに対して構成されている NTP サーバと一致することも確認する必要があります。タイム ソースが一致しない場合、同期の問題が発生する可能性があります。ポッドの詳細ページには、ポッドの構成済み NTP サーバが表示されます。Horizon Universal Console の [キャパシティ] ページからポッドの詳細ページを開くことができます。
Access でのデスクトップ割り当てへのエンド ユーザー アクセスの確認
Horizon Cloud 環境を Access 環境に統合した後、これらの手順を使用して、エンド ユーザーがポッドでプロビジョニングされた仮想デスクトップおよびリモート アプリケーションにリモート アクセスできることを確認することができます。
前提条件
次の項目が完了していることを確認します。
- 前述の 構成手順の説明に従って、統合プロセスを完了します。
- 構成手順を完了します。
- Access を介してデスクトップにアクセスするためにエンド ユーザーに提供するアクセス方法を構成します。
- 資格のあるデスクトップが統合 Horizon Cloud ポッドから Access 環境に同期されていることを確認します。Access 管理コンソールで、[仮想アプリケーションの構成] ページに移動し、Horizon Cloud コレクションを同期します。
手順
-
組織のアクセス URL を使用して Access にログインします。
-
資格のある Horizon Cloud デスクトップとリモート アプリケーションをポータルから起動します。
このページは役に立ちましたか?