Kategorie: Findings in the Wild 3 Beiträge

Finding in the Wild | Citrix Workspace App 2607 LTSR x64 – StoreFront SSO funktioniert nicht mehr

Ein Citrix Workspace App Upgrade, und plötzlich funktioniert die automatische Anmeldung am StoreFront nicht mehr.

Genau solche Fehlerbilder sind besonders interessant, weil die Ursache nicht unbedingt dort liegt, wo man sie zunächst vermutet.

Das Fehlerbild:

❌ Windows-Anmeldung funktioniert problemlos
❌ StoreFront fordert erneut Benutzername und Kennwort an
❌ Domain Pass-through Authentication funktioniert nicht mehr
✅ Vor der Umstellung auf die native x64 Workspace App war SSO funktionsfähig

Der erste Verdacht fällt schnell auf Kerberos, GPOs, StoreFront oder die SSON-Komponente.

Die eigentliche Ursache:

Citrix dokumentiert für die Workspace App 2607 LTSR x64 ein Known Issue bei der Domain Pass-through Authentication.

Dabei kann die Registrierung der cck.dll-Komponente im 64-Bit-Registry-Zweig fehlen beziehungsweise nicht korrekt hinterlegt sein.

🛠️ Der Workaround

Auf dem betroffenen Client lässt sich die Registrierung über folgenden Befehl korrigieren:

Anschließend die Workspace App vollständig beenden und die Anmeldung erneut testen.

Mein Fazit:

Wenn nach einem Workspace-App-Upgrade plötzlich StoreFront-SSO ausfällt, würde ich nicht sofort die gesamte Authentifizierungskette auseinandernehmen.

Ich prüfe zuerst die Client-Version, die Architektur und die Registrierung der beteiligten Komponenten.

Ein kleiner Registry-Eintrag kann hier den entscheidenden Unterschied machen.

⚠️ Der Workaround gilt für das dokumentierte Fehlerbild und sollte vor einem breiten Rollout getestet werden.

Finding in the Wild | Citrix FAS – SSO funktioniert nach dem Upgrade nicht mehr?

Bei Citrix-Upgrades schaue ich mir nicht nur die VDA-Registrierung und den Sitzungsstart an, sondern auch die komplette Authentifizierungskette.

Gerade bei Citrix Federated Authentication Service (FAS) gibt es seit Version 2511 eine interessante Änderung, die in gemischten Umgebungen schnell übersehen werden kann.

Das Fehlerbild:

❌ Benutzer können sich am StoreFront anmelden
❌ Der veröffentlichte Desktop startet, aber Windows-SSO schlägt fehl
❌ Zertifikatsvorlagen und CA-Konfiguration sehen korrekt aus
❌ Nicht alle VDAs zeigen dasselbe Verhalten

🔍 Was steckt dahinter?

Mit FAS 2511 hat Citrix das neue V2-Ticketformat eingeführt.

Der entscheidende Unterschied:

Bisher (V1):
Der VDA benötigt die FAS-Serveradressen über die bekannte Registry-/GPO-Konfiguration.

Neu (V2):
Die FAS-Adresse wird direkt im Ticket übermittelt.

Damit entfällt für VDAs ab Version 2511 die separate FAS-Adressliste.

⚠️ Der entscheidende Punkt:

In einer gemischten Citrix-Umgebung mit älteren und neueren VDAs darf die bisherige FAS-Konfiguration nicht einfach entfernt werden.

Ältere VDAs benötigen weiterhin die FAS-Serveradressen.

🛠️ So gehe ich bei der Analyse vor:

1. FAS- und VDA-Versionen vergleichen.
2. Prüfen, ob die FAS-Serveradressen auf älteren VDAs weiterhin konfiguriert sind.
3. Auf dem FAS-Server das Application Event 204 auswerten. Dort lässt sich erkennen, ob V1- oder V2-Tickets verwendet werden.
4. Erst danach Zertifikate, CA-Templates und Berechtigungen untersuchen.

💡 Mein Fazit:

Nicht jedes FAS-SSO-Problem liegt an der Zertifizierungsstelle.

Mit FAS V2 wird die Architektur einfacher – allerdings nur, wenn alle beteiligten VDAs das neue Ticketformat unterstützen.

Gerade bei LTSR-Migrationen und gemischten VDA-Versionen gehört die FAS-Ticketversion deshalb für mich auf die Troubleshooting-Checkliste.

Finding in the Wild | Citrix MCS – VDA startet, aber die Domänenvertrauensstellung ist defekt!

Ein Fehlerbild, das in nichtpersistenten Citrix-Umgebungen besonders unangenehm werden kann.

Der VDA startet nach einem Reboot scheinbar problemlos. Die VM ist erreichbar, die Netzwerkverbindung steht – aber Benutzer können sich nicht mehr anmelden.

❌ Windows meldet eine fehlerhafte Domänenvertrauensstellung
❌ Benutzeranmeldungen über ICA oder RDP schlagen fehl
❌ Ein Neustart behebt das Problem nicht dauerhaft
❌ Im schlimmsten Fall sind mehrere Maschinen eines MCS-Katalogs betroffen

🔍 Wo liegt die eigentliche Ursache?

Bei Citrix Machine Creation Services (MCS) erhält jede Maschine eine eigene Identität.

Diese wird unter anderem über die MCS Identity Disk bereitgestellt.

Sie enthält die maschinenspezifischen Identitätsinformationen, die für die korrekte Zuordnung zur Active-Directory-Domäne erforderlich sind.

Wenn das Maschinenkontokennwort beziehungsweise die Trust-Informationen nicht mehr zum AD-Computerkonto passen, kann die Domänenvertrauensstellung fehlschlagen.

Mögliche Auslöser sind beispielsweise Snapshot-Rollbacks, fehlerhafte Identity-Informationen oder manuelle Änderungen an AD-Computerkonten.

🛠️ Mein Troubleshooting-Ansatz

Zunächst prüfe ich auf dem betroffenen VDA den Secure Channel:

Anschließend kontrolliere ich:

✔️ Netlogon-Ereignisse
✔️ Das zugehörige AD-Computerkonto
✔️ Die Zuordnung der MCS Identity Disk
✔️ Den Maschinenstatus im Citrix Broker

Und jetzt kommt der interessante Teil:

Citrix bietet mit Repair-AcctIdentity eine gezielte Reparatur der Maschinenidentität.

Damit lassen sich Maschinenkennwort und Trust-Informationen reparieren, ohne direkt den gesamten Machine Catalog neu aufzubauen.

Beispiel:

Wichtig: Die betroffene VM muss dafür ausgeschaltet und im Maintenance Mode sein.

💡 Mein Fazit

Bei einem defekten Secure Channel in einer nichtpersistenten MCS-Umgebung würde ich nicht einfach den Computer aus der Domäne entfernen und erneut aufnehmen.

Die Maschinenidentität wird durch MCS verwaltet. Eine manuelle Reparatur innerhalb des VDAs kann deshalb beim nächsten Neustart wieder verloren gehen.

Erst die MCS-Identität prüfen, dann gezielt reparieren – statt direkt den kompletten Katalog neu aufzubauen.