セッションのシャドウ
セッションのシャドウにより、ドメイン管理者はイントラネット内のユーザーのICAセッションを閲覧できます。 この機能では、noVNCを使用してICAセッションに接続します。
注
この機能を使用するには、
Citrix Director7.16以降を使用してください。
インストールと構成
依存関係
セッションのシャドウには、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
<!--NeedCopy-->
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
<!--NeedCopy-->
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"
<!--NeedCopy-->
Ubuntuの場合：
python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールするには、次のコマンドを実行します：
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
SUSEの場合：
python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールするには、次のコマンドを実行します：
sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->
Debian 12の場合：
python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールするには、次のコマンドを実行します：
apt install python3-websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Debian 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に制限されています。 要件を満たすために、特にマルチセッションのシャドウ用に十分なポートがあることを確認してください。
レジストリ
次の表は、関連するレジストリの一覧です：
| レジストリ | 説明 | デフォルト値 |
|---|---|---|
| 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"
<!--NeedCopy-->
SSL
Linux VDAとCitrix Director間のnoVNC接続では、WebSocketプロトコルが使用されます。 セッションのシャドウの場合、ws://またはwss://のどちらが選択されるかは、前述の「ShadowingUseSSL」レジストリによって決まります。 デフォルトでは、ws://が選択されています。 ただし、セキュリティ上の理由から、wss://を使用して、各Citrix Directorクライアントと各Linux VDAサーバーに証明書をインストールすることをお勧めします。 ws://を使用したLinux VDAセッションのシャドウについては、Citrixはセキュリティ上のいかなる責任も負いません。
SSLを有効にするには、次のコマンドを実行します：
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->
サーバー証明書とルートSSL証明書を取得する
証明書には、信頼された証明機関（CA）による署名が必要です。
Linux VDAサーバーでSSLを設定する場合は、サーバーごとに個別のサーバー証明書（キーを含む）が必要です。 また、サーバー証明書によって各コンピューターが識別されるため、各サーバーの完全修飾ドメイン名（FQDN）を調べる必要があります。 便宜上、ドメイン全体にワイルドカード証明書を使用することを検討してください。
Linux VDAと通信するCitrix Directorクライアントごとにルート証明書も必要です。 ルート証明書は、サーバー証明書と同じ証明機関から入手できます。
次の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）の証明書スナップインを使用してルート証明書をインストールできます。 証明機関から証明書を取得したら、IISのサーバー証明書ウィザードを再び起動します。この操作により、自動的に証明書がインポートされます。 または、Microsoft管理コンソールの証明書スナップインで証明書を表示して、サーバーにインストールすることもできます。 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
<!--NeedCopy-->
使用状況
Citrix Directorからターゲットのセッションを見つけ、［セッション詳細］ ビューで ［シャドウ］ をクリックして、シャドウの要求をLinux VDAに送信します。
接続が初期化されると、ICAセッションクライアント（Citrix Directorクライアントではない）に確認メッセージが表示され、セッションをシャドウする許可がユーザーに求められます。
ユーザーが ［はい］ をクリックすると、ICAセッションがシャドウされていることを示すウィンドウがCitrix Director側で開きます。
使用方法について詳しくは、Citrix Directorのドキュメントを参照してください。
制限事項
- VDAがドメインに参加しており、認証にAzure Active Directory（AAD）を使用してMicrosoft Azure上でホストされている場合、セッションのシャドウ機能は動作しません。
- セッションのシャドウは、イントラネットでのみ使用するように設計されています。 Citrix Gatewayを介して接続する場合でも、外部ネットワークでは機能しません。 外部ネットワークでのLinux VDAセッションのシャドウについては、Citrixはいかなる責任も負いません。
- セッションのシャドウを有効にすると、ドメイン管理者はICAセッションのみを表示できますが、書き込みの権限や制御する権限はありません。
- 管理者が
Citrix Directorから ［シャドウ］ をクリックすると、セッションをシャドウする許可をユーザーに求める確認メッセージが表示されます。 セッションユーザーが許可を与えた場合にのみ、セッションをシャドウできます。 - 前述の確認メッセージには、20秒のタイムアウト制限があります。 タイムアウトになると、シャドウの要求は失敗します。
- 1つのセッションは、1人の管理者だけがシャドウできます。 たとえば、セッション管理者Aがシャドウしている場合に、管理者Bがシャドウ要求を送信すると、ユーザーの許可を取得するための確認がユーザーデバイスに再度表示されます。 ユーザーが同意すると、管理者Aのシャドウ接続は停止され、管理者Bに対して新しいシャドウ接続が構築されます。 ある管理者が同じセッションに対して別のシャドウ要求を送信すると、また新しいシャドウ接続を構築できます。
- セッションのシャドウを使用するには、
Citrix Director7.16以降をインストールしてください。 -
Citrix Directorクライアントは、IPアドレスではなくFQDNを使用して、ターゲットのLinux VDAサーバーに接続します。 したがって、Citrix Directorクライアントは、Linux VDAサーバーのFQDNを解決できる必要があります。
トラブルシューティング
セッションのシャドウが失敗した場合は、Citrix DirectorクライアントとLinux VDAの両方でデバッグを実行します。
Citrix Directorクライアントの場合
Webブラウザーの開発ツールを使用して、［コンソール］ タブの出力ログを確認します。 または、［ネットワーク］ タブでShadowLinuxSession APIの応答を確認します。 ユーザー権限を取得するための確認が表示されても接続が確立されない場合は、VDAのFQDNを手動でpingして、Citrix DirectorがFQDNを解決できることを確認します。 wss://接続で問題が発生した場合は、証明書を確認してください。
Linux VDAの場合
-
手がかりについては、
/var/log/xdl/vda.logファイルを確認してください。 -
/var/xdl/sessionshadowing.shファイルを編集し、「logFile」変数を変更して、Directorからのセッションのシャドウ時に手がかりを探すために追跡できるログファイルを指定します。 -
また、証明書がnoVNC接続で正しく動作するかどうかを手動で確認することもできます：
-
ps aux | grep xorgを実行して、現在のセッションのXorgディスプレイ番号$display-numを見つけます（例：:3）。
-
次のコマンドを実行して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--> -
次のようにnoVNCを使用して接続し、SSLモードを確認します。 VDAのFQDNとポート番号を入力します。 この例では、ポート番号は6009です。
-
VDA上のWebsockifyによって印刷されたエラー、またはクライアント上のブラウザーによって報告されたエラーを解決します。
接続確立時の主なチェックポイント：
- セッションのシャドウがポートを開くのを止めるファイアウォール制限がないか確認します。
- SSLシナリオの場合、証明書とキーファイルの名前が正しく指定され、正しいパスに置かれていることを確認します。
- 新しいシャドウ要求で使用するための十分なポートが、6001〜6099の間に残っていることを確認します。
-
/var/xdl/sessionshadowing.shに必要なため、「netstat」がインストールされていることを確認してください。 -
openssl x509 -in shadowingcert.pem -text -nooutを実行して、CNフィールドとSANフィールドに特に注意しながら、証明書が正しく構成されていることを確認します。 -
RHEL 8では、
rebind.soが見つからないという問題が発生する可能性があります。 この問題を解決するには、次のコマンドを実行します：ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so <!--NeedCopy-->
-