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.

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 – 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 | Windows 11 26H2 – Black Screens und endlose Citrix-Anmeldungen

Nach Windows-Updates häufen sich Probleme in Citrix-Umgebungen:

❌ Anmeldung hängt bei „Willkommen“ oder „Bitte warten“
❌ Schwarzer Bildschirm nach erfolgreicher Anmeldung
❌ Explorer startet nicht
❌ Benutzerprofile werden nicht vollständig geladen

Das Problem: Gleiche Symptome, unterschiedliche Ursachen.

Aktuell gibt es mehrere bekannte Fehlerbilder:

1️⃣ Windows Shell / explorer.exe
Microsoft bestätigt Explorer-Probleme nach der Anmeldung, insbesondere in virtuellen Windows-11-Umgebungen mit FSLogix.
✅ Fix: KB5127648 (Oktober 2026).

2️⃣ Citrix UPM – UPM-13949
Unter Windows 11 26H2 können neue Benutzerprofile auf MCS-Maschinen beim ersten Login hängen bleiben. Der Profilordner wird erstellt, die Anmeldung aber nicht abgeschlossen. Bestehende Profile funktionieren.
⚠️ Citrix untersucht das Problem.

3️⃣ FSLogix – Profilcontainer
Mögliche Ursachen sind verzögertes VHDX-Mounting, SMB-Latenzen, Storage-Engpässe, gesperrte Container, Berechtigungen oder Antivirus-Interferenzen.

4️⃣ Citrix UPM – Profile Store
Fehlerhafte NTFS- oder Share-Berechtigungen nach Profilmigrationen können verhindern, dass das Profil korrekt initialisiert wird.

5️⃣ Citrix VDA – Registrierungsprobleme
Nach KB5127648 können VDAs im Status „Registering“ hängen bleiben. BrokerService meldet unter anderem SecurityNegotiationException.
➡️ Citrix dokumentiert einen Registry-Workaround.

6️⃣ Remote Desktop Services
Nach bestimmten Windows-Updates kann TermService hängen bleiben. Sitzungen verbleiben bei „Connecting“, neue Verbindungen scheitern.

7️⃣ MCS Master Image
Wenn plötzlich alle Maschinen betroffen sind, sollten Windows-Build, VDA-Version, GPOs, Logon Scripts und der letzte funktionierende Snapshot verglichen werden.

🔧 Mein Troubleshooting-Ansatz:

✔ VDA registriert?
✔ Session tatsächlich gestartet?
✔ Neues oder bestehendes Profil betroffen?
✔ FSLogix-VHDX beziehungsweise UPM-Profil geladen?
✔ Fehler im User Profile Service?
✔ explorer.exe gestartet oder abgestürzt?
✔ Windows-Updates und VDA-Version geprüft?
✔ Einzelne VDAs oder gesamter MCS-Katalog betroffen?

💡 Fazit

Ein Black Screen ist ein Symptom, keine Diagnose.

Wer nur FSLogix untersucht, obwohl der Explorer abstürzt oder der VDA nicht registriert, verliert wertvolle Zeit.

Erst feststellen, an welcher Stelle die Anmeldung scheitert. Dann gezielt die Ursache beheben.

Finding in the Wild | Citrix 2607 LTSR – Upgrade erfolgreich, aber plötzlich sind Softwarelizenzen ungültig!

Diese Woche habe ich bei einem Kunden die Citrix-Umgebung auf das aktuelle CVAD 2607 LTSR aktualisiert.

Das Upgrade lief zunächst vollkommen problemlos.

✅ VDAs starteten sauber
✅ Registrierung am Delivery Controller erfolgreich
✅ Anwendungen ließen sich starten
✅ Keine Auffälligkeiten in Citrix Director

Eigentlich ein erfolgreiches Upgrade.

Doch kurz darauf meldeten einzelne Fachanwendungen plötzlich Lizenzprobleme.

❌ Lizenz ungültig
❌ Hardware-ID geändert
❌ Erneute Aktivierung erforderlich

Zunächst deutete alles auf ein Problem mit der Lizenzierungssoftware hin.

Die eigentliche Ursache lag allerdings bei einer Änderung in Citrix MCS.

🔍 Was habe ich festgestellt?

Seit VDA 2511 sorgt Citrix bei MCS-provisionierten Windows-Maschinen für eine eindeutige MachineGuid.

Früher konnten mehrere MCS-Maschinen denselben Wert aus dem Master-Image übernehmen.

Mit den neueren VDA-Versionen – einschließlich 2607 LTSR – wird diese Maschinenidentität eindeutig vergeben und bleibt über Neustarts und Image-Updates hinweg bestehen.

Technisch eine sinnvolle Verbesserung.

Allerdings verwenden einige Fachanwendungen die Windows-MachineGuid als Bestandteil ihres Lizenz-Fingerprints.

Ändert sich dieser Wert beim Upgrade, erkennt die Software möglicherweise eine neue Maschine.

🛠️ Wie habe ich das geprüft?

Über die Registry lässt sich die MachineGuid auslesen:

Der Vergleich mit den bisherigen Maschinenidentitäten zeigte die Änderung nach dem Upgrade.

Damit war auch klar, warum die betroffenen Anwendungen eine erneute Lizenzaktivierung verlangten.

Was nehme ich für zukünftige Upgrades mit?

✔ MachineGuid vor dem Upgrade dokumentieren
✔ Lizenzabhängigkeiten von Fachanwendungen prüfen
✔ Neue VDA-Version zunächst mit Pilotmaschinen testen
✔ Lizenzaktivierung nach dem Upgrade validieren
✔ Gegebenenfalls Reaktivierung mit dem Hersteller abstimmen

⚠️ Die alte MachineGuid einfach wiederherzustellen oder auf mehrere VDAs zu kopieren, ist keine saubere Lösung.

💡 Mein Fazit

Das Citrix-Upgrade war technisch erfolgreich. Trotzdem hatte eine Änderung im Hintergrund direkte Auswirkungen auf die Anwendungen der Benutzer.

Nicht jeder Fehler nach einem Citrix-Upgrade ist ein klassischer Citrix-Fehler. Manchmal verändert sich eine technische Grundlage, auf die andere Anwendungen angewiesen sind.

Citrix dokumentiert dieses Verhalten unter PMCS-58288.