セッションシャドウイング

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

注：

この機能を使用するには、Citrix Director 7.16以降を使用してください。

インストールと構成

依存関係

セッションシャドウイングには、python-websockifyとx11vncという2つの新しい依存関係が必要です。Linux VDAのインストール後に、python-websockifyとx11vncを手動でインストールしてください。

アマゾン リナックス2の場合:

次のコマンドを実行して、python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールします。

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

RHEL 9.x/8.xおよびロッキー リナックス 9.x/8.xの場合:

次のコマンドを実行して、python-websockifyとx11vnc（x11vncバージョン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-->

ウブントゥの場合:

次のコマンドを実行して、python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールします。

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

SUSEの場合：

まず、ヤーストまたは以下のスーゼコネクトコマンドのいずれかを使用して、「SUSE Linux Enterprise Workstation Extension 15 SP6」モジュールを有効にします。

suseconnect -p sle-we/15.6/x86_64 -r <regcode>
<!--NeedCopy-->

詳細については、SUSEドキュメントを参照してください: https://documentation.suse.com/ja-jp/sles/15-SP6/html/SLES-all/article-modules.html。

次に、以下のコマンドを実行して、python-websockify と x11vnc (x11vnc バージョン 0.9.13 以降) をインストールします。

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

デビアン 12の場合:

以下のコマンドを実行して、python-websockify と x11vnc (x11vnc バージョン 0.9.13 以降) をインストールします。

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

デビアン 11の場合:

以下のコマンドを実行して、python-websockify と x11vnc (x11vnc バージョン 0.9.13 以降) をインストールします。

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

ポート

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

レジストリ

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

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

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

SSL

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

SSLを有効にするには、次のコマンドを実行します。

/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->

サーバーおよびルート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 が最低基準として指定されています。
• Chrome は自己署名 SSL 証明書を安全でないとみなし、受け入れなくなりました。生成された証明書に SAN (subjectAltName) フィールドがないため、NET::ERR_CERT_COMMON_NAME_INVALID エラーが発生します。この問題を解決するには、SAN フィールドを含む拡張属性 (X509 v3 拡張) を持つ証明書を提供してください。

各 Citrix Director クライアントにルート証明書をインストールする

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

各 Linux VDA サーバーにサーバー証明書とそのキーをインストールする

サーバー証明書には「shadowingcert.*」、キーファイルには「shadowingkey.*」という名前を付けます（* は形式を示します。例: shadowingcert.pem および shadowingkey.key）。サーバー証明書とキーファイルをパス /etc/xdl/shadowingssl の下に置き、ctxsrvr のみに読み取りアクセスを許可する制限された権限で適切に保護します。名前またはパスが正しくないと、Linux VDA は特定の証明書またはキーファイルを見つけることができず、その結果、Citrix Director で接続障害が発生します。コマンドは次のとおりです。

cp <vda's-public-key> /etc/xdl/shadowingssl/shadowingcert.pem
cp <vda's-server-private-key> /etc/xdl/shadowingssl/shadowingkey.key
sudo chown ctxsrvr:ctxadm  /etc/xdl/shadowingssl/shadowingcert.pem
sudo chown ctxsrvr:ctxadm  /etc/xdl/shadowingssl/shadowingkey.key
<!--NeedCopy-->

使用法

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

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

管理者がこのセッションをシャドウすることを許可するかどうか(/ja-jp/linux-virtual-delivery-agent/2511/media/allow-administrator-to-shadow-session.png)

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

使用方法の詳細については、Citrix Director Documentationを参照してください。

制限事項

• VDAがドメインに参加しており、認証にAzure Active Directory (AAD)を使用してMicrosoft Azureでホストされている場合、セッションシャドウ機能は動作しません。
• セッションシャドウはイントラネット内でのみ使用するように設計されています。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の両方でデバッグを行ってください。

シトリックス ディレクター クライアントで

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

リナックス ブイディーエー上で

1. /var/log/xdl/vda.logファイルで手がかりを確認します。

2. /var/xdl/sessionshadowing.shファイルを編集し、「logFile」変数を変更して、ディレクターからのセッションシャドウイング中に手がかりを追跡できるログファイルを指定します。

3. また、noVNC接続で証明書が正しく機能するかどうかを手動で確認することもできます。

   1. ps aux | grep xorgを実行して、現在のセッションのXorgディスプレイ番号$display-num（例: :3）を見つけます。

   2. 次のコマンドを実行してx11vncサーバーを起動し、着信接続を待ちます。

      注:

      次のコマンドを実行する前に、$passwd、$port、$display-num変数を設定します。

      runuser -l "ctxsrvr" -s /bin/bash -c "websockify <port> -v --cert  /etc/xdl/shadowingssl/shadowingcert.pem --key  /etc/xdl/shadowingssl/shadowingkey.key -- x11vnc  -viewonly  -shared -passwd $passwd -rfbport $port -display $display-num -many -o /var/log/xdl/x11vnc.log"
      <!--NeedCopy-->
      

   3. noVNCを使用してSSLモードを確認するには、次のように接続を試行します。VDAのFQDNとポート番号を入力します。この例では、ポート番号は6009です。

      

   4. VDA上のWebsockifyによって出力されたエラー、またはクライアント上のブラウザによって報告されたエラーを解決します。

      接続確立中の主要なチェックポイント:

      1. セッションシャドウイングがポートを開くのを妨げるファイアウォール制限がないか確認します。
      2. SSLシナリオの場合、証明書とキーファイルに適切に名前を付け、正しいパスに配置したことを確認します。
      3. 新しいシャドウイング要求のために、6001～6099の間で十分なポートが残っていることを確認します。
      4. openssl x509 -in shadowingcert.pem -text -nooutを実行し、証明書が正しく構成されていることを確認します。特にCNフィールドとSANフィールドに注意してください。

      5. RHEL 8では、rebind.soが見つからないという問題が発生する可能性があります。この問題を解決するには、次のコマンドを実行します。

         ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so
         <!--NeedCopy-->