Finding in the Wild | Wenn Citrix HDX Direct durch einen Cipher-Mismatch ständig die Verbindung verliert!

Citrix-Sitzungen, die sich scheinbar ohne erkennbaren Grund immer wieder trennen und automatisch neu verbinden.

Die erste Vermutung?

Netzwerkprobleme, Paketverluste, Firewalls oder eine instabile UDP-Verbindung.

Doch nicht immer liegt die Ursache im Netzwerk.

🔎 Das Problem

Bei der Verwendung von EDT (Enlightened Data Transport) über HDX Direct kann es zu wiederholten Session-Disconnects und Reconnects kommen.

Besonders interessant: Die Verbindung wird grundsätzlich aufgebaut, bleibt aber nicht stabil.

Citrix dokumentiert dieses Verhalten unter der Fehlernummer CVADHELP-29336.

🛠️ Die Ursache

Ein Cipher-Mismatch bei der Verwendung von EDT über HDX Direct.

Damit liegt die Ursache nicht zwangsläufig an schlechter Netzwerkqualität, sondern an einem Problem bei der Aushandlung beziehungsweise Verwendung der Verschlüsselung.

Das macht die Fehlersuche besonders interessant, weil die Symptome zunächst stark nach einem klassischen Netzwerkproblem aussehen.

💡 Was sollte man prüfen?

✅ Verwendet die betroffene Sitzung tatsächlich EDT über HDX Direct?

✅ Treten die Disconnects ausschließlich bei UDP/EDT auf?

✅ Bleibt dieselbe Sitzung bei Verwendung von TCP stabil?

✅ Gibt es Hinweise auf Transport- oder Verschlüsselungsfehler in den Citrix-Diagnosedaten?

✅ Welche VDA-Version und welcher Cumulative-Update-Stand sind installiert?

Wichtig: Ein Wechsel auf TCP kann bei der Eingrenzung helfen, ist aber keine dauerhafte Lösung für das eigentliche Problem.

🔧 Der Fix

Citrix führt CVADHELP-29336 in den Fixed Issues von Citrix Virtual Apps and Desktops 2507 LTSR CU1 auf.

🎯 Mein Fazit

Nicht jeder Citrix-Reconnect ist ein Netzwerkproblem.

Gerade mit EDT, HDX Direct und den unterschiedlichen Transportwegen wird die Fehlersuche zunehmend komplexer.

Wenn TCP stabil läuft, EDT aber ständig Reconnects verursacht, sollte man nicht nur Firewalls und Paketverluste untersuchen, sondern auch bekannte Citrix-Transportfehler berücksichtigen.

Finding in the Wild | Wenn Citrix plötzlich alle Benutzer auf denselben VDA schickt!

Diese Woche hatte ich bei einem Kunden wieder einen interessanten Fall, der auf den ersten Blick nach einem klassischen Performanceproblem aussah.

Mehrere Multi-Session-VDAs, ausreichend Ressourcen und eigentlich eine funktionierende Lastverteilung.

Trotzdem landeten immer mehr Benutzer auf demselben Sessionhost, während andere VDAs kaum ausgelastet waren.

🔎 Was war auffällig?

Bei der Analyse der Umgebung fiel auf, dass einzelne VDAs ihre Load-Indizes nicht mehr vollständig meldeten.

CPU-, RAM- und Disk-Load-Werte fehlten teilweise. Dadurch hatte der Citrix Broker keine zuverlässige Grundlage mehr für die Lastverteilung.

Die Folge: Neue Sitzungen wurden nicht mehr gleichmäßig auf die verfügbaren VDAs verteilt.

🛠️ Die Ursache

Nach weiterer Analyse stieß ich auf einen dokumentierten Citrix-Bug:

CVADHELP-28688

Während der Initialisierung der Citrix Group Policy Client-Side Extension (CseEngine) kann die FQDN-Ermittlung des VDAs fehlschlagen.

Das kann dazu führen, dass die Load-Indizes nicht mehr korrekt gemeldet werden.

Citrix hat das Problem mit CVAD 2507 LTSR CU2 behoben.

💡 Was sollte man prüfen?

Wenn die Lastverteilung in einer CVAD-Umgebung plötzlich merkwürdig reagiert:

✅ Load-Indizes aller VDAs miteinander vergleichen.

✅ Prüfen, ob CPU-, RAM- und Disk-Load-Werte vollständig vorhanden sind.

✅ DNS- und FQDN-Auflösung der betroffenen Sessionhosts kontrollieren.

✅ Citrix Policy Engine und zugehörige Ereignisprotokolle untersuchen.

✅ VDA-Version und installierte Cumulative Updates überprüfen.

🎯 Mein Fazit

Nicht jedes Citrix-Performanceproblem ist ein Ressourcenproblem.

Manchmal sind genügend CPU, RAM und Sessionhosts vorhanden – aber der Broker bekommt schlicht nicht die Informationen, die er für eine vernünftige Lastverteilung benötigt.

Und genau deshalb lohnt es sich, bei ungleichmäßig ausgelasteten VDAs auch die Load-Indizes genauer anzusehen.

📌 Referenz: Citrix CVADHELP-28688 – CVAD 2507 LTSR CU2 Fixed Issues

Finding in the Wild | Windows October Update breaks Citrix VDA Registration!

Neuer Patchday, neue Überraschung. Und diesmal trifft es die Citrix VDA-Registrierung.

Nach der Installation des Windows-11-Sicherheitsupdates KB5127648 (Oktober 2026) können sich Citrix Virtual Delivery Agents plötzlich nicht mehr am Delivery Controller registrieren.

Das Interessante daran: Der VDA ist erreichbar. RDP funktioniert. Aber Citrix bleibt auf „Registering“ hängen.

🔍 Das Fehlerbild
– Citrix Studio: „Trying to re-register“
– VDA-Status bleibt auf „Registering“
– Published Desktops lassen sich nicht starten
– RDP auf die betroffene Maschine funktioniert weiterhin

Citrix dokumentiert das Problem offiziell unter CTX697231 für Windows 11 24H2/25H2, gemeldet mit VDA 2511. Andere VDA-Versionen könnten ebenfalls betroffen sein.

🔬 Der entscheidende Hinweis steckt im Eventlog

Auf dem Delivery Controller:
Event ID 131075
Prozess: BrokerService.exe
Exception:
System.ServiceModel.Security.SecurityNegotiationException
Fehlermeldung:
The caller was not authenticated by the service.
Betroffene Operation:
Citrix.Cds.Protocol.Worker.IQueryAgent.Test()

Damit wird es interessant: Nicht die klassische Erreichbarkeit des Controllers ist das Problem, sondern die Authentifizierung während der Kommunikation zwischen Broker Service und VDA.

🛠️ Der Workaround

Citrix hat bereits eine getestete Mitigation veröffentlicht:

Anschließend den betroffenen VDA neu starten.

Der Registry-Wert stellt vom neuen Windows Administrator Protection auf den klassischen Admin Approval Mode um.

Citrix bestätigt, dass sich die betroffenen VDAs danach wieder erfolgreich registrieren.

⚠️ Wichtig: Das ist ein temporärer Workaround, der eine zusätzliche Windows-Sicherheitsfunktion zurücknimmt. Die Änderung sollte kontrolliert erfolgen und nach einem endgültigen Fix erneut bewertet werden.

💡 Was lernen wir daraus?

Ein VDA, der nach dem Patchday nicht mehr registriert ist, muss nicht zwangsläufig ein Citrix-Problem haben.

Und wenn RDP funktioniert, bedeutet das noch lange nicht, dass auch die Citrix-Broker-Authentifizierung funktioniert.

Bevor ihr also VDAs neu installiert, Delivery Controller repariert oder die Active-Directory-Konfiguration auseinandernehmt:

Prüft KB5127648, Event ID 131075 und TypeOfAdminApprovalMode.

Citrix und Microsoft untersuchen die eigentliche Ursache weiterhin gemeinsam.

📚 Quelle:

Finding in the Wild | Citrix FIDO2 – Browser funktioniert, Office 365 nicht!

Bei einem Kunden hatte ich ein interessantes Problem mit der FIDO2-Weiterleitung in einer Citrix-Umgebung.

Das Fehlerbild:

✅ FIDO2-Authentifizierung im Browser funktioniert.

❌ In Microsoft Teams und OneDrive wird der FIDO2-Key nicht erkannt.

Die Citrix-Session selbst funktioniert problemlos, auch die FIDO2-Weiterleitung scheint zunächst korrekt eingerichtet zu sein.

Nach einiger Fehlersuche bin ich in den Citrix Docs auf zwei interessante Fixed Issues gestoßen:

🔹 CVADHELP-29179: FIDO2 funktioniert nur in Browser-Sessions, nicht aber in Office-365-Anwendungen.

🔹 CVADHELP-29040: FIDO2 funktioniert standardmäßig nicht mit Edge WebView2.

Die Lösung:

Ein Update auf Citrix VDA 2402 LTSR CU4.

Danach funktionierte die FIDO2-Authentifizierung auch in Teams und OneDrive.

💡 Mein Learning:

Wenn FIDO2 im Browser funktioniert, aber in Microsoft-365-Anwendungen nicht, muss es nicht an Entra ID, dem Security Key oder den Citrix Policies liegen.

Manchmal steckt die Lösung bereits in den Fixed Issues eines Citrix Cumulative Updates. 😉

Finding in the Wild | Citrix Entra SSO – wenn die Microsoft Security Baseline die Anmeldung blockiert

Eine Citrix-Umgebung mit Microsoft Entra ID, korrekt konfiguriertem SSO und registrierten VDAs.

Die Benutzer authentifizieren sich erfolgreich an Citrix Workspace. Beim Start des Desktops erscheint jedoch erneut eine Windows-Anmeldeaufforderung oder die SSO-Anmeldung schlägt fehl.

Das Fehlerbild:

✅ Entra-ID-Authentifizierung erfolgreich
✅ VDA registriert und erreichbar
✅ Citrix-Ressourcen werden angezeigt
❌ Single Sign-on innerhalb der Sitzung funktioniert nicht

Der erste Verdacht fällt auf Entra ID, Conditional Access, Kerberos oder die Citrix-Konfiguration.

Die eigentliche Ursache kann aber in einer Microsoft Security Baseline liegen.

🔍 Root Cause

Citrix Entra SSO benötigt folgende Windows-Sicherheitseinstellung:

Allow Custom SSPs and APs to be loaded into LSASS

Die Microsoft Intune Security Baseline für Windows setzt diese Einstellung standardmäßig auf Disabled.

Damit verhindert Windows das Laden zusätzlicher Security Support Providers und Authentication Packages in LSASS.

Die für Citrix SSO benötigte Authentifizierungsintegration kann dadurch blockiert werden.

🛠️ Mein Troubleshooting-Ansatz

Ich prüfe auf dem betroffenen VDA zuerst die effektive Richtlinie:

Computer Configuration → System → Local Security Authority

Entscheidend ist:

Allow Custom SSPs and APs to be loaded into LSASS

Anschließend kontrolliere ich, ob die Einstellung über Intune, eine Security Baseline oder eine klassische GPO vorgegeben wird.

Die Lösung:

Die Einstellung auf den betroffenen Citrix-Session-Hosts gezielt auf Enabled setzen.

Wichtig: Nicht die komplette Security Baseline deaktivieren!

Ich würde dafür eine dedizierte Richtlinie beziehungsweise eine abgestimmte Ausnahme für die Citrix-VDAs verwenden.

Danach die Richtlinienübernahme kontrollieren, den VDA neu starten und SSO erneut testen.

⚠️ Security-Hinweis

Diese Änderung erlaubt das Laden zusätzlicher SSP-/AP-Komponenten in LSASS und erweitert damit bewusst die zulässige Authentifizierungsintegration.

Deshalb gehört die Ausnahme ausschließlich auf die Systeme, die diese Funktion tatsächlich benötigen.

💡 Mein Fazit

Nicht jedes Citrix-SSO-Problem ist ein Citrix-Problem.

Manchmal verhindert eine korrekt ausgerollte Security Baseline genau die Funktion, die für die gewünschte Authentifizierungsarchitektur erforderlich ist.

Security Hardening und Funktionalität müssen gemeinsam betrachtet werden – gerade bei Citrix, Entra ID und Windows.