Remote-Zugriff mit ThinLinc 4.12
Zeitloser Klassiker
Veröffentlicht in Ausgabe 09/2021 - PRAXIS
Der Covid-19-Pandemie wird gerade im Bereich der Digitalisierung eine Katalysatorrolle bescheinigt. Innerhalb kürzester Zeit mussten Prozesse digitalisiert werden, was vorher in dieser Geschwindigkeit unmöglich schien. Quasi über Nacht hat damit die Rolle des IT-Administrators enorm an Bedeutung gewonnen. Dabei profitieren sie nicht selten von Technologien, die längst überholt schienen: Terminalservices sind eigentlich ein alter Hut und stammen aus einer Zeit, als die Clients für kaum mehr als die Darstellung einfacher Zeichen taugten. Für Administratoren sind sie ein willkommenes Instrument, da sich die zentral betriebenen Applikationen und Einstellungen einfacher verwalten lassen als dies bei wartungsintensiven Desktoprechnern der Fall ist.
Der Einsatz von klassischen Terminalserver-Technologien mit einem (oder mehreren) zentralen Servern verspricht die optimale Auslastung eines zentralen Serversystems anstelle der oft ineffizienten Verteilung auf die Desktops. Prinzipiell erhöht eine serverbasierte Lösung die Verfügbarkeit – und damit letztlich die Sicherheit. Das mittlerweile 18 Jahre alte ThinLinc liegt inzwischen in Version 4.12 vor und umfasst sowohl die serverseitigen Elemente (Session-Broker, Loadbalancer, Admin-Oberfläche) als auch die Endbenutzerkomponenten (Clientsoftware, Anpassungstools). Aus dem Zusammenspiel dieser verschiedenen Bestandteile ergibt sich eine Komplettlösung, die alle Anforderungen an eine moderne Terminalumgebung bereitstellt.
Technischer Unterbau
Technisch gesehen handelt es sich bei ThinLinc um einen Linux-Remotedesktopserver, der überwiegend auf Open-Source-Software wie TigerVNC, noVNC, OpenSSH, CUPS und PulseAudio aufbaut. Der Entwickler Cendio aus dem schwedischen Linköping hat aus diesen verschiedenen Werkzeugen eine stabile Umgebung für das Server-based Computing entwickelt. Dabei profitiert ThinLinc von der Robustheit der zugrundeliegenden Tools.
Der Covid-19-Pandemie wird gerade im Bereich der Digitalisierung eine Katalysatorrolle bescheinigt. Innerhalb kürzester Zeit mussten Prozesse digitalisiert werden, was vorher in dieser Geschwindigkeit unmöglich schien. Quasi über Nacht hat damit die Rolle des IT-Administrators enorm an Bedeutung gewonnen. Dabei profitieren sie nicht selten von Technologien, die längst überholt schienen: Terminalservices sind eigentlich ein alter Hut und stammen aus einer Zeit, als die Clients für kaum mehr als die Darstellung einfacher Zeichen taugten. Für Administratoren sind sie ein willkommenes Instrument, da sich die zentral betriebenen Applikationen und Einstellungen einfacher verwalten lassen als dies bei wartungsintensiven Desktoprechnern der Fall ist.
Der Einsatz von klassischen Terminalserver-Technologien mit einem (oder mehreren) zentralen Servern verspricht die optimale Auslastung eines zentralen Serversystems anstelle der oft ineffizienten Verteilung auf die Desktops. Prinzipiell erhöht eine serverbasierte Lösung die Verfügbarkeit – und damit letztlich die Sicherheit. Das mittlerweile 18 Jahre alte ThinLinc liegt inzwischen in Version 4.12 vor und umfasst sowohl die serverseitigen Elemente (Session-Broker, Loadbalancer, Admin-Oberfläche) als auch die Endbenutzerkomponenten (Clientsoftware, Anpassungstools). Aus dem Zusammenspiel dieser verschiedenen Bestandteile ergibt sich eine Komplettlösung, die alle Anforderungen an eine moderne Terminalumgebung bereitstellt.
Technischer Unterbau
Technisch gesehen handelt es sich bei ThinLinc um einen Linux-Remotedesktopserver, der überwiegend auf Open-Source-Software wie TigerVNC, noVNC, OpenSSH, CUPS und PulseAudio aufbaut. Der Entwickler Cendio aus dem schwedischen Linköping hat aus diesen verschiedenen Werkzeugen eine stabile Umgebung für das Server-based Computing entwickelt. Dabei profitiert ThinLinc von der Robustheit der zugrundeliegenden Tools.
ThinLinc stellt die Ressourcen des verwendeten Linux-Servers bereit, indem eine reguläre Linux-Distribution in einen Remote-Desktop-Server umgewandelt wird. Für den Administrator vereinfachen sich typische Aufgaben, da er lediglich den Server im Blick behalten muss. Somit fällt auch das Monitoring der Umgebung deutlich leichter.
Grundsätzlich unterstützt ThinLinc alle Linux-Distributionen, die RPM oder DPKG verwenden. Dabei ist die Systemarchitektur des Werkzeugs dergestalt konzipiert, dass sich der Terminalserver problemlos in eine bestehende IT-Infrastruktur integrieren lässt, basiert es doch auf einer typischen Client-Server-Architektur. Dabei ist neben der regulären Systemauthentifizierung die Integration von eDirectory, Active Directory, NIS et cetera möglich. ThinLinc verwendet PAM (Pluggable Authentication Modules) für die Authentifizierung.
Die Software unterstützt Clustering und bietet High Availability sowie Loadbalancing. Um die Hochverfügbarkeit sicherzustellen, finden zwei Systeme Verwendung, die als VSM-Server (Virtual Systems Management) agieren. Fällt ein System aus, bedient der VSM-Server die Anfragen so, dass es zu keinen oder lediglich zu minimalen Dienstunterbrechungen kommt. Der Lastausgleich verteilt die Sitzungen der Benutzer gleichmäßig auf die Server in einem ThinLinc-Cluster. Dabei werden die Server, soweit dies möglich ist, gleich belastet.
Die Architektur ist durch den Master, den Agent und den Client gekennzeichnet. Der ThinLinc-Master-Server (vsmserver) ist für die Erstauthentifizierung und die Auswahl des Terminalservers zuständig. Dabei verfolgt er alle Sitzungen und verteilt die Last auf mehrere Agenten in einem Cluster. Seine Aufgabe besteht außerdem darin, den Clients die relevanten Sitzungsinformationen zukommen zu lassen.
Die Aufgaben des ThinLinc-Agenten (vsmagent) bestehen im Starten und Hosten der Prozesse, aus denen sich eine Sitzung generiert. Außerdem baut der Agent Tunnel für grafische und lokale Geräte auf. Die Tunnel werden pro Benutzer über eine SSH-Verbindung gemultiplext. Schließlich stellt der Client zwei Verbindungen her. Zunächst erzeugt er eine mit dem Master und dann erneut mit demjenigen Agenten, den der Master als optimal qualifiziert.
Vorbereitungen für Installation
Bevor Sie die eigentliche Installation durchführen, sollten Sie das Linux-Serversystem, das Sie für die Ausführung von ThinLinc verwenden wollen, auf die erforderlichen Systemvoraussetzungen überprüfen. Hardwareseitig sind keine besonderen Prämissen zu erfüllen. Die Serverausstattung sollte sich primär an den Anforderungen orientieren, die die Benutzer an die Umgebung haben. Um jedem Benutzer einen KDE- oder Gnome-Desktop zur Verfügung zu stellen, sollten Sie jeweils circa 200 MByte Speicherplatz vorsehen. Weitaus wichtiger ist die Verfügbarkeit von RPM-Unterstützung, SSH und eine korrekte NTP-Konfiguration.
Die Entwickler von ThinLinc, das unter einer proprietären Lizenz steht, stellen eine Demoversion zum Download bereit. Diese ist auf fünf gleichzeitig arbeitende Benutzer beschränkt. Fünf bis zehn Benutzer schlagen mit 78 US-Dollar pro Jahr und User zu Buche, elf bis 49 sind ab 66 US-Dollar pro Jahr und Benutzer erhältlich. Zur Installation laden Sie sich das ZIP-Archiv von der ThinLinc-Website herunter [1], entpacken es in ein Verzeichnis Ihrer Wahl und starten das Installationsskript mit
sh ./install-server.Sollten Sie über eine gültige Lizenz verfügen, legen Sie die zugehörige Textdatei mit der Dateierweiterung ".license" im Verzeichnis "/opt/thinlinc/etc/licenses" ab. Damit ist das Basissystem prinzipiell einsatzbereit. Als Nächstes können Sie sich der Druckerinstallation oder aber der Einrichtung des Webzugriffs zuwenden.
Drucker konfigurieren mit CUPS
Das Drucken von Dokumenten ist trotz der gestiegenen Akzeptanz des papierlosen Büros weiterhin eine wichtige Funktion, die auch eine zentrale Serverlösung bereitstellen muss. ThinLinc kommt laut der Projekt-Website insbesondere im universitären und behördlichen Kontext zum Einsatz. Gerade der zweitgenannte Bereich bedarf trotz einer zunehmenden Digitalisierung einer Möglichkeit zum Drucken. Das Werkzeug greift deshalb bei der Druckfunktionalität auf den renommierten CUPS-Druckserver zurück.
ThinLinc bietet grundsätzlich zwei Varianten: Sie können einen lokalen oder den nächstgelegenen Drucker ansprechen. Im ersten Fall sind zwei Betriebsmodi verfügbar: geräteunabhängiger und geräteabhängiger Modus, wobei sich beide Modi miteinander kombinieren lassen. Der Thinlocal-Drucker ist clusterfähig – sendet ein Benutzer einen Druckauftrag an einen Knoten in einem ThinLinc-Cluster, der die Benutzersitzung nicht hostet, wird der Druckauftrag automatisch an einen geeigneten Knoten weitergereicht.
Um den PDF-Konvertierungsfilter, das Backend und die Warteschlange in CUPS auf allen Maschinen zu installieren, greifen Sie auf das ThinLinc-Setup zurück. Es fügt dem CUPS-Server eine neue Warteschlange namens "thinlocal" hinzu und stellt diese den Benutzern zur Verfügung.
Nach der Installation ist der lokale Drucker einsatzbereit. Hierzu muss lediglich in der ThinLinc-Client-Konfiguration sichergestellt sein, dass die Umleitung aktiviert ist.
Single-App-Zugriff realisieren
ThinLinc bietet verschiedene Möglichkeiten, die nicht alle auf den ersten Blick zu erkennen sind. So können Sie anstelle eines vollständigen Desktops die Benutzerumgebung auf eine einzige Anwendung begrenzen. Sicherheitsperspektivisch handelt es sich dabei um eine hochinteressante Möglichkeit. In der Praxis können Sie den Zugriff beispielsweise auf einen Webbrowser beschränken. Den Mitarbeitern steht dann nur der webbasierte Zugriff mit Firefox zur Verfügung.
Hierfür sind Anpassungen der ThinLinc-Konfigurationsdatei "/opt/thinlinc/etc/ conf.d" erforderlich. Generieren Sie dazu ein neues Profil, was über das Editieren der Datei "profiles.hconf" funktioniert. Diese könnte im Fall von Firefox als einzig erlaubter Anwendung wie folgt aussehen:
[/profiles/firefox]
name=Nur Firefox
description=Beispielkonfiguration für einen Single-App-Zugriff auf ThinLinc
cmdline=${TLPREFIX}/bin/tl-single-app firefox
testcmd=type firefox
Außerdem müssen Sie das neue Profil dem "order"-Parameter hinzufügen:
order=firefox
Nach dem Speichern und dem Neustart des ThinLinc-Servers ist das neue Profil über die Profilauswahl verfügbar.
Mit Windows verzahnen
Für die Integration in eine heterogene Netzwerkumgebung ist die Zugriffsmöglichkeit auf einen Active-Directory- und einen Windows-Fileserver wichtig. Zunächst müssen Sie auf Seiten von ThinLinc diverse Komponenten installieren:
yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation
Als Nächstes gilt es, das Zusammenspiel mit dem Windows-DNS-Service zu aktivieren, damit die AD-Domain korrekt erfasst werden kann. Der Listing-Kasten "Windows-Integration" zeigt, wie dies aussehen muss. Um dann der Domain beizutreten und das Admin-Passwort für den Zugriff zu übergeben, verwenden Sie den Befehl
realm join <Domäne>.Listing 1: Windows-Integration
[localhost]# realm discover <Domäne> DOMAIN
type: kerberos
realm-name: <Domäne>
domain-name: <Domäne>
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
Nun verifizieren Sie mit
id testuser@<Domäne> die Benutzerauflösung im Active Directory. Außerdem ist eine Anpassung der System-Security-Services-Daemon-Konfiguration "sssd.conf" notwendig, damit ThinLinc als Service erkennbar ist. Dazu editieren Sie die Datei "/etc/sssd/ sssd.conf" und nehmen folgende Ergänzung vor:ad_gpo_map_remote_interactive = +thinlinc
Nach einem Neustart von "sssd" mittels
systemctl restart sssd greifen die Anpassungen dann.Zugriffssicherheit erhöhen
Beim Zugriff auf den ThinLinc-Server haben Sie die Möglichkeit, die Zwei-Faktor-Authentifizierung, ein Einmalpasswort (One-Time-Password, OTP) oder ein Standardpasswort für die Authentifizierung zu verwenden. Das Prozedere, um ThinLinc OTP-fähig zu machen, gestaltet sich einfach. Zunächst installieren Sie den Google Authenticator:
sudo dnf install google-authenticator
Im Anschluss konfigurieren Sie "sshd" so, dass der Daemon die Authentifizierung zulässt. Dazu editieren Sie die Datei "/etc/ssh/sshd_config" und aktivieren die Option "ChallengeResponseAuthentication" mit "yes":
# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
Nach einem Neustart greift auch diese Systemanpassung. Der nächste Schritt dient der Konfiguration des Zusammenspiels von PAM und dem Google Authenticator. Hierzu editieren Sie die Datei "/etc/pam.d/thinlinc" und nehmen die im Listing-Kasten 2 ersichtlichen Anpassungen vor.
Listing 2: OTP-Settings in "/etc/pam.d/thinlinc"
#%PAM-1.0 e
Auth required pam_sepermit.so e
Auth substack password-auth e
Auth required pam_google_authenticator.so nullok e
Auth include postlogin e
account required pam_sepermit.so e
account required pam_nologin.so e
Nach der Installation des Google Authenticator auf dem Endgerät muss der Anwender auf dem ThinLinc-Server noch die OTP-Funktionalität aktivieren. Dazu führt er das Programm "google-authenticator" aus, das einen interaktiven Dialog öffnet. Im weiteren Konfigurationsverlauf wird ein QR-Code ausgegeben, den die User mit dem Endgerät scannen. Damit ist diese Funktionalität aktiviert.
Zugriff auch per Webclient
Grundsätzlich stellt ThinLinc auch einen Webclient zur Verfügung. Hierfür greift es auf noVNC zurück, eine VNC-Client-JavaScript-Bibliothek. Dabei profitieren Administratoren und Benutzer davon, dass sich noVNC [2] in mobilen Umgebungen wie Android und iOS ausführen lässt. Der Vorteil für die Anwender ist offensichtlich: Die Installation des ThinLinc-Clients ist nicht zwingend notwendig und einem Zugriff von mobilen Endgeräten steht nichts im Weg. Während die "traditionellen" ThinLinc-Clients bei der Verschlüsselung der Client-Server-Verbindung allesamt auf SSH setzen, nutzt der Webclient TLS als Protokoll. noVNC stellt eine HTML-5-Funktionalität bereit. Damit steht auch einer Implementierung von BYOD-Policies nichts entgegen.
Fazit
Terminalumgebungen erleben in der Corona-Krise ein Revival. Dabei können Administratoren aus einem beachtlichen Angebot an kommerziellen und freien Werkzeugen schöpfen. Es stellt sich allerdings die Frage, ob die Entscheidung für ein kommerzielles Werkzeug wie ThinLinc lohnt oder ob Unternehmen nicht lieber zu einem freien Remote-Desktop-Werkzeug wie UltraVNC greifen sollten. Im direkten Vergleich zeigen sich keine nennenswerten Unterschiede. Eine ThinLinc-Lizenzierung ist vor allem dort sinnvoll, wo Unternehmen auf zeitnahen Support angewiesen sind.
(ln)