How-to: Session Management bei NoMachine
Die Technik basiert auf der Optimierung des X11 Protokolls (X Window System auf unixoiden Betriebssystemen). Die Verbindung vom Client zum entfernten Rechner ist SSL-verschlüsselt, früher ausschließlich mit dem SSH-Protokoll, später ist das NoMachine-eigene NX-Prokoll dazugekommen, das heute am meisten genutzt wird.
Security und Datenschutz wird bei NoMachine immer mitbedacht. So können Authentifizierungsmechanismen, die beim Kunden bereits vorhanden sind, wie Zweifaktorauthentifizierung, Authentifizierung über Active Directory, LDAP, Kerberos, u.s.w. integriert werden. Der Zugriff auf die Server kann z.B. durch einen Gateway-Server („Cloud Server“), durch Loadbalancing entfernter Zielrechner oder durch Berechtigungskonfigurationen weiter kontrolliert werden.
Genau auf letzteres, die Berechtigungskonfigurationen, gehe ich hier näher ein, denn über die Jahre hat NoMachine die Möglichkeiten der Autorisierung und des Session Management erweitert und verfeinert. Die öffentlich zugängliche Serverdokumentation ist stellenweise etwas kurz. Die folgenden Beispiele gehen ausführlicher auf oft gefragte Szenarien ein.
Session Sharing bei NoMachine
Kann NoMachine sowas wie Teamviewer? Ja, das Feature nennt sich Session Sharing.
Es kann in der Serverkonfiguration an- oder abgeschaltet werden. Wenn es angeschaltet ist, kann entweder „view-only“, „restricted“ (nur screen resize ist erlaubt) oder „interactive“ eingestellt werden. Außerdem lässt sich die Autorisierung konfigurieren, wenn sich jemand auf den Desktop eines anderen Users aufschalten möchte. Das geht in drei Stufen sowohl bei virtuellen Desktops, als auch beim physikalischen Desktop durch Einstellen des entsprechenden Modus, des VirtualDesktopMode bzw. PhysicalDesktopMode in der Serverkonfiguration.
Hier am Beispiel des PhysicalDesktopMode beim Enterprise Desktop Server:
| PhysicalDesktopMode | Aufschalten ohne Genehmigung durch den Desktop-User für… |
|---|---|
| 0 | alle |
| 1 | Administratoren und Trusted User |
| 2 | Trusted User |
„Trusted User“ sind zu definierende Vertrauens-User. Direkt nach der Serverinstallation gibt es noch keine.
Session sharing wird gerne in Ausbildungseinrichtungen genutzt. Wenn z.B. User „Schüler3“ sich per NoMachine-Client auf den Desktop aufschalten will, bekommt der momentan eingeloggte User ein solches Popup:
Wenn der User „Lehrer“ sich ohne Genehmigung auf den physikalische Desktop aufschalten können soll, kann man diesen als sogenannten „Vertrauens-User“ konfigurieren. Als root- oder sudo-User führt man dazu aus:
# nxserver --useredit Lehrer --trusted physical
Das Ergebnis prüft man mit:
# nxserver –userlist
Im Beispiel von vier Schülern und einem Lehrer sieht der Output von nxserver –userlist dann so aus:
NX> 149 NX users list Username NX administrator Redirected to Trusted physical for Trusted virtual for Screen sharing Access Forwarded to -------- ---------------- ------------- -------------------- ------------------- -------------- ------- ------------ Schüler1 enabled enabled Schüler2 enabled enabled Schüler3 enabled enabled Schüler4 enabled enabled Lehrer all nodes and users enabled enabled
Welcher User sich wann aufschalten kann, lässt sich noch granularer einstellen durch user- oder gruppenspezifische Definitionen.
Wenn z.B. zusätzlich noch „Schüler3“ sich ohne Genehmigung aufschalten können soll, wenn „Schüler2“ eingeloggt ist, führt man aus:
# nxserver --useredit Schüler3 --trusted physical --per-user Schüler2
Ergebnis:
# nxserver --userlist NX> 149 NX users list Username NX administrator Redirected to Trusted physical for Trusted virtual for Screen sharing Access Forwarded to -------- ---------------- ------------- -------------------- ------------------- -------------- ------- ------------ Schüler1 enabled enabled Schüler2 enabled enabled Schüler3 Schüler2 enabled enabled Schüler4 enabled enabled Lehrer all nodes and users enabled enabled
Session Management mit Profile Rules
Die sogenannten „Profile Rules“ sind ein mächtiges Instrument, mit dem sich der Zugriff auf Systemressourcen konfigurieren lässt.
Im folgenden Beispiel sollen auf einem NoMachine Terminalserver alle User in der Gruppe „Vertrieb“ kein Session Sharing machen dürfen.
Wenn die NoMachine-Gruppe „Vertrieb“ angelegt ist und die User der Gruppe zugeordnet sind, führt man diesen Befehl aus:
# nxserver --ruleadd --class session --type shadow --value no --group Vertrieb NX> 125 Adding rule for group: Vertrieb. NX> 128 Rule for group: Vertrieb added to NoMachine profiles DB.
Alle Typen von Sessions, die nicht explizit verboten sind, sind erlaubt.
Dann soll z.B. noch User „nxtest4“ nur eine einzige Applikation auf dem Server ausführen können, nämlich den Browser Firefox.
Dazu erlaubt man ihm den Sessiontyp „unix-application“, definiert den Firefox für den Sessiontyp „unix-script“ und verbietet alle anderen Session-Typen, die in der Server-Konfiguration generell erlaubt sind:
#nxserver --ruleadd --class session --type unix-application --value no --user nxtest4 #nxserver --ruleadd --class session --type unix-script --value /usr/bin/firefox --user nxtest4 #nxserver --ruleadd --class session --type unix-xsession-default -- value no --user nxtest4 #nxserver --ruleadd --class session --type unix-console --value no --user nxtest4
u.s.w. für andere Sessiontypen, soweit sie in /usr/NX/etc/server.cfg stehen.
Das Ergebnis:
#nxserver --rulelist NX> 104 Rule list: Class Type Value Apply to: ------- --------------------- ---------------- ---------------- session unix-application yes nxtest4 session unix-xsession-default no nxtest4 session unix-console no nxtest4 session unix-default no nxtest4 session unix-script /usr/bin/firefox nxtest4 session shadow no Vertrieb (group)
Wenn danach „nxtest4“ eine andere Applikation als Firefox starten will, bekommt er diese Meldung, die ihm sogar noch mitteilt, was erlaubt wäre:
Damit der User „nxtest4“ den Befehl Firefox nicht bei jeder neuen Session eingeben muss, kann er das Client-seitig vorkonfigurieren.
Dazu gibt es die Option „Save this setting in the connection file“, siehe Screenshot.
Diese Checkbox gibt es an allen möglichen Stellen. Man kann das auch im entsprechenden Sessionfile editieren und dieses auf alle relevanten Client-Rechner ausrollen. Die Client-seitige Vorkonfiguration der Sessions umfasst so viele Möglichkeiten, das wäre Stoff für einen separaten Blog.
Session Management mit remote Nodes
Ein NoMachine-Nutzer hat ein Loadbalancing Setup auf einem Enterprise Terminal Server mit zwei remote Nodes und möchte es erweitern um eine weitere remote Node auf dem eine Spezialanwendung läuft, die nur für Admins verfügbar sein soll.
Dieser Server soll nicht zum Loadbalancing gehören, also manuell wählbar sein. Eine Gruppe von Entwicklern soll nur auf die Nodes im Loadbalancing zugreifen können.
Die Liste der verfügbaren entfernten Zielrechner sieht zunächst so aus:
# nxserver --nodelist NX> 167 Node list: Node Protocol Label Status Load-B Manual-S Weight Limit -------------------- -------- ---------------- ------- ------ -------- ----- 192.168.114.214:4000 NX running yes no 192.168.114.216:4000 NX running yes no
Loadbalancing ist standardmäßig aktiviert, manuelle Node-Selektion deaktiviert. Nach Hinzufügen der entfernten Node für die Spezialanwendung legt man Profile Rules an, die zunächst beides, das Loadbalancing und die manuelle Node-Wahl erlaubt:
#nxserver --ruleadd --class feature --type node-load-balancing --value yes #nxserver --ruleadd --class feature --type manual-node-selection --value yes
Ergebnis prüfen:
# nxserver --rulelist NX> 104 Rule list: Class Type Value Apply to: ------- --------------------- ----- --------- feature node-load-balancing yes NX system feature manual-node-selection yes NX system # nxserver --nodelist NX> 167 Node list: Node Protocol Label Status Load-B Manual-S Weight Limit -------------------- -------- ---------------- ------- ------ -------- ------------ 192.168.114.214:4000 NX running yes yes 192.168.114.216:4000 NX running yes yes 192.168.114.234:4000 NX Spezialanwendung running yes yes
Die Loadbalancing-Konfiguration gilt zunächst systemweit. Noch kann jeder User auf alle Nodes zugreifen.
Nach dem Einloggen sieht das so aus, bspw. mit CentOS 6.9 Servern:
Wenn man noch User-Gruppen definiert, eine für Entwickler, die nur auf die Nodes im Loadbalancing zugreifen können, und eine für Admins, die manuellen Zugriff auf die Nodes haben sollen, dann kann man damit die Zugriffe steuern. Nach dem Hinzufügen der Regeln für die Usergruppen sieht das so aus:
# nxserver --rulelist NX> 104 Rule list: Class Type Value Apply to: ------- --------------------- ----- ------------------ feature manual-node-selection yes Admins (group) feature node-load-balancing no Admins (group) feature node-load-balancing yes Entwickler (group) feature manual-node-selection no Entwickler (group)
Dann schließt man noch die remote Node mit der Spezialanwendung vom Loadbalancing aus:
# nxserver --nodeedit 192.168.114.234:4000 --load-balancing no NX> 177 Modifying node: 192.168.114.234:4000 NX> 176 With connection type: encrypted NX> 175 With load-balancing: no NX> 811 Nodeedit process finished.
Ergebnis:
# nxserver --nodelist NX> 167 Node list: Node Protocol Label Status Load-B Manual-S WeightLimit -------------------- -------- ----- ------- ------ -------- ---------- 192.168.114.214:4000 NX running yes yes 192.168.114.216:4000 NX running yes yes 192.168.114.234:4000 NX running no yes
Admins können so weiterhin auch auf die Loadbalancing Nodes zugreifen. Will man das auch noch verbieten, editiert man diese Nodes entsprechend mit den Befehlen, die die manuelle Node-Wahl verbieten:
# nxserver --nodeedit 192.168.114.214:4000 --manual-selection no # nxserver --nodeedit 192.168.114.216:4000 --manual-selection no
Ergebnis:
# nxserver --nodelist NX> 167 Node list: Node Protocol Label Status Load-B Manual-S Weight Limit -------------------- -------- ---------------- ------- ------ -------- ------------ 192.168.114.214:4000 NX running yes no 192.168.114.216:4000 NX running yes no 192.168.114.234:4000 NX Spezialanwendung running no yes
Die Konfigurationsmöglichkeiten gehen noch viel weiter. Die Einschränkung bestimmter Usergruppen auf bestimmte remote Nodes kann kombiniert werden mit der Zuordnung zu bestimmten Session-Typen oder Applikationen wie aus Beispiel 2. Außerdem lassen sich Zugriffe auf Ressourcen wie z.B. Drucker, Filesysteme, USB-Geräte in ähnlicher Weise konfigurieren. Weitere Drehschrauben sind für den Datentransfer von oder zum Server eingerichtet worden, für die Weiterleitung von Verbindungsanfragen zu anderen Servern, für die Begrenzung der Anzahl laufender Desktops, systemweit, node- oder userspezifisch.
Wem das immer noch nicht reicht, der kann die Möglichkeit der kundenspezifischen Skripte nutzen („custom scripts“), die in den verschiedenen Stadien des Session-Aufbaus zur Verfügung stehen. So steht vor dem User-login die remote IP des Clients als Parameter zur Verfügung. Nach dem Login, aber noch vor dem Session-Aufbau stehen u.a. der Username, Sessiontyp und die node host IP als Parameter zur Verfügung für individuelle Anpassungen per Skript. Das kann z.B. ein Skript zum Mounten eines Filesystems sein, oder zum Erstellen eines Popups im Desktop des Users, oder für das Erzeugen einer Statistik.
Fazit
NoMachine hat mit Hilfe der Kunden, die ihre Wünsche über den Support-Kanal und über das NoMachine-Forum eingereicht haben, die Möglichkeiten des Session Management kontinuierlich verbessert und ausgeweitet, sodass kaum noch Wünsche übrig bleiben. Zu beachten ist allerdings, dass nicht alle Features auf allen Servertypen zur Verfügung stehen. Alle Features eines Servertyps sind jedoch bereits in den Evaluationspaketen enthalten, sodass Sie alles vorab testen können.
