セッションのシャドウ
セッションのシャドウ機能により、ドメイン管理者はイントラネット内のユーザーのICAセッションを閲覧できます。この機能では、noVNCを使用してICAセッションに接続します。
注：
セッションのシャドウ機能を使用するには、
Citrix Director7.16以降を使用してください。
インストールと構成
依存関係
セッションのシャドウには、python-websockifyとx11vncという、2つの新しい依存関係が必要です。python-websockifyとx11vncの依存関係は、Ubuntu 16.04にLinux VDAをインストールすると自動的にインストールされます。サポートされている他のディストリビューションでは、Linux VDAをインストールした後に、python-websockifyとx11vncを手動でインストールする必要があります。
RHEL 7.xおよびAmazon Linux2の場合：
python-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールするには、次のコマンドを実行します：
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
python-websockifyとx11vncを解決するには、RHEL 7.xでExtra Packages for Enterprise Linux（EPEL）とオプションのRPMリポジトリを有効にします：
-
EPEL
x11vncにはEPELリポジトリが必要です。次のコマンドを実行して、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-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-->
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の場合：
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
SSL
Linux VDAとCitrix Director間のnoVNC接続では、WebSocketプロトコルが使用されます。セッションのシャドウの場合、ws://とwss://のどちらが選択されるかは、前述の「ShadowingUseSSL」レジストリによって決まります。デフォルトでは、ws://が選択されています。ただし、セキュリティ上の理由から、wss://を使用して、各Citrix Directorクライアントと各Linux VDAサーバーに証明書をインストールすることをお勧めします。ws://を使用したLinux VDAセッションのシャドウについては、Citrixはセキュリティ上のいかなる責任も負いません。
サーバー証明書とルート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が最低基準として指定されています。
各Citrix Directorクライアントにルート証明書をインストールする
セッションのシャドウとIISで、同じレジストリベースの証明書ストアを使用するため、IISまたはMicrosoft管理コンソール（MMC）の証明書スナップインを使用してルート証明書をインストールできます。証明機関から証明書を取得したら、IISのサーバー証明書ウィザードを再び起動します。この操作により、自動的に証明書がインポートされます。または、Microsoft管理コンソールの証明書スナップインで証明書を表示して、サーバーにインストールすることもできます。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クライアントではない）に確認メッセージが表示され、セッションをシャドウする許可がユーザーに求められます。
ユーザーが ［はい］ をクリックすると、ICAセッションがシャドウされていることを示すウィンドウがCitrix Director側で開きます。
使用方法について詳しくは、Citrix Directorのドキュメントを参照してください。
制限事項
- セッションのシャドウは、イントラネットでのみ使用するように設計されています。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の場合
シャドウ要求に応答して、ユーザーの許可を取得するための確認が表示されることを確認します。表示されない場合は、vda.logファイルとhdx.logファイルを調べてください。vda.logファイルを取得するには、次の操作を実行します：
-
/etc/xdl/ctx-vda.confファイルを見つけます。vda.logの構成を有効にするには、次の行のコメントを外します：
Log4jConfig="/etc/xdl/log4j.xml" -
/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--> -
service ctxvda restartコマンドを実行して、ctxvdaサービスを再起動します。
接続確立中にエラーが発生した場合は、次の操作を実行してください：
- セッションのシャドウがポートを開くのを止めるファイアウォール制限がないか確認します。
- SSLシナリオの場合、証明書とキーファイルの名前が正しく指定され、正しいパスに置かれていることを確認します。
- 新しいシャドウ要求で使用するための十分なポートが、6001〜6099の間に残っていることを確認します。