セッションのシャドウ
セッションのシャドウ機能により、ドメイン管理者はイントラネット内のユーザーのICAセッションを閲覧できます。この機能は、noVNCを使用してICAセッションに接続し、RHEL 7.xとUbuntu 16.04でのみサポートされています。
注：
セッションのシャドウ機能を使用するには、Citrix Directorのバージョンを7.16以降にする必要があります。
インストールと構成
依存関係
セッションのシャドウには、python-websockifyとx11vncという、2つの新しい依存関係が必要です。python-websockifyとx11vncの依存関係は、Ubuntu 16.04にLinux VDAをインストールすると自動的にインストールされます。RHEL 7.xでは、Linux VDAをインストールした後に、python-websockifyとx11vncを手動でインストールする必要があります。
RHEL 7.xでpython-websockifyとx11vnc（x11vncバージョン0.9.13以降）をインストールするには、次のコマンドを実行します。
sudo yum install -y python-websockify x11vnc
<!--NeedCopy-->
python-websockifyとx11vncを解決するには、RHEL 7.x上で次のリポジトリを有効にします：
-
Extra Packages for Enterprise Linux (EPEL)
python-websockifyとx11vncの両方にEPELリポジトリが必要です。次のコマンドを実行して、EPELリポジトリを有効にします：sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E '%{rhel}').noarch.rpm <!--NeedCopy--> -
オプションのRPM
x11vncの依存パッケージをインストールするために、オプションのRPMリポジトリを有効にするには、次のいずれかのコマンドを実行します。
ワークステーションの場合：
subscription-manager repos --enable=rhel-7-workstation-optional-rpms <!--NeedCopy-->サーバーの場合：
subscription-manager repos --enable=rhel-7-server-optional-rpms <!--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://が選択されています。ただし、セキュリティ上の理由から、Citrixは、wss://を使用して各Citrix Directorクライアントと各Linux VDAサーバーに証明書をインストールすることをお勧めします。ws://を使用したLinux VDAセッションのシャドウについては、シトリックスはセキュリティ上のいかなる責任も負いません。
サーバー証明書とルートSSL証明書を取得する
証明書には、信頼された証明機関（CA）による署名が必要です。
Linux VDAサーバーでSSLを設定する場合は、サーバーごとに個別のサーバー証明書（キーを含む）が必要です。また、サーバー証明書によって各コンピューターが識別されるため、各サーバーの完全修飾ドメイン名（FQDN）を調べる必要があります。便宜上、代わりにドメイン全体にワイルドカード証明書を使用できます。この場合、少なくともドメイン名を知っておく必要があります。
各サーバーにサーバー証明書をインストールするだけでなく、Linux VDAサーバーを使用して通信を行う各Citrix Directorクライアントに、同じ証明機関が発行するルート証明書をインストールする必要があります。ルート証明書は、サーバー証明書と同じ証明機関から入手できます。サーバー証明書とクライアント証明書は、オペレーティングシステムに組み込まれている証明機関、社内証明機関（社内で構築する証明機関）、またはオペレーティングシステムに組み込まれていない証明機関のものをインストールできます。証明書を取得するためにどの手段を取るべきかについては、社内のセキュリティ担当部門に問い合わせてください。
重要：
- サーバー証明書の共通名は、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.csrや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セッションのシャドウについて、シトリックスではいかなる責任も負いません。
- セッションのシャドウを有効にすると、ドメイン管理者はICAセッションのみを表示できますが、書き込みの権限や制御する権限はありません。
- 管理者がCitrix Directorから ［シャドウ］ をクリックすると、セッションをシャドウする許可をユーザーに求める確認メッセージが表示されます。セッションユーザーが許可を与えた場合にのみ、セッションをシャドウできます。
- 前述の確認メッセージには、20秒のタイムアウト制限があります。タイムアウトになると、シャドウの要求は失敗します。
- 各ICAセッションは、1つのCitrix Directorウィンドウで、1人の管理者だけがシャドウできます。ICAセッションが管理者Aによってシャドウされていて、その間に管理者Bがシャドウ要求を送信した場合、ユーザーの許可を取得するための確認がユーザーデバイスに再度表示されます。ユーザーが同意すると、管理者Aのシャドウ接続は停止され、管理者Bに対して新しいシャドウ接続が構築されます。同じ管理者によって同じICAセッションの別のシャドウ要求が送信された場合も同じです。
- セッションのシャドウを使用するには、Citrix Director 7.16以降をインストールしてください。
- Citrix Directorクライアントは、IPアドレスではなくFQDNを使用して、ターゲットのLinux VDAサーバーに接続します。したがって、Citrix Directorクライアントは、Linux VDAサーバーのFQDNを解決できる必要があります。
トラブルシューティング
セッションのシャドウが失敗した場合は、Citrix DirectorクライアントとLinux VDAの両方でデバッグを実行します。
Citrix Directorクライアントの場合
Webブラウザーの開発ツールを使用して、［コンソール］ タブの出力ログを確認します。または、［ネットワーク］ タブでShadowLinuxSession APIの応答を確認します。ユーザーの許可を取得するための確認が表示されても接続が確立されない場合は、Linux 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の間に残っていることを確認します。