Ein Desktop soll sich für den Benutzer vertraut anfühlen: anmelden, die eigenen Anwendungen öffnen und arbeiten. Ob dahinter Windows oder Linux läuft, wird vor allem dann zum Thema, wenn etwas nicht wie erwartet funktioniert.
In unserer Testumgebung haben wir Ubuntu-Desktops über Citrix bereitgestellt und bestehende Systeme nach Updates kontrolliert. Die technische Grundlage bilden Active Directory, SSSD und der Citrix Linux VDA. Auf dem neu eingerichteten System verwenden wir GNOME als Desktop.
Auf dem Weg dorthin gab es mehrere Hürden: Ein akzeptiertes Passwort führte zunächst noch nicht zur erlaubten Anmeldung. Danach öffnete sich die Sitzung kurz und verschwand wieder, weil das persönliche Home-Verzeichnis fehlte. Die Protokolle halfen uns, diese beiden Fehler voneinander zu unterscheiden.
Linux als zusätzlicher Arbeitsplatz
Citrix kennen viele aus der Bereitstellung von Windows-Anwendungen. In unserem Pilot nutzen wir denselben grundsätzlichen Zugang auch für Linux-Desktops. Der Virtual Delivery Agent, kurz VDA, ist dabei die Komponente, die das Linux-System für Citrix-Sitzungen bereitstellt.
Für mich ist das eine Möglichkeit, verschiedene Arbeitsumgebungen zentral zugänglich zu machen. Ob ein solcher Desktop im Alltag passt, hängt von den benötigten Anwendungen und Arbeitsabläufen ab. Der Pilot erlaubt uns, genau das praktisch zu beurteilen.
Die Domänenintegration mit SSSD prüfen
Für die Domänenintegration haben wir realmd und adcli zusammen mit SSSD verwendet. SSSD steht für System Security Services Daemon und bindet in diesem Aufbau unter anderem die AD-Benutzer in die Linux-Anmeldung ein. Der Linux-Rechner erhält ein eigenes Computerkonto in Active Directory.
Vor dem Citrix-Test kontrollierten wir das Maschinenvertrauen und die Benutzerauflösung. Dafür eignen sich beispielsweise diese lesenden Abfragen; Domäne und Benutzer sind hier ausschliesslich Platzhalter:
sudo adcli testjoin --domain=example.invalid
getent passwd 'benutzer@example.invalid'Ein erfolgreicher Vertrauensprüfungslauf und ein gefundener Benutzer sind wichtige Zwischenstände. Danach muss die tatsächliche Anmeldung funktionieren. Die Ubuntu-Dokumentation zur AD-Anbindung mit SSSD beschreibt die beteiligten Komponenten und Prüfungen.
GNOME als Desktop für die Citrix Sitzung
Auf dem neuen VDA haben wir GNOME mit Wayland eingerichtet. Bei der Auswahl müssen Linux-Distribution, Desktop und VDA zusammenpassen. Citrix führt die unterstützten Kombinationen in seinen Systemanforderungen für den Linux VDA auf.
Im Installationsdialog trat eine irreführende Meldung auf: Nach der GNOME-Auswahl wurde ein fehlender MATE-Desktop beanstandet. Die Prüfung der vorhandenen Sitzungsdateien und des mitgelieferten Skripts zeigte, dass GNOME bereits installiert war. Der Dateitest des Skripts berücksichtigte den vorhandenen Ubuntu-Sitzungsnamen nicht.
Wir konnten die Einrichtung mit der vorgesehenen Vorgabe für die Desktopumgebung fortsetzen. Einen weiteren Desktop allein aufgrund der Fehlermeldung nachzuinstallieren, war dafür nicht erforderlich. Der anschliessende Sitzungsstart blieb die entscheidende Funktionsprüfung.
Das Passwort war richtig und der Zugriff wurde trotzdem verweigert
Beim ersten Citrix-Login zeigte sich ein Unterschied zwischen Authentifizierung und Zugriffsentscheidung. Im Protokoll meldete SSSD eine erfolgreiche Passwortprüfung. Im nachfolgenden Account-Schritt wurde die Anmeldung dennoch abgelehnt.
Die Ursache lag zunächst in der Zuordnung des Citrix-PAM-Dienstes zur GPO-Zugriffsprüfung. PAM ist die Linux-Schnittstelle für die Anmeldung; die Citrix-Sitzung verwendet hier den Dienst ctxhdx. Dieser musste den Regeln für eine interaktive Remote-Anmeldung zugeordnet werden. Citrix beschreibt dafür folgende Einstellung im jeweiligen Domainabschnitt der SSSD-Konfiguration:
ad_gpo_map_remote_interactive = +ctxhdx, +ctxfasctxfas betrifft den entsprechenden FAS-Anmeldeweg. Die Citrix-Fehlerbeschreibung zur PAM-/GPO-Zuordnung erläutert die Einstellung. Sie gehört in den passenden Domainabschnitt, nicht in den allgemeinen SSSD-Abschnitt.
Danach wurde eine zweite Ursache sichtbar: Das Computerkonto konnte mehrere bei der Auswertung berücksichtigte Gruppenrichtlinien nicht lesen. Wir prüften die betroffenen Richtlinien einzeln und ergänzten gezielt Leserechte für den Linux-Rechner. Die GPO-Zugriffskontrolle blieb dabei aktiv. Leserechte auf eine Richtlinie bedeuten noch nicht, dass der Rechner sie auch anwenden darf.
Eine erneute Account-Prüfung über den Citrix-PAM-Dienst war anschliessend erfolgreich. Damit war die Zugriffsentscheidung geklärt; als Nächstes musste die Benutzerumgebung starten.
Das fehlende Home Verzeichnis beendete die Sitzung
Nach der Korrektur öffnete sich die Sitzung kurz und wurde sofort wieder geschlossen. In den Protokollen erschienen Zugriffsfehler beim Anlegen persönlicher Anwendungsdaten. Die Prüfung zeigte: Der Benutzer war bekannt und hatte einen Home-Pfad, das Verzeichnis selbst existierte aber nicht.
Mit der persönlichen Umgebung ist hier das lokale Linux-Home gemeint. Dort legen Desktop und Anwendungen ihre Einstellungen und Dateien ab. Die erfolgreiche AD-Anbindung hatte dessen automatische Erstellung noch nicht eingerichtet.
Wir aktivierten deshalb über pam-auth-update die Option Create home directory on login. Das PAM-Modul pam_mkhomedir erstellt das Home beim ersten Anmelden. Die Ubuntu-Anleitung zur automatischen Home-Erstellung behandelt diesen zusätzlichen Schritt.
Beim nächsten Citrix-Start wurde das Home angelegt und der GNOME-Desktop blieb geöffnet. Anmeldung, Berechtigung und persönliche Umgebung waren damit gemeinsam funktionsfähig.
Sprache und Tastatur machen den Unterschied
Eine passende Tastaturbelegung gehört für mich zur Grundfunktion eines Arbeitsplatzes. Gerade bei Sonderzeichen fällt eine Abweichung schnell auf. Auch Sprache, Datumsformat und Zeitzone sollen zur gewohnten Umgebung passen.
Diese Einstellungen haben wir sowohl am System als auch innerhalb der Citrix-Sitzung kontrolliert. Eine Prüfung über einen administrativen Fernzugang zeigt dessen eigene Umgebung. Für den Benutzer zählt, was in seinem Desktop tatsächlich ankommt.
Der praktische Test bestätigte die gewünschte Tastaturbelegung und die Schweizer Regionseinstellungen. Damit war ein weiterer Teil des Arbeitsplatzes überprüft.
Updates brauchen Rücksicht auf laufende Arbeit
Nach einem Update kontrollieren wir den Zustand der Dienste und die erneute Verfügbarkeit über Citrix. Anschliessend folgt der Test am Desktop. Ein erfolgreicher Paketlauf allein beantwortet noch nicht, ob ein Benutzer wieder arbeiten kann.
Für die spätere automatische Wartung haben wir eine klare Anforderung festgehalten: Ein belegter Desktop soll ausgelassen werden. Laufende Benutzersitzungen sollen für ein planmässiges Update nicht erzwungen beendet werden. Die Systeme sollen nacheinander gewartet und vor der erneuten Freigabe geprüft werden.
Diese Automatisierung ist noch in Planung. Wir möchten sie in eine zentrale Wartungssteuerung einordnen, die später auch andere Betriebsaufgaben übernehmen kann.
Der Pilot ist benutzbar und bleibt in Weiterentwicklung
Die getesteten Linux-Desktops lassen sich über Citrix öffnen, und die persönliche Anmeldung funktioniert. Die gewünschte Tastatur und Region sind ebenfalls geprüft.
Einzelne Fragen zum Bedienkomfort bleiben auf unserer Arbeitsliste. Wir halten sie fest und bearbeiten sie getrennt weiter. Der Pilot liefert uns damit einen funktionierenden Ausgangspunkt und konkrete Erfahrungen für den weiteren Betrieb.
Mir hat dieser Ablauf erneut gezeigt, wie wichtig der Test aus Benutzersicht ist. Die technische Einrichtung schafft die Voraussetzung. Ob der Arbeitsplatz seinen Zweck erfüllt, zeigt sich beim Anmelden und Arbeiten.