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

最終公開日 : Nov 13, 2026
セッションシャドウイングを使用すると、ドメイン管理者はイントラネットでユーザーのICA®セッションを表示できます。この機能はnoVNCを使用してICAセッションに接続します。
注:
この機能を使用するには、Citrix Director 7.16以降を使用してください。
Related information
管理

インストールと構成

依存関係

セッションシャドウイングには、python-websockify と x11vnc の2つの新しい依存関係が必要です。Linux VDAのインストール後に、python-websockify と x11vnc を手動でインストールしてください。
Amazon Linux2の場合：
python-websockify と x11vnc (x11vnc バージョン0.9.13以降) をインストールするには、次のコマンドを実行します。
sudo pip3 install websockify
sudo yum install x11vnc
RHEL 9.x/8.x および Rocky Linux 9.x/8.x の場合:
python-websockify と x11vnc (x11vnc バージョン0.9.13以降) をインストールするには、次のコマンドを実行します。
sudo pip3 install websockify
sudo yum install x11vnc
EPELおよびCodeReady Linux Builderリポジトリを有効にして、x11vnc を解決します。
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"
Ubuntuの場合：
python-websockify と x11vnc (x11vnc バージョン0.9.13以降) をインストールするには、次のコマンドを実行します。
sudo pip3 install websockify
sudo apt-get install x11vnc
SUSEの場合：
python-websockify と x11vnc (x11vnc バージョン0.9.13以降) をインストールするには、次のコマンドを実行します。
sudo pip3 install websockify
sudo zypper install x11vnc
Debian 12の場合：
python-websockify と x11vnc (x11vnc バージョン 0.9.13 以降) をインストールするには、次のコマンドを実行します。
apt install python3-websockify
sudo apt-get install x11vnc
Debian 11 の場合:
python-websockify と x11vnc (x11vnc バージョン 0.9.13 以降) をインストールするには、次のコマンドを実行します。
sudo pip3 install websockify
sudo apt-get install x11vnc

ポート

セッションシャドウイング機能は、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 を有効にするには、次のコマンドを実行します。
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"

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

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

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

使用方法

Citrix Director から、ターゲットセッションを見つけ、セッションの詳細ビューで をクリックして、Linux VDAにシャドウ要求を送信します。
シャドウタブ
接続が初期化されると、ICAセッションクライアント（Citrix Director クライアントではない）に確認が表示され、ユーザーにセッションのシャドウを許可するかどうかを尋ねます。
管理者がこのセッションをシャドウすることを許可するかどうか
ユーザーが をクリックすると、Citrix Director 側にウィンドウが表示され、ICAセッションがシャドウされていることを示します。
使用方法の詳細については、Citrix Directorドキュメント を参照してください。

制限事項

  • 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の両方でデバッグを行ってください。

Citrix Directorクライアントで

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

Linux VDA で

  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"
    3. 次のようにnoVNCを使用して接続を試み、SSLモードを確認します。VDAのFQDNとポート番号を入力します。この例では、ポート番号は6009です。
      noVNCを使用して接続
    4. VDA上のWebsockifyによって出力されたエラー、またはクライアント上のブラウザによって報告されたエラーを解決します。
      接続確立中の主要なチェックポイント:
      1. セッションシャドウイングがポートを開くのを妨げるファイアウォールの制限がないか確認します。
      2. SSLシナリオの場合、証明書とキーファイルに適切に名前を付け、正しいパスに配置したことを確認します。
      3. 新しいシャドウイング要求のために、6001～6099の間に十分なポートが残っていることを確認します。
      4. 「netstat」がインストールされていることを確認します。これは/var/xdl/sessionshadowing.shによって必要とされるためです。
      5. openssl x509 -in shadowingcert.pem -text -nooutを実行して、証明書が正しく構成されていることを確認します。特にCNフィールドとSANフィールドに注意してください。
      6. RHEL 8では、rebind.soが見つからないという問題が発生する可能性があります。この問題を解決するには、次のコマンドを実行します。
        ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so