Linux Virtual Delivery Agent 2201

シャドウセッション

セッションシャドウイング機能を使用すると、ドメイン管理者はイントラネットでユーザーのICA®セッションを表示できます。この機能は、noVNCを使用してICAセッションに接続します。

注:

セッションシャドウイング機能を使用するには、Citrix Director 7.16以降を使用してください。

インストールと構成

依存関係

セッションシャドウイングには、python-websockifyx11vncの2つの新しい依存関係が必要です。python-websockifyx11vncの依存関係は、Ubuntu 16.04にLinux VDAをインストールすると自動的にインストールされます。その他のサポートされているディストリビューションでは、Linux VDAのインストール後にpython-websockifyx11vncを手動でインストールする必要があります。

RHEL 7.xおよびAmazon Linux2の場合:

python-websockifyx11vncx11vncバージョン0.9.13以降)をインストールするには、次のコマンドを実行します。

sudo pip3 install websockify
-  sudo yum install x11vnc
<!--NeedCopy-->

python-websockifyx11vncを解決するには、RHEL 7.xでExtra Packages for Enterprise Linux (EPEL)およびオプションのRPMリポジトリを有効にします。

  • EPEL

    EPELリポジトリはx11vncに必要です。EPELリポジトリを有効にするには、次のコマンドを実行します。

     yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
     <!--NeedCopy-->
    
  • オプションのRPM

    x11vncの一部の依存パッケージをインストールするために、オプションのRPMsリポジトリを有効にするには、次のコマンドを実行します。

     subscription-manager repos --enable rhel-7-server-optional-rpms --enable rhel-7-server-extras-rpms
     <!--NeedCopy-->
    

RHEL 8.xの場合:

python-websockifyx11vncx11vncバージョン0.9.13以降)をインストールするには、次のコマンドを実行します。

sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->

x11vncを解決するには、EPELおよびCodeReady Linux Builderリポジトリを有効にします。

dnf install -y --nogpgcheck https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

subscription-manager repos --enable "codeready-builder  -for-rhel-8-x86_64-rpms"
<!--NeedCopy-->

Ubuntuの場合:

python-websockifyx11vncx11vncバージョン0.9.13以降)をインストールするには、次のコマンドを実行します。

sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->

SUSEの場合:

python-websockifyx11vncx11vncバージョン0.9.13以降)をインストールするには、次のコマンドを実行します。

-  sudo pip3 install websockify
-  sudo zypper install x11vnc
<!--NeedCopy-->
  • Debianの場合:

python-websockifyx11vncx11vncバージョン0.9.13以降)をインストールするには、次のコマンドを実行します。

sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->

ポート

セッションシャドウイング機能は、Linux VDAからCitrix Directorへの接続を確立するために、6001~6099の範囲から利用可能なポートを自動的に選択します。そのため、同時にシャドウイングできるICAセッションの数は99に制限されます。特にマルチセッションシャドウイングの場合、要件を満たすのに十分なポートが利用可能であることを確認してください。

レジストリ

  • 次の表に関連するレジストリを示します。

  • レジストリ 説明 デフォルト値
  • | :———————————- | :—————————————————————– | :———– |
  • EnableSessionShadowing セッションシャドウイング機能を有効または無効にします 1 (有効)
  • ShadowingUseSSL Linux VDAとCitrix Director間の接続を暗号化するかどうかを決定します 0 (無効)

レジストリ値を変更するには、Linux VDAでctxregコマンドを実行します。例えば、セッションシャドウイングを無効にするには、次のコマンドを実行します。

/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "EnableSessionShadowing" -d 0x00000000

SSL

Linux VDAとCitrix Director間のnoVNC接続は、WebSocketプロトコルを使用します。セッションシャドウイングでは、ws://またはwss://のどちらを選択するかは、前述の「ShadowingUseSSL」レジストリによって異なります。デフォルトでは、ws://が選択されます。ただし、セキュリティ上の理由から、wss://を使用し、各Citrix Directorクライアントおよび各Linux VDAサーバーに証明書をインストールすることをお勧めします。Citrixは、ws://を使用したLinux VDAセッションシャドウイングに関するいかなるセキュリティ上の責任も負いません。

サーバーおよびルートSSL証明書の取得

証明書は、信頼された認証局 (CA) によって署名されている必要があります。

SSLを構成する各Linux VDAサーバーには、個別のサーバー証明書(キーを含む)が必要です。サーバー証明書は特定のコンピューターを識別するため、各サーバーの完全修飾ドメイン名 (FQDN) を知っている必要があります。代わりに、ドメイン全体にワイルドカード証明書を使用することもできます。この場合、少なくともドメイン名を知っている必要があります。

Linux VDAと通信する各Citrix Directorクライアントにもルート証明書が必要です。ルート証明書は、サーバー証明書を発行するのと同じCAから入手できます。

サーバー証明書とクライアント証明書は、以下のCAからインストールできます。

  • オペレーティングシステムにバンドルされているCA
  • エンタープライズCA(組織がアクセスを許可しているCA)
  • オペレーティングシステムにバンドルされていないCA

証明書を取得するために組織がどの方法を要求しているかについては、組織のセキュリティチームに相談してください。

重要:

  • サーバー証明書のコモンネームは、Linux VDAの正確なFQDNであるか、少なくとも正しいワイルドカードとドメイン文字である必要があります。例:vda1.basedomain.comまたは*.basedomain.com。
  • SHA1およびMD5を含むハッシュアルゴリズムは、一部のブラウザーがサポートするデジタル証明書の署名には弱すぎます。そのため、SHA-256が最小標準として指定されています。

各Citrix Directorクライアントへのルート証明書のインストール

セッションシャドウイングはIISと同じレジストリベースの証明書ストアを使用するため、IISまたはMicrosoft管理コンソール (MMC) の証明書スナップインを使用してルート証明書をインストールできます。CAから証明書を受け取ったら、IISでWebサーバー証明書ウィザードを再起動すると、ウィザードが証明書をインストールします。または、MMCを使用してコンピューター上の証明書を表示およびインポートし、証明書をスタンドアロンスナップインとして追加することもできます。Internet ExplorerとGoogle Chromeは、オペレーティングシステムにインストールされている証明書をデフォルトでインポートします。Mozilla Firefoxの場合、証明書マネージャーの「認証局」タブでルートSSL証明書をインポートする必要があります。

各Linux VDAサーバーへのサーバー証明書とそのキーのインストール

サーバー証明書には「shadowingcert.*」という名前を付け、キーファイルには「shadowingkey.*」という名前を付けます(*は形式を示します。例:shadowingcert.pemおよびshadowingkey.key)。サーバー証明書とキーファイルをパス /etc/xdl/shadowingssl の下に置き、制限された権限で適切に保護します。名前またはパスが正しくないと、Linux VDAは特定の証明書またはキーファイルを見つけることができず、その結果、Citrix Directorとの接続が失敗します。

使用方法

Citrix Directorから、ターゲットセッションを見つけ、「セッションの詳細」ビューで「シャドウ」をクリックして、Linux VDAにシャドウイング要求を送信します。

シャドウタブ

接続が初期化されると、ICAセッションクライアント(Citrix Directorクライアントではない)に確認メッセージが表示され、ユーザーにセッションをシャドウイングする許可を求めます。

管理者がこのセッションをシャドウイングすることを許可するかどうか

ユーザーが「はい」をクリックすると、Citrix Director側にウィンドウが表示され、ICAセッションがシャドウイングされていることを示します。

使用方法の詳細については、Citrix Directorドキュメントを参照してください。

制限事項

  • セッションシャドウイングは、イントラネット内でのみ使用するように設計されています。Citrix Gateway経由で接続する場合でも、外部ネットワークでは機能しません。Citrixは、外部ネットワークでのLinux VDAセッションシャドウイングに関するいかなる責任も負いません。
  • セッションシャドウイングが有効になっている場合、ドメイン管理者はICAセッションを表示することのみが可能であり、書き込みや制御の権限はありません。
  • 管理者がCitrix Directorから「シャドウ」をクリックすると、ユーザーにセッションをシャドウイングする許可を求める確認メッセージが表示されます。セッションは、セッションユーザーが許可を与えた場合にのみシャドウイングできます。
  • 前述の確認メッセージには20秒のタイムアウト制限があります。タイムアウトになると、シャドウイング要求は失敗します。
  • 1つのセッションは、1人の管理者のみがシャドウイングできます。たとえば、管理者Bが管理者Aがシャドウイングしているセッションに対してシャドウイング要求を送信した場合、ユーザーの許可を得るための確認メッセージがユーザーデバイスに再表示されます。ユーザーが同意すると、管理者Aのシャドウイング接続は停止し、管理者Bのために新しいシャドウイング接続が構築されます。管理者が同じセッションに対して別のシャドウイング要求を送信した場合でも、新しいシャドウイング接続を構築できます。
  • セッションシャドウイングを使用するには、Citrix Director 7.16以降をインストールします。
  • Citrix Directorクライアントは、ターゲットのLinux VDAサーバーに接続するためにIPアドレスではなくFQDNを使用します。したがって、Citrix DirectorクライアントはLinux VDAサーバーのFQDNを解決できる必要があります。

トラブルシューティング

セッションシャドウイングが失敗した場合は、Citrix DirectorクライアントとLinux VDAの両方でデバッグを行います。

Citrix Directorクライアントでの操作

ブラウザーの開発者ツールを使用して、「コンソール」タブで出力ログを確認します。または、「ネットワーク」タブでShadowLinuxSession APIの応答を確認します。ユーザー許可の確認メッセージが表示されるものの、接続の確立に失敗する場合は、VDAのFQDNを手動でpingして、Citrix DirectorがFQDNを解決できることを確認します。wss://接続に問題がある場合は、証明書を確認してください。

Linux VDAでの操作

シャドウイング要求に応答して、ユーザー許可の確認メッセージが表示されることを確認します。表示されない場合は、vda.logおよびhdx.logファイルで手がかりを探します。vda.logファイルを取得するには、次の手順を実行します。

  1. /etc/xdl/ctx-vda.confファイルを見つけます。vda.log構成を有効にするには、次の行のコメントを解除します。

    Log4jConfig="/etc/xdl/log4j.xml"

  2. /etc/xdl/log4j.xmlを開き、com.citrix.dmcの部分を見つけて、「info」を「trace」に次のように変更します。

     <!-- Broker Agent Plugin - Director VDA plugin Logger -->
    
      <logger name="com.citrix.dmc">
    
        <level value="trace"/>
    
      </logger>
    <!--NeedCopy-->
    
  3. service ctxvda restartコマンドを実行して、ctxvdaサービスを再起動します。

接続の確立中にエラーが発生した場合は、次の点を確認します。

  1. セッションシャドウイングがポートを開くのを妨げるファイアウォールの制限がないか確認します。
  2. SSLシナリオの場合、証明書とキーファイルに適切な名前を付け、正しいパスに配置していることを確認します。
  3. 新しいシャドウイング要求のために、6001~6099の間に十分なポートが残っていることを確認します。
シャドウセッション