Sitzungs-Shadowing

Last published : Nov 13, 2026
Das Shadowing von Sitzungen ermöglicht Domänenadministratoren, die ICA®-Sitzungen von Benutzern in einem Intranet anzuzeigen. Die Funktion verwendet noVNC, um eine Verbindung zu den ICA-Sitzungen herzustellen.
Hinweis:
Um die Funktion zu verwenden, verwenden Sie Citrix Director 7.16 oder höher.
Related information
Verwaltung

Installation und Konfiguration

Abhängigkeiten

Zwei neue Abhängigkeiten, python-websockify und x11vnc, sind für das Sitzungs-Shadowing erforderlich. Installieren Sie python-websockify und x11vnc manuell, nachdem Sie den Linux VDA installiert haben.
Für Amazon Linux2:
Führen Sie die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren:
sudo pip3 install websockify
sudo yum install x11vnc
Für RHEL 9.x/8.x und Rocky Linux 9.x/8.x:
Führen Sie die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren.
sudo pip3 install websockify
sudo yum install x11vnc
Beheben Sie x11vnc, indem Sie die EPEL- und CodeReady Linux Builder-Repositorys aktivieren:
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"
Für Ubuntu:
Führen Sie die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren:
sudo pip3 install websockify
sudo apt-get install x11vnc
Für SUSE:
Aktivieren Sie zunächst das Modul „SUSE Linux Enterprise Workstation Extension 15 SP6“ entweder mit YaST oder dem folgenden Befehl SUSEConnect:
suseconnect -p sle-we/15.6/x86_64 -r <regcode>
Weitere Informationen finden Sie in der SUSE-Dokumentation: <https://documentation.suse.com/de-de/sles/15-SP6/html/SLES-all/article-modules.html>.
Führen Sie dann die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren:
sudo pip3 install websockify
sudo zypper install x11vnc
Für Debian 12:
Führen Sie die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren:
apt install python3-websockify
sudo apt-get install x11vnc
Für Debian 11:
Führen Sie die folgenden Befehle aus, um python-websockify und x11vnc (x11vnc Version 0.9.13 oder höher) zu installieren:
sudo pip3 install websockify
sudo apt-get install x11vnc

Port

Die Sitzungsschattenfunktion wählt automatisch verfügbare Ports aus dem Bereich 6001-6099 aus, um Verbindungen vom Linux VDA zu Citrix Director aufzubauen. Daher ist die Anzahl der ICA-Sitzungen, die Sie gleichzeitig schatten können, auf 99 begrenzt. Stellen Sie sicher, dass genügend Ports verfügbar sind, um Ihre Anforderungen zu erfüllen, insbesondere für das Schatten von Mehrfachsitzungen.

Registrierung

Die folgende Tabelle listet die zugehörigen Registrierungseinträge auf:
Registrierung Beschreibung Standardwert
EnableSessionShadowing Aktiviert oder deaktiviert die Sitzungsschattenfunktion 1 (Aktiviert)
ShadowingUseSSL Legt fest, ob die Verbindung zwischen dem Linux VDA und Citrix Director verschlüsselt werden soll 0 (Deaktiviert)
Führen Sie den Befehl ctxreg auf dem Linux VDA aus, um die Registrierungswerte zu ändern. Um beispielsweise das Sitzungsschatten zu deaktivieren, führen Sie den folgenden Befehl aus:
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "EnableSessionShadowing" -d "0x00000000"

SSL

Die noVNC-Verbindung zwischen dem Linux VDA und Citrix Director verwendet das WebSocket-Protokoll. Für die Sitzungsschattenfunktion hängt die Wahl zwischen ws:// und wss:// von der zuvor erwähnten Registrierung „ShadowingUseSSL“ ab. Standardmäßig wird ws:// gewählt. Aus Sicherheitsgründen empfehlen wir jedoch die Verwendung von wss:// und die Installation von Zertifikaten auf jedem Citrix Director-Client und auf jedem Linux VDA-Server. Citrix lehnt jegliche Sicherheitsverantwortung für die Linux VDA-Sitzungsschattenfunktion bei Verwendung von ws:// ab.
Führen Sie den folgenden Befehl aus, um SSL zu aktivieren:
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"

Server- und Root-SSL-Zertifikate abrufen

Zertifikate müssen von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert sein.
Für jeden Linux VDA-Server, auf dem Sie SSL konfigurieren möchten, ist ein separates Serverzertifikat (einschließlich des Schlüssels) erforderlich. Ein Serverzertifikat identifiziert einen bestimmten Computer, daher müssen Sie den vollqualifizierten Domänennamen (FQDN) jedes Servers kennen. Erwägen Sie der Einfachheit halber die Verwendung eines Wildcard-Zertifikats für die gesamte Domäne.
Ein Root-Zertifikat ist auch für jeden Citrix Director-Client erforderlich, der mit dem Linux VDA kommuniziert. Root-Zertifikate sind von denselben Zertifizierungsstellen erhältlich, die auch die Serverzertifikate ausstellen.
Sie können Server- und Clientzertifikate von den folgenden Zertifizierungsstellen installieren:
  • Eine CA, die mit Ihrem Betriebssystem gebündelt ist
  • Eine Unternehmens-CA (eine CA, die Ihre Organisation Ihnen zugänglich macht)
  • Eine CA, die nicht mit Ihrem Betriebssystem gebündelt ist
Wenden Sie sich an das Sicherheitsteam Ihrer Organisation, um herauszufinden, welche der Methoden sie für den Erhalt von Zertifikaten vorschreiben.
Wichtig:
  • Der Common Name für ein Serverzertifikat muss der exakte FQDN des Linux VDA oder zumindest der korrekte Wildcard plus Domänenzeichen sein. Zum Beispiel vda1.basedomain.com oder *.basedomain.com.
  • Hashing-Algorithmen wie SHA1 und MD5 sind für Signaturen in digitalen Zertifikaten zu schwach, um von einigen Browsern unterstützt zu werden. Daher ist SHA-256 als Mindeststandard festgelegt.
  • Chrome akzeptiert keine selbstsignierten SSL-Zertifikate mehr, da diese als unsicher gelten. Der Fehler NET::ERR_CERT_COMMON_NAME_INVALID tritt auf, weil dem generierten Zertifikat das SAN-Feld (subjectAltName) fehlt. Um dieses Problem zu beheben, stellen Sie ein Zertifikat mit erweiterten Attributen (X509 v3-Erweiterungen) bereit, das das SAN-Feld enthält.

Ein Root-Zertifikat auf jedem Citrix Director-Client installieren

Sitzungsschatten verwendet denselben registrierungsbasierten Zertifikatsspeicher wie IIS, sodass Sie Stammzertifikate mithilfe von IIS oder dem Microsoft Management Console (MMC)-Zertifikate-Snap-In installieren können. Wenn Sie ein Zertifikat von einer Zertifizierungsstelle erhalten, können Sie den Assistenten für Webserverzertifikate in IIS neu starten, und der Assistent installiert das Zertifikat. Alternativ können Sie Zertifikate auf dem Computer mithilfe der MMC anzeigen und importieren und das Zertifikat als eigenständiges Snap-In hinzufügen. Internet Explorer und Google Chrome importieren die auf Ihrem Betriebssystem installierten Zertifikate standardmäßig. Für Mozilla Firefox müssen Sie Ihre Stamm-CA-Zertifikate auf der Registerkarte Zertifizierungsstellen des Zertifikat-Managers importieren.

Installieren Sie ein Serverzertifikat und dessen Schlüssel auf jedem Linux-VDA-Server

Benennen Sie die Serverzertifikate „shadowingcert.*“ und die Schlüsseldatei „shadowingkey.*“ (* gibt das Format an, z. B. shadowingcert.pem und shadowingkey.key). Legen Sie Serverzertifikate und Schlüsseldateien unter dem Pfad /etc/xdl/shadowingssl ab und schützen Sie sie ordnungsgemäß mit eingeschränkten Berechtigungen, sodass nur ctxsrvr Lesezugriff hat. Ein falscher Name oder Pfad führt dazu, dass der Linux-VDA eine bestimmte Zertifikats- oder Schlüsseldatei nicht finden kann und somit einen Verbindungsfehler mit Citrix Director verursacht. Die Befehle lauten wie folgt:
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

Verwendung

Suchen Sie in Citrix Director die Ziel-Sitzung und klicken Sie in der Ansicht Sitzungsdetails auf Shadow, um eine Shadowing-Anfrage an den Linux-VDA zu senden.
Nachdem die Verbindung initialisiert wurde, wird eine Bestätigung auf dem ICA-Sitzungsclient (nicht auf dem Citrix Director-Client) angezeigt, um den Benutzer um Erlaubnis zu bitten, die Sitzung zu schatten.
Ob ein Administrator diese Sitzung schatten darf
Wenn der Benutzer auf Ja klickt, wird ein Fenster auf der Citrix Director-Seite angezeigt, das anzeigt, dass die ICA-Sitzung geschattet wird.
Weitere Informationen zur Verwendung finden Sie in der Citrix Director-Dokumentation.

Einschränkungen

  • Wenn Ihre VDAs einer Domäne beigetreten sind und auf Microsoft Azure gehostet werden, wobei Azure Active Directory (AAD) zur Authentifizierung verwendet wird, funktioniert die Sitzungsschatten-Funktion nicht.
  • Sitzungsschatten ist nur für die Verwendung in einem Intranet konzipiert. Es funktioniert nicht für externe Netzwerke, selbst wenn die Verbindung über Citrix Gateway hergestellt wird. Citrix lehnt jegliche Verantwortung für das Linux-VDA-Sitzungsschatten in einem externen Netzwerk ab.
  • Wenn Sitzungsschatten aktiviert ist, kann ein Domänenadministrator die ICA-Sitzungen nur anzeigen, hat aber keine Berechtigung, sie zu schreiben oder zu steuern.
  • Nachdem ein Administrator in Citrix Director auf Shadow geklickt hat, wird eine Bestätigung angezeigt, um den Benutzer um Erlaubnis zu bitten, die Sitzung zu schatten. Eine Sitzung kann nur geschattet werden, wenn der Sitzungsbenutzer die Erlaubnis erteilt.
  • Die zuvor erwähnte Bestätigung hat eine Zeitüberschreitungsbegrenzung, die 20 Sekunden beträgt. Eine Shadowing-Anfrage schlägt fehl, wenn die Zeit abläuft.
  • Eine Sitzung kann nur von einem Administrator geschattet werden. Wenn beispielsweise Administrator B eine Shadowing-Anfrage für eine Sitzung sendet, die Administrator A schattet, wird die Bestätigung zur Einholung der Benutzererlaubnis erneut auf dem Benutzergerät angezeigt. Wenn der Benutzer zustimmt, wird die Shadowing-Verbindung für Administrator A beendet und eine neue Shadowing-Verbindung für Administrator B aufgebaut. Wenn ein Administrator eine weitere Shadowing-Anfrage für dieselbe Sitzung sendet, kann ebenfalls eine neue Shadowing-Verbindung aufgebaut werden.
  • Um Session Shadowing zu verwenden, installieren Sie Citrix Director 7.16 oder höher.
  • Ein Citrix Director Client verwendet einen FQDN anstelle einer IP-Adresse, um eine Verbindung zum Ziel-Linux-VDA-Server herzustellen. Daher muss der Citrix Director Client den FQDN des Linux-VDA-Servers auflösen können.

Problembehandlung

Wenn Session Shadowing fehlschlägt, führen Sie das Debugging sowohl auf dem Citrix Director Client als auch auf dem Linux VDA durch.

Auf dem Citrix Director Client

Über die Entwicklertools des Browsers überprüfen Sie die Ausgabeprotokolle auf der Registerkarte Konsole. Oder überprüfen Sie die Antwort der ShadowLinuxSession-API auf der Registerkarte Netzwerk. Wenn die Bestätigung zum Abrufen der Benutzerberechtigung angezeigt wird, der Verbindungsaufbau jedoch fehlschlägt, pingen Sie den FQDN des VDA manuell an, um zu überprüfen, ob Citrix Director den FQDN auflösen kann. Wenn es ein Problem mit der wss:// Verbindung gibt, überprüfen Sie Ihre Zertifikate.

Auf dem Linux VDA

  1. Überprüfen Sie die Datei /var/log/xdl/vda.log auf Hinweise.
  2. Bearbeiten Sie die Datei /var/xdl/sessionshadowing.sh und ändern Sie die Variable 'logFile', um eine Protokolldatei anzugeben, die während des Session Shadowing vom Director aus auf Hinweise überwacht werden kann.
  3. Sie können auch manuell überprüfen, ob Ihre Zertifikate mit der noVNC-Verbindung korrekt funktionieren:
    1. Führen Sie ps aux \| grep xorg aus, um die Xorg-Anzeigenummer $display-num der aktuellen Sitzung zu finden, zum Beispiel :3.
    2. Führen Sie den folgenden Befehl aus, um einen x11vnc-Server zu starten und auf eine eingehende Verbindung zu warten.
      Hinweis:
      Bevor Sie den folgenden Befehl ausführen, legen Sie die Variablen $passwd, $port, $display-num fest.
      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. Versuchen Sie, sich über noVNC zu verbinden, um den SSL-Modus wie folgt zu überprüfen. Geben Sie den FQDN Ihres VDA und die Portnummer ein. In diesem Beispiel ist die Portnummer 6009.
      Mit noVNC verbinden
    4. Beheben Sie alle Fehler, die von Websockify auf dem VDA ausgegeben oder vom Browser auf dem Client gemeldet werden.
      Wichtige Prüfpunkte während des Verbindungsaufbaus:
      1. Prüfen Sie auf Firewall-Einschränkungen, die verhindern, dass die Sitzungsschattenfunktion den Port öffnet.
      2. Stellen Sie sicher, dass Sie Zertifikate und Schlüsseldateien korrekt benannt und im richtigen Pfad abgelegt haben, falls es sich um das SSL-Szenario handelt.
      3. Stellen Sie sicher, dass zwischen 6001 und 6099 genügend Ports für neue Schattenanforderungen verfügbar sind.
      4. Führen Sie openssl x509 -in shadowingcert.pem -text -noout aus, um zu überprüfen, ob die Zertifikate korrekt konfiguriert sind, und achten Sie dabei besonders auf die Felder CN und SAN.
      5. Unter RHEL 8 kann es vorkommen, dass rebind.so nicht gefunden wird. Um dieses Problem zu beheben, führen Sie den folgenden Befehl aus:
        ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so