How-to: Session Management bei NoMachine

Seit über 10 Jahren ist Thinking Objects Premium-Partner für Vertrieb und Integration der Desktop-Virtualisierungslösung NoMachine der Firma Medialogic. Der NoMachine-Server macht die Darstellung des Bildschirminhalts eines entfernten Rechners möglich.

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

CAPTCHA *