移行ダッシュボードを使用した Omnissa Access Connector 22.09 への移行

移行ダッシュボードを使用して、既存のディレクトリと仮想アプリケーションのコレクションを Omnissa Access 19.03 または 19.03.0.1 Connector から 22.09 Connector に移行します。移行プロセスは、移行を完了する前に新しいコネクタを使用して環境をテストできる段階的なアプローチです。

移行ステージ

この移行プロセスには、次のステージが含まれます。

• 22.09 Connector のインストール

  新しい 22.09 Connector （ディレクトリ同期サービス、ユーザー認証サービス、Kerberos 認証サービス、仮想アプリケーション サービスを含む）をインストールします。少なくとも、ディレクトリ同期サービスをインストールします。レガシー コネクタでコネクタベースの認証が構成されている場合は、ユーザー認証サービスをインストールします。レガシー コネクタで Kerberos 認証方法が構成されている場合は、Kerberos 認証サービスをインストールします。レガシー コネクタで仮想アプリケーションのコレクションが構成されている場合は、仮想アプリケーション サービスをインストールします。

• ディレクトリの移行

  このステージでは、ディレクトリの移行ウィザードを使用して、すべてのディレクトリ データを移行します。必要な情報のほとんどは環境から事前に入力されていますが、ディレクトリのバインド ユーザー パスワードなどの重要な値を入力します。

  このステージでディレクトリを移行しても、既存のディレクトリ、認証方法、または ID プロバイダの構成は変更されません。まだ古いコネクタを使用しています。変更は、プレビュー ステージに移動した後にのみ有効になります。

• 仮想アプリケーションのコレクションの移行

  このステージでは、既存の仮想アプリケーションのコレクションを移行するコネクタを選択します。新しい設定は、プレビュー ステージに移動した後にのみ有効になります。

• プレビュー

  プレビュー ステージでは、新しい 22.09 Connector を使用して環境をプレビューします。22.09 Connector からの新しいディレクトリ同期サービス、ユーザー認証サービス、Kerberos 認証サービス、および仮想アプリケーション サービスにより、ディレクトリの同期、ユーザーの認証、および仮想アプリケーションの同期が実行されます。Kerberos を除くすべての認証方法が送信モードになります。

  プレビュー ステージは、新しいサービスを使用して環境を徹底的にテストすることを目的としています。ディレクトリの同期、仮想アプリケーションの同期、ユーザーの認証、アプリケーションの起動が予期したとおりに正常に機能していることを確認します。

  プレビュー ステージでは、ディレクトリ、認証方法、ID プロバイダ、または仮想アプリケーションのコレクションを作成、編集、または削除することはできません。

  プレビュー ステージから、古いコネクタの使用にロールバックできます。ロールバックすると、前のステージで移行したディレクトリ データが維持されたままになります。その後、既存のディレクトリ、認証方法、または ID プロバイダのいずれかに変更を加えた場合は、必ずディレクトリ データを再度移行してください。

• 移行の完了

  新しい環境のテストに問題がなければ、移行を完了します。移行が完了した後は、古いコネクタの使用にロールバックすることはできません。

前提条件

• 「Omnissa Access Connector 22.09 に移行するための要件」に記載されている要件を確認します。

• 環境内のすべてのコネクタのバージョンが 19.03.x であることを確認します。古いバージョンのコネクタがある場合は、移行を開始する前に 19.03.x にアップグレードします。

• 22.09 Connector 用に 1 台以上の Windows サーバを準備します。

  詳細については、「Omnissa Access Connector 22.09 に移行するための要件」を参照してください。

• オンプレミスの Omnissa Access 仮想アプライアンスを使用している場合は、コネクタを移行する前に 22.09 にアップグレードします。

• ユーザー認証サービスをインストールする場合は、環境に 22.05、21.x、または 20.x ユーザー認証サービス インスタンスが含まれていないことを確認します。移行の一環として、22.09 Connector をインストールします。環境内のすべてのユーザー認証サービス インスタンスはバージョン 22.09 である必要があります。ユーザー認証サービスのバージョンが混在している場合は、移行を続行できません。

• RSA SecurID 認証方法が 19.03.x コネクタで構成されている場合：

  • RSA Authentication Manager アプライアンス バージョン 8.2 SP1 以降を使用していることを確認します。Omnissa Access Connector 22.09 は RSA Authentication Manager アプライアンス 8.2 SP1 以降をサポートします。
  • RSA Authentication Manager サーバの複数のインスタンスを展開している場合は、Omnissa Access との統合が機能するように、ロード バランサの背後でそれらを構成する必要があります。『Omnissa Access でのユーザー認証方法の管理』ガイドの「RSA SecurID ロード バランサの Omnissa Access 要件」に記載されている要件を満たしていることを確認します。
  • RSA セキュリティ コンソールで、コネクタが完全修飾ドメイン名 (FQDN) を使用して認証エージェントとして追加されていることを確認します。たとえば、connectorserver.example.com です。すでに FQDN ではなく NetBIOS 名を使用してコネクタを認証エージェントとして追加している場合は、FQDN を使用して別のエントリを追加します。新しいエントリの IP アドレス フィールドは空のままにします。古いエントリは削除しないでください。
  • 移行プロセスの一環として、RSA SecurID 認証方法を構成します。認証方法の構成に必要な情報には、RSA Authentication Manager またはロード バランサ サーバのホスト名、通信ポート、アクセス キー、およびサーバが自己署名証明書を使用する場合の RSA Authentication Manager またはロード バランサ サーバの SSL 証明書が含まれます。情報の一部を RSA セキュリティ コンソールから取得するため、セキュリティ コンソールの認証情報も必要です。
  • プロキシ サーバにコネクタが構成されている場合は、RSA Authentication Manager サーバ用に構成された通信ポートがプロキシ サーバで開いている必要があります。

• 新しい Windows Server にユーザー認証サービスをインストールする場合は、コネクタの移行を開始する前に、Windows Server を RSA Authentication Manager サーバにエージェントとして追加します。

• （オンプレミスの Omnissa Access のインストールのみ）ID プロバイダが複数のディレクトリに関連付けられている場合は、各 ID プロバイダが 1 つのディレクトリのみに関連付けられるように構成を変更します。

• ディレクトリを移行する前に、[グループを追加するときにグループ メンバーをディレクトリに同期] オプションを有効にして、ユーザー、グループ、およびグループ メンバーシップが正しく同期されていることを確認します。

  1. Omnissa Access コンソールで、[設定] > [ログイン設定] の順に選択します。

  2. [編集] をクリックし、[グループを追加するときにグループ メンバーをディレクトリに同期] チェック ボックスを選択して、[保存] をクリックします。

  3. ディレクトリの [同期設定] タブに移動し、[グループ] セクションを展開して、[保存] をクリックします。次に、[ユーザー] セクションを展開し、[保存] をクリックします。

     **重要：**この手順は、[ログイン設定] ページの変更を確実に有効にするために必要です。

  4. 正しいユーザー、グループ、およびグループ メンバーシップが Omnissa Access に同期されるまで、いくつかのディレクトリ同期の実行が正常に完了するのを待ちます。

• 移行プロセスを開始する前に、ディレクトリ同期プロセスがどのディレクトリに対しても実行されていないことを確認します。

• People Search 機能が有効になっている場合は、移行プロセスを開始する前に、どのディレクトリに対してもフォト同期プロセスが実行されていないことを確認します。

• ディレクトリが関連付けられていない 19.03.x Connector を移行する場合は、手順 5 で [最新の Workspace ONE Access Connector] オプションを選択すると、移行が完了したと見なされ、19.03.x Connector がテナントから削除されることに注意してください。後でガシー コネクタを使用することを決定し、[コネクタ選択のリセット] ボタンを使用してコネクタの選択を変更した場合、19.03.x Connector は表示されません。19.03.x Connector をサービスで再アクティベーションするには、再インストールする必要があります。

手順

1. Omnissa Access コンソールで、[統合] > [コネクタ（レガシー）] の順に選択し、[レガシー コネクタ] ページに移動します。

2. [レガシー コネクタ] ページで、[コネクタ選択のリセット] ボタンをクリックし、確認のポップアップで [続行] をクリックします。

   

   

3. [コネクタ使用の確認] ダイアログ ボックスで [最新の Workspace ONE Access Connector] を選択し、[OK] をクリックして、選択内容を確定します。

   

4. [統合] > [ディレクトリ] の順に選択して、[ディレクトリ] ページに移動します。

   [ディレクトリと仮想アプリケーションの移行] ページが表示されます。

   

5. [移行の開始] をクリックします。

   [移行] ダッシュボードが表示されます。このダッシュボードには、移行を完了するために実行する手順が表示されます。このページの情報を確認します。

6. [移行] ダッシュボードの [最新の Workspace ONE Access Connector のインストール] セクションで、[開始] をクリックします。

   

   [コネクタ] ページが表示されます。

7. [コネクタ] ページで、[新規] をクリックします。

   

8. 新しいコネクタを追加ウィザードに従って、コネクタ インストーラと必要な構成ファイルをダウンロードし、新しいコネクタをインストールします。

   

   インストールの情報については、『Omnissa Access Connector 22.09 のインストール』ガイドを参照してください。

   コネクタをインストールするときは、必ずディレクトリ同期サービスをインストールしてください。レガシー コネクタでコネクタベースの認証が構成されている場合は、ユーザー認証サービスをインストールします。Kerberos 認証サービスは、レガシー コネクタのいずれかに Kerberos 認証方法が構成されている場合にのみ必要です。レガシー コネクタで仮想アプリケーションのコレクションが構成されている場合、または新しいコネクタで仮想アプリケーションのコレクションを構成する場合は、仮想アプリケーション サービスをインストールします。

   注意：

   • Omnissa Access コンソールでコネクタの構成ファイルを生成する場合は、必ずルールを満たすパスワードを作成してください。

     パスワードは 14 文字以上で、1 つ以上の数字、1 つ以上の大文字、1 つ以上の特殊文字を含める必要があります。次の特殊文字のみを使用できます。

     @ ! , # $ { } ( ) _ + . < > ? *

     すべての文字は、表示および印字可能な ASCII 文字である必要があります。

   • インストール中に、インストーラの [構成ファイルの指定] ページに FIPS モードを有効にするオプションが表示されます。[FIPS を有効にする] オプションは選択しないでください。レガシー コネクタから 22.09 コネクタに移行する場合、FIPS モードはサポートされません。

   • インストール プロセスの最後に、システムを再起動するよう求めるプロンプトが表示される場合があります。19.03.x Connector サーバに新しい Connector をインストールする場合は、システムを再起動しないでください。コネクタの移行プロセス全体が完了した後にのみ、システムを再起動します。

   • ユーザー認証サービスをインストールする場合は、環境内のすべてのユーザー認証サービス インスタンスがバージョン 22.09 であり、22.05、21.x、または 20.x ユーザー認証サービス インスタンスが存在しないことを確認してください。ユーザー認証サービスのバージョンが混在している場合は、移行を続行できません。

9. コネクタのインストールが正常に完了したら、管理コンソールの [統合] > [ディレクトリ] ページに移動し、[移行を続行] をクリックします。

10. 移行ダッシュボードの [ディレクトリの移行] セクションで、すべてのディレクトリを 1 つずつ移行します。

    

    [ディレクトリの移行] セクションには、テナント内のすべての Active Directory および LDAP ディレクトリが一覧表示されます。移行を完了する前に、一覧表示されているすべてのディレクトリを移行する必要があります。

    **注：**このステップでディレクトリを移行しても、既存のディレクトリ、認証方法、ID プロバイダの構成は変更されず、次のステップで変更をプレビューした後にのみ有効になります。

    1. ディレクトリの横にある [移行] ボタンをクリックします。

       ディレクトリの移行ウィザードが表示されます。ウィザードは、移行するディレクトリに合わせてカスタマイズされます。ディレクトリに設定されている認証方法については、追加のページが表示されます。

    2. [ディレクトリ] ページで、ディレクトリのバインド ユーザー パスワードを入力します。

       [ディレクトリ同期ホスト] リストには、ディレクトリ同期サービスがインストールされている新しい 22.09 Connector ホストが表示されます。ディレクトリの同期に使用する 1 台以上のホストを選択します。

       

    3. [Kerberos] ページ（Kerberos 認証方法が構成されている場合にのみ表示されます）で、Kerberos 認証方法の移行に必要な情報を指定します。

       • ソース コネクタ：ソース コネクタが事前に選択されています。事前に選択したコネクタが使用できない場合は、別のコネクタを選択できます。
       • Kerberos 認証ホスト：Kerberos 認証サービスがインストールされている新しい 22.09 Connector ホストがリストに表示されます。Kerberos 認証に使用する 1 台以上のホストを選択します。

    4. [パスワード] ページで、パスワード認証方法の移行に必要な情報を指定します。

       • ソース コネクタ：ソース コネクタが事前に選択されています。事前に選択したコネクタが使用できない場合は、別のコネクタを選択できます。
       • バインド パスワード：ディレクトリのバインド ユーザー パスワードを入力します。
       • ユーザー認証ホスト：ユーザー認証サービスがインストールされている新しい 22.09 Connector ホストがリストに表示されます。パスワード認証に使用する 1 台以上のホストを選択します。

    5. [RADIUS] ページ（RADIUS 認証方法が構成されている場合にのみ表示されます）で、RADIUS 認証方法の移行に必要な情報を指定します。

       • ソース コネクタ：ソース コネクタが事前に選択されています。事前に選択したコネクタが使用できない場合は、別のコネクタを選択できます。
       • 共有シークレット：RADIUS サーバの共有シークレット。
       • ユーザー認証ホスト：ユーザー認証サービスがインストールされている新しい 22.09 Connector ホストがリストに表示されます。RADIUS 認証に使用する 1 台以上のホストを選択します。

    6. [SecurID] ページ（RSA SecurID 認証方法が構成されている場合にのみ表示されます）で、RSA SecurID 認証方法の移行に必要な情報を指定します。

       • ソース コネクタ：ソース コネクタが事前に選択されています。事前に選択したコネクタが使用できない場合は、別のコネクタを選択できます。

       • **許可されている認証試行回数：**RSA SecurID トークンを使用する場合のログイン失敗が許可される最大回数を入力します。デフォルトは、5 回です。

         **注：**RSA SecurID 認証を使用する複数のディレクトリを移行する場合は、各 RSA SecurID の構成で [許可されている認証試行回数] を同じ値に構成します。この値が同一でない場合、SecurID 認証は失敗します。

       • **SecurID サーバ ホスト名：**RSA Authentication Manager サーバのホスト名を入力します（myserver.example.com など）。ロード バランサの背後に RSA Authentication Manager サーバの複数のインスタンスを構成している場合は、代わりにロード バランサのホスト名を入力します。例：lb.example.com。

       • SecurID サーバ通信ポート：RSA Authentication Manager インスタンスの通信ポートを入力します。デフォルト ポートは 5555 です。通信ポート番号を取得するには、RSA セキュリティ コンソールにログインし、[セットアップ] > [システム設定] > [RSA SecurID 認証 API] ページに移動し、[通信ポート] をコピーします。

       • SecurID サーバ アクセス キー：RSA Authentication Manager インスタンスからアクセス キーを入力します。アクセス キーを取得するには、RSA セキュリティ コンソールで、[セットアップ] > [システム設定] > [RSA SecurID 認証 API] ページに移動し、[エージェント資格情報] に一覧表示される [アクセス キー] をコピーします。

       • **SecurID サーバ CA/SSL 証明書：**RSA Authentication Manager サーバまたはロード バランサ サーバに自己署名証明書がある場合は、証明書をコピーしてテキスト ボックスに貼り付けます。サーバに公式の認証局によって署名された証明書がある場合、証明書をアップロードする必要はありません。

       • **認証方法のタイムアウト（秒単位）：**認証の試行が可能な秒数を入力します。その後、認証の試行はタイムアウトになります。デフォルト値は 180 秒です。

       • ユーザー認証ホスト：ユーザー認証サービスがインストールされている新しい 22.09 Connector ホストがリストに表示されます。RSA SecurID 認証に使用する 1 台以上のホストを選択します。

    7. [ID プロバイダ] ページ（Kerberos 認証が構成されている場合にのみ表示されます）で、移行中に Kerberos 認証用に作成される新しい ID プロバイダに使用するコネクタ ロード バランサの完全修飾ドメイン名 (FQDN) を入力します。

       現在のロード バランサの FQDN が参照用に表示されます。これは、ディレクトリの ID プロバイダ ページの現在の [ID プロバイダ ホスト名] 値です。

       22.09 Connector が 1 つしかなく、ロード バランサが構成されていない場合は、コネクタの FQDN を入力します。

       

    8. [サマリ] ページで選択内容を確認し、[保存] をクリックします。

       ディレクトリ移行データが保存されます。設定を表示するには、[ディレクトリの移行] ダッシュボードのディレクトリの横にある [設定の確認] ボタンをクリックします。

       入力した情報を変更する場合は、[サマリ] ページで [最初からやり直し] をクリックします。これにより、ディレクトリに対して入力した移行データが破棄され、ディレクトリを再度移行できます。

       

    9. 残りのディレクトリを移行します。

11. [仮想アプリケーションのコレクションの移行] セクションで、仮想アプリケーションのコレクションを移行するコネクタを選択します。

    1. [移行] をクリックします。

       

    2. [仮想アプリケーションのコレクションの移行] ウィンドウで、各仮想アプリケーションのコレクションに使用する 22.09 Connector を選択します。仮想アプリケーション サービスがインストールされているすべてのコネクタがドロップダウン メニューに表示されます。仮想アプリケーション サービスがアクティブ状態のコネクタを選択します。コネクタ名の横に状態が表示されます。高可用性のために複数のコネクタを追加できます。複数のコネクタを追加する場合は、フォールバックの順序に並べ替えます。

       **注：**すべての仮想アプリケーションのコレクションを同時に移行する必要があります。移行する特定のコレクションを選択することはできません。

    3. [保存] をクリックします。

    例：

    

    プレビュー ステージに移動すると、仮想アプリケーションのコレクションが移行されます。

    **注：**移行の完了後にコネクタをさらに追加できます。また、仮想アプリケーションのコレクション用に選択したコネクタを変更することもできます。

12. [移行の完了] セクションで [プレビューの開始] をクリックして、移行プロセスを開始します。

    

    プレビュー ステージでは、新しい 22.09 Connector が使用されます。ディレクトリ同期は新しいディレクトリ同期サービスによって実行、ユーザー認証は新しいユーザー認証サービスによって実行、Kerberos 認証は新しい Kerberos 認証サービスによって実行、仮想アプリケーションの同期は新しい仮想アプリケーション サービスによって実行されます。プレビュー ステージでは、ディレクトリ、認証方法、ID プロバイダ、仮想アプリケーションのコレクションを変更したり、新しく作成したりすることはできません。変換された ID プロバイダは [統合] > [ID プロバイダ] ページで、変換された認証方法は [統合] > [コネクタ認証方法] ページで表示できます。Kerberos を除くすべての認証方法が送信モードになります。

    プレビュー ステージでは、次のガイドラインに従います。

    • ディレクトリごとに、セーフガードを使用せずにプレビュー ステージで最初のディレクトリ同期を実行する必要があります。ディレクトリ ページで [同期] > [セーフガードを使用しない同期] を選択します。

      すべてのユーザーとグループが更新されるため、最初の同期に時間がかかる点に注意してください。

      ディレクトリの同期が正常に完了したら、移行プロセスの残りの部分に進む前に、正しいユーザー、グループ、およびグループ メンバーシップが同期されていることを確認します。

    • 展開で People Search が有効になっている場合は、セーフガード設定なしでディレクトリを手動で同期する必要があります。セーフガードを使用せずにディレクトリを同期するには、[ディレクトリ] ページで [同期] > [セーフガードを使用しない同期] の順に選択します。 **重要：**プレビュー ステージで環境を完全にテストし、予期したとおりに動作していることを確認します。ディレクトリの同期、仮想アプリケーションの同期、ユーザー ログイン、アプリケーションの起動が正常に機能していることを確認します。

13. 環境が正常に動作していないと判断した場合、またはディレクトリ、認証方法、ID プロバイダ、仮想アプリケーションのコレクションを変更する場合は、プレビュー ステージをキャンセルしてから古いコネクタの使用に戻ります。

    [統合] > [ディレクトリ] ページに移動し、[移行を続行] をクリックして、[ディレクトリの移行] ダッシュボードの [移行の完了] セクションで [中断] をクリックします。

    後でディレクトリ、認証方法、ID プロバイダに変更を加えた場合は、[ディレクトリの移行] セクションで、ディレクトリを再度移行してください。

14. プレビュー ステージでお使いの環境が予期したとおりに動作していて、移行を完了する準備ができていることを確認したら、[統合] > [ディレクトリ] ページに移動し、[移行を続行] をクリックして [ディレクトリの移行] ダッシュボードに戻ります。

    注意：移行が完了した後は、古いコネクタにロールバックすることはできません。

    [完了] をクリックして移行を完了します。

結果

すべてのディレクトリと仮想アプリケーションのコレクションは、新しい 22.09 Connector に移行されます。新しいディレクトリ同期サービス、ユーザー認証サービス、Kerberos 認証サービス、および仮想アプリケーション サービスにより、ディレクトリの同期、ユーザーの認証、および仮想アプリケーションの同期が実行されるようになりました。

新しい ID プロバイダが各ディレクトリに作成され、「Migrated IDP for directory」という名前で [ID プロバイダ] ページに表示されます。新しい ID プロバイダは組み込みタイプです。Kerberos 認証では、Workspace_IDP タイプの個別の ID プロバイダが作成されます。

Kerberos を除くすべての認証方法は、送信方法に変換され、「(cloud deployment)」サフィックスで名前が変更されます。たとえば、Password 認証方法の名前は「Password (cloud deployment)」に変更されます。[コネクタ認証方法] ページから、新しい認証方法を表示および管理できます。

次のステップ

• 移行が完了したら、古い 19.03.x Connector をインストール先のサーバからアンインストールする必要があります。

  ThinApp 仮想アプリケーションのコレクションを移行した場合は、Linux Connector をアンインストールします。

• 移行が完了すると、Citrix 統合のための Integration Broker は必要なくなります。必要な機能が仮想アプリケーション サービスの一部になりました。

• Horizon および Horizon Cloud 統合の場合、Horizon Connection Server または Horizon Cloud テナントの基盤となる Horizon Server に、信頼されている認証局 (CA) によって署名された有効な証明書があることを確認します。Horizon Server に自己署名証明書がある場合は、仮想アプリケーション サービスがインストールされている Omnissa Access Connector インスタンスに証明書チェーンをアップロードして、コネクタと Horizon Server 間の信頼を確立する必要があります。これは、Omnissa Access Connector バージョン 21.08 以降の新しい要件です。コネクタ インストーラを使用して証明書をアップロードします。詳細については、『Omnissa Access Connector 22.09 のインストール』を参照してください。証明書をアップロードしたら、コネクタ サービスを再起動してください。