セッションシャドウイング
セッションシャドウイングを使用すると、ドメイン管理者はイントラネット内でユーザーのICA®セッションを表示できます。この機能はnoVNCを使用してICAセッションに接続します。
注:
この機能を使用するには、
Citrix Director7.16以降を使用してください。
インストールと構成
依存関係
セッションシャドウイングには、python-websockifyとx11vncという2つの新しい依存関係が必要です。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-->
(RHEL 7.xの場合) Extra Packages for Enterprise Linux（EPEL）およびオプションのRPMリポジトリを有効にして、python-websockifyとx11vncを解決します。
-
EPEL
EPELリポジトリは
x11vncに必要です。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 9.2/9.0/8.xおよびRocky Linux 9.2/9.0/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の場合:
-
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サーバーに証明書をインストールすることをお勧めします。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
証明書を取得するために組織がどの方法を要求しているかについては、組織のセキュリティチームに相談してください。
重要:
- サーバー証明書の共通名 (Common Name) は、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 の場合は、証明書マネージャーの [認証局] タブでルート SSL 証明書をインポートする必要があります。
各 Linux VDA サーバーへのサーバー証明書とそのキーのインストール
サーバー証明書には「shadowingcert.*」、キーファイルには「shadowingkey.*」という名前を付けます (* は形式を示します。たとえば、shadowingcert.pem および shadowingkey.key)。サーバー証明書とキーファイルをパス /etc/xdl/shadowingssl の下に置き、制限された権限で適切に保護してください。名前またはパスが正しくないと、Linux VDA は特定の証明書またはキーファイルを見つけることができず、その結果 Citrix Director との接続が失敗します。
使用方法
Citrix Director から、ターゲットセッションを見つけ、[セッションの詳細] ビューで [シャドウ] をクリックして、Linux VDA にシャドウイング要求を送信します。
接続が初期化されると、ICA セッションクライアント (``Citrix Director` クライアントではない) に確認が表示され、ユーザーにセッションをシャドウイングする許可を求めます。
ユーザーが [はい] をクリックすると、``Citrix Director` 側にウィンドウが表示され、ICA セッションがシャドウイングされていることを示します。
使用方法の詳細については、Citrix Director ドキュメントを参照してください。
制限事項
- セッションシャドウイングは、イントラネット内でのみ使用するように設計されています。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 での操作
-
/var/log/xdl/vda.logファイルで手がかりを確認します。 -
/var/xdl/sessionshadowing.shファイルを編集し、「logFile」変数を変更して、Director からのセッションシャドウイング中に手がかりを追跡できるログファイルを指定します。 -
また、noVNC 接続で証明書が正しく機能するかどうかを手動で確認することもできます。
-
ps aux | grep xorg を実行して、現在のセッションの Xorg ディスプレイ番号
<display-num>(例::3) を見つけます。 -
次のコマンドを実行して x11vnc サーバーを起動し、受信接続を待ちます。
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-->
-