Inhaltsverzeichnis
Bewertung 1
Die Kandidaten sollten in der Lage sein, einen NIS-Server zu konfigurieren und NIS Maps für wichtige Konfigurationsdateien zu erzeugen. Dieses Lernziel beinhaltet die Konfiguration eines Systems als NIS-Client, die Installation eines NIS-Slave-Servers und die Konfiguration der Durchführung der Suche von lokalen Dateien, DNS, NIS usw. in nsswitch.conf.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- nisupdate, ypbind, ypcat, ypmatch, ypserv, ypswitch, yppasswd, yppoll, yppush, ypwhich, rpcinfo
- nis.conf, nsswitch.conf, ypserv.conf
- Inhalt von /etc/nis/: netgroup, nicknames, securenets
- Makefile
Ein NIS-Server entnimmt seine Informationen aus Dateien, die als maps bezeichnet werden. Diese Dateien enthalten immer sogenannte key/value Paare, also Informationen in der Form Name/Wert. Allerdings sind diese Informationen nicht in Textform abgespeichert, sondern in der Regel im Berkley-DBM-Format.
Ein NIS-Server hat also verschiedenste solcher maps auf seinem Dateisystem gespeichert, auf die ein Client über verschiedene RPC-Aufrufe zugreifen kann. Die Maps selbst werden normalerweise aus den orginal Unix Textdateien wie /etc/passwd oder /etc/hosts aufgebaut. In manchen Fällen werden mehrere Maps aus nur einer Unix-Textdatei aufgebaut, jede einzelne map für jeweils ein key/value Paar.
NIS-Domains
Alle Rechner, die Teile ihrer Konfiguration über einen NIS-Server gemeinsam benutzen werden zu einer sogenannten NIS-Domain zusammengefasst. Diese Domain hat nichts mit der DNS-Domain zu tun, sie bezieht sich alleine auf die Frage, welche Rechner welche Informationen gemeinsam verwalten. Es handelt sich bei einer NIS-Domain also alleine um eine administrative Organisationsform, mit der ein Normaluser praktisch nicht konfrontiert wird.
Über die Zugehörigkeit zu einer NIS-Domain wird entschieden, welcher NIS-Server von welchem Host verwendet werden soll. So kann ein physikalisches Netzwerk in mehrere NIS-Domains aufgeteilt sein, die jede ihren eigenen NIS-Server zur Verfügung stellt.
Weil ein NIS-Server für seine Domain-Mitglieder lebenswichtige Informationen zur Verfügung stellt, ohne die ein Arbeiten praktisch nicht möglich ist, können mehrere NIS-Server pro NIS-Domain betrieben werden. Einer dieser Server ist der Master-Server, alle anderen sind seine Slave-Server. Der Master-Server ist der Ort, an dem Maps angelegt werden, er kümmert sich dann selbstständig darum, dass seine Informationen an die Slave-Server weitergeleitet werden.
Damit ein Client in einer NIS-Domain jetzt herausfinden kann, welcher Server für ihn zuständig ist, existiert das Programm ypbind. Jedesmal, wenn eine NIS-Abfrage von einem Client an einen Server durchgeführt wird, überprüft ypbind mittels Broadcast-Aufrufen zunächst einmal, welcher Server für die entsprechende NIS-Domain zur Verfügung steht. In einem Netz, in dem nur ein NIS-Server arbeitet ist das aber eine unnötige Arbeit, die zu hoher Netzauslastung führen kann. Aus diesem Grund kann ypbind auch so konfiguriert werden, dass immer nur ein bestimmter Server angesprochen wird.
Konfiguration eines NIS-Servers
Der erste Schritt, den wir bei der Konfiguration ausführen müssen ist die Festlegung des Namens der NIS-Domain. Dazu dient der Befehl domainname, mit dem der Systemverwalter den Namen der NIS-Domain setzen kann. Der Befehl
domainname versuch
legt also fest, dass unsere NIS-Domain jetzt „versuch“ heissen soll. Normaluser können den Befehl domainname ohne Parameter anwenden, um den Namen der verwendeten NIS-Domain zu erfragen.
Erstellen der Map-Dateien
Nach der Installation des Servers muss zunächst dafür gesorgt werden, dass das Verzeichnis für die Map-Dateien existiert. In der Regel wird dieses Verzeichnis unter /var/yp liegen und so heissen, wie die NIS-Domain, die es verwalten soll. Um also die NIS-Domain versuch aufzubauen, müssen wir ein Verzeichnis /var/yp/versuch erstellen.
Die Map-Dateien sind in einem speziellen Datenbankformat gespeichert. Um die Orginal Unix-Textdateien wie z.B. /etc/passwd in dieses Format zu konvertieren, wäre ein ziemlich umständlicher und schwer zu merkender Umgang mit sed oder awk nötig. Um diesen Vorgang abzukürzen, gibt es ein spezielles Makefile, das uns diese Arbeit abnimmt. Bei modernen Versionen wird dieses Makefile bei der Installation bereits in das Verzeichnis /var/yp installiert.
Ein einfacher Aufruf von make im Verzeichnis /var/yp erstellt jetzt die notwendigen Mapdateien ganz automatisch. Im Makefile selbst kann dazu noch editiert werden, welche Mapdateien angelegt werden sollen und an welche Slave-Server sie weitergegeben werden sollen. (Slaveserver werden normalerweise in der Datei /var/yp/ypservers aufgelistet.)
Damit das Makefile tatsächlich funktioniert, muss der NIS-Server vorher gestartet werden. In der Regel wird das über ein init-Script erledigt, da ein NIS-Server so wichtig ist, dass er grundsätzlich als Stand-Alone-Server betrieben wird. Das Binary des Servers heisst ypserv und wird vom initscript ohne weitere Parameter aufgerufen. Neben diesem Dienst werden noch ein paar weitere gestartet, zu denen später genaueres zu hören sein wird…
Absichern gegen Fremdzugriff
Damit jetzt nicht jeder Rechner des Internets auf unseren NIS-Server zugreifen kann, gibt es zwei Möglichkeiten, den Server abzusichern. Die erste ist der Mechanismus über die TCP-Wrappers. Um also nur dem Netz 192.168.1.0 Zugriff auf den Server zu gestatten, könnten wir in die Datei /etc/hosts.allow den Eintrag
ypserv: 192.168.1.
schreiben und in /etc/hosts.deny entsprechend
ypserv: ALL
Jetzt ist der Zugriff nur noch für die Rechner des in hosts.allow genannten Netzes möglich.
Die zweite Möglichkeit ist die Datei /etc/ypserv.securenets. Diese Datei legt fest, welche Rechner den NIS-Server benutzen dürfen. Das Format der Datei ist einfach, sie enthält zeilenweise Einträge der Form
Maske IP-Adresse
die festlegen, welche Adressen Zugriff bekommen. Eine entsprechende Datei für unser Beispiel mit dem Netz 192.168.1.0 sähe dann folgendermaßen aus:
# Erlaubt Verbindungen vom Localhost - zwingend erforderlich host 127.0.0.1 # entspricht 255.255.255.255 127.0.0.1 # # Alle Rechner aus 192.168.1.0 haben Zugriff 255.255.255.0 192.168.1.0 #
Die Konfigurationsdatei /etc/ypserv.conf
Diese Konfigurationsdatei ermöglicht es, festzulegen, welche Hosts auf welche Maps des Servers Zugriff haben.
Konfiguration des NIS-Clients
Die erste und wichtigste Voraussetzung für einen NIS-Client ist es, herauszubekommen, wer sein zuständiger NIS-Server ist. Diese Frage wird normalerweise über das Programm ypbind geklärt. ypbind überprüft das Netz mittels Broadcast-Nachfragen und kann so herausfinden, wer der zuständige NIS-Server ist.
In einem Netz, in dem eine geringe Fluktuation besteht, ist es aber eigentlich nicht notwendig, einen so umständlichen Vorgang zu starten, wenn sich doch sowieso wenig an der Verfügbarkeit von NIS-Servern ändern wird. Aus diesem Grund gibt es die Möglichkeit, dem ypbind Programm von vorneherein mitzuteilen, welche Server zur Verfügung stehen.
In der Datei /etc/yp.conf können solche Einträge stehen. Denkbar sind drei verschiedene Formen:
domain Nisdomäne server Hostname
Der angegebene Server Hostname wird für die NIS-Domain Nisdomäne verwendet. Es ist möglich mehrere dieser Einträge für nur eine Domain zu haben, um auch Slave-Server zu beschreiben.
domain Nisdomäne broadcast
Der übliche Broadcast-Aufruf wird verwendet, um den NIS-Server für die genannte Domain Nisdomäne herauszufinden.
ypserver Hostname
Der genannte Server Hostname wird für die lokale NIS-Domain benutzt.
Das Programm ypbind ist ein Daemon, der grundsätzlich läuft. Wenn Veränderungen an dieser Konfigurationsdatei vorgenommen wurden, so muss der Daemon entweder neu gestartet werden, oder es muss ihm ein HUP-Signal übermittelt werden, damit er die Datei neu einliesst.
Bei einem Rechner, der regelmäßig seine NIS-Domain wechselt, etwa einem Laptop, der sowohl zu Hause, als auch in der Arbeit an eine solche Domain angeschlossen ist, können auch mehrere Angaben über die verwendten Server in dieser Datei stehen:
domain zuhause server 192.168.1.1 domain firma server 172.23.45.67
Es bietet sich an, statt Hostnamen lieber gleich IP-Adressen zu nutzen, denn wenn ein eventuell benutzter DNS-Server einmal nicht zur Verfügung steht, ist ansonsten kein Zugriff auf den NIS-Server möglich.
Testen der Konfiguration
Wenn auf dem Client-Rechner alles soweit eingerichtet ist, können wir die Verfügbarkeit des Servers überprüfen. Der erste Schritt ist es, zu überprüfen, ob auf dem Server überhaupt der Portmapper die entsprechenden Dienste anbietet. Dazu dient das Programm rpcinfo, das wir jetzt folgendermaßen aufrufen:
rpcinfo -u Servername ypserv
Die Antwort sollte dann lauten
Program 100004 Version 1 ist bereit und wartet Program 100004 Version 2 ist bereit und wartet
Jetzt können wir mit dem Programm ypcat beliebige Map-Dateien des Servers in Textform ausgeben. Dazu können entweder die Namen der Mapdateien des Servers angegeben werden (etwa hosts.byname oder services.byservicname), oder es werden die Namen verwendet, die im Server in der Datei /var/yp/nicknames als Abkürzungen angegeben wurden. Der Aufruf von
ypcat hosts.byname
sollte jetzt also eine Ausgabe in der Art
192.168.100.123 versuchsserver 127.0.0.1 versuchsserver localhost
aufweisen. Wenn das soweit funktioniert, dann ist der Server und Client bereit, NIS tatsächlich einzusetzen.
Server-Mapdateien statt lokaler Datein benutzen
Um jetzt tatsächlich die Fähigkeiten von NIS einzusetzen, muss dem Client noch mitgeteilt werden, dass er nicht mehr auf die lokalen Dateien zugreifen soll, sondern auf die entsprechenden Map-Dateien des NIS-Servers. Das klingt einfach, ist aber intern gar nicht so ohne.
Praktisch alle wichtigen Unix-Tools greifen auf die eine oder andere Art auf Informationen zurück, die in diesen Dateien liegen. Bereits ein einfaches ls -l Kommando muss ja in der Lage sein, die UID und GID der Datei in lesbare Usernamen umzusetzen. Der einzige Ort, an dem diese Umsetzung stattfinden kann sind die Dateien /etc/passwd und /etc/group. Das Betriebssystem bzw. die Standard-Library des Systems bietet sogenannte System-Calls, die diese Aufgabe zentral steuern. So existiert beispielsweise der System-Call gethostbyname, der die IP-Adresse eines Hosts anhand seines Namens zurückgibt. Die Frage stellt sich jetzt, woher der Systemaufruf wissen soll, wo er nach dieser Information suchen soll, in der Datei /etc/hosts, beim nächsten zuständigen Nameserver oder über einen NIS-Server und dessen Mapdatei hosts.byname. Die Antwort auf diese Frage liegt in der Datei /etc/nsswitch.conf. Diese Datei wird von der Standard-Library – genauer gesagt von der GNU libc – abgearbeitet und enthält Hinweise auf Informationsquellen und Suchreihenfolge.
In dieser Datei könnten jetzt die folgenden Einträge stehen:
hosts: nis files dns services: files nis networks: nis files
Damit legen wir fest, dass Zugriffe auf Hostnamen zunächst über den NIS-Server, dann über die lokale Datei /etc/hosts und erst wenn das alles gescheitert ist über DNS laufen sollen. Zugriffe auf Informationen aus /etc/services werden zuerst über die lokale Datei und erst dann über NIS gemacht, Zugriffe auf die Informationen, die normalerweise in /etc/networks stehen, erfragen wir zuerst über NIS und erst wenn das gescheitert ist über die lokale Datei.
Das Wort Scheitern in diesem Zusammenhang ist missverständlich. Es geht eher darum, dass der Server, der angesprochen wurde, nicht ansprechbar ist. Erst dann wird der jeweils nächste Dienst verwendet. Das bedeutet aber, dass, wenn in unserem Beispiel der NIS-Server zwar läuft, aber die Antwort nicht kennt, die anderen Dienste gar nicht erst gefragt werden.
Um das zu ändern, kann jedem Dienst noch eine eckige Klammer mit Optionen folgen, die festlegen, was genau passieren soll, wenn der Dienst keine Antwort findet. Die Option hat folgende Form:
[Status=Aktion]
oder mit der logischen Negation von Status
[!Status=Aktion]
Der Status ergibt sich aus dem Rückgabewert des Eintrags, der vor der eckigen Klammer steht, Aktion ist entweder return (Abbruch) oder continue (mit dem nächsten Dienst in der Liste weitermachen). Status kann folgende Werte annehmen: success Kein Fehler trat auf und der gesuchte Eintrag wurde zurückgegeben. Die voreingestellte Aktion für diesen Status ist return. notfound Der Server war ansprechbar, aber er hat den gesuchten Wert nicht gefunden. Die voreingestellte Aktion in diesem Fall ist continue. unavail Der Dienst ist permanent nicht erreichbar. Voreingestellte Aktion ist continue. tryagain Der Dienst ist vorübergehend nicht erreichbar. Voreingestellte Aktion ist continue.
Ein paar Beispiele:
hosts: dns [!UNAVAIL=return] files
Wenn DNS nicht den gewünschten Datensatz zurückgibt, obwohl der Server existiert, dann wird files gar nicht aufgerufen. Files wird nur verwendet, wenn der DNS-Server ausgefallen ist.
networks: nis [NOTFOUND=return] files
Genau das selbe mit Networks, nur anders formuliert.
Die wichtigsten Zugriffe beziehen sich aber nicht auf die bisher genannten Dateien, sondern auf die Informationen in /etc/passwd und /etc/group. Bei modernen Linux-Distributionen, die mit der glibc arbeiten, genügt auch hier der Eintrag
passwd: nis files group: nis files
Um auch mit dem Shadow-Password-System zu arbeiten ist zusätzlich noch der Eintrag
shadow: nis files
nötig. Allerdings darf man nicht vergessen, dass die Verwendung von NIS das Shadow-Prinzip mehr oder weniger auf den Kopf stellt, denn jeder User kann jetzt das verschlüsselte Passwort über einen Aufruf von
ypcat shadow.byname
lesen. Und genau das sollte ja eigentlich mit Shadow vermieden werden.
Damit jetzt auch ein User, der sein Passwort wechselt, das statt in der lokalen Datei in der Map-Datei des Servers tut, muss jetzt das alte Programm /bin/passwd durch das Programm yppasswd ersetzt werden. Die beste Methode ist es, das alte Programm umzubenennen und einen Link zu erzeugen, der yppasswd jetzt als passwd anspricht:
cd /bin mv passwd passwd.org ln yppasswd passwd
Jetzt wird jedesmal, wenn ein User sein Passwort mit /bin/passwd wechselt, in Wahrheit das Programm yppasswd aufgerufen. Dieses Programm gibt das geänderte Passwort an den Daemon yppasswdd weiter, der auf dem NIS-Server läuft. Dieser Daemon trägt das neue Passwort jetzt in die entsprechende Map-Datei ein.
Um schließlich noch die Möglichkeit zu schaffen, auf einzelnen Rechnern bestimmte User entweder auszuschließen, oder ihnen andere Einstellungen zu verschaffen, etwa eine andere Startshell, kann die jeweils lokale Datenbank (also hier /etc/passwd) noch besondere Einträge beinhalten, die jeweils mit einem Plus oder Minuszeichen beginnen. Dazu sind allerdings zwei Änderungen notwendig:
- Der Eintrag für passwd in /etc/nsswitch.conf muss den Kompatibilitätsmodus für alte NIS-Versionen enthalten: passwd: compat
- Die letzte Zeile von /etc/passwd muss ein +-Zeichen oder ein Pluszeichen gefolgt von 6 Doppelpunkten sein.
Beginnt ein solcher Eintrag mit einem Plus-Zeichen (+), so werden die dort stehenden Informationen statt denen benutzt, die der NIS-Server anbietet. Um dem User Otto statt der bash die C-Shell auf einem Client als Startshell zu geben, kann in die Datei /etc/passwd der Eintrag
+otto::::::/bin/csh
aufgenommen werden. Alle leeren Felder werden weiterhin über NIS erfragt. Um aber dem User Peter den Zugriff auf unseren Rechner ganz zu verbieten, obwohl er einen Eintrag im NIS-Server hat können wir folgenden Eintrag vornehmen:
-peter::::::
Weitere Programme im Zusammenhang von NIS
Neben den schon genannten Programmen ypbind und ypcat gibt es noch eine ganze Menge weiterer Programme, die in diesem Zusammenhang interessant und von LPI gefordert sind. Hier folgt eine kurze Zusammenfassung dieser Tools: ypmatch Mit ypmatch können einzelne Werte anhand ihrer Schlüsselfelder aus bestimmten Map-Dateien einer bestimmten NIS-Domain erfragt werden. Mit dem Aufruf
ypmatch hans passwd.byname
wird der Datensatz angezeigt, der über den User hans in der Datei passwd.byname im NIS-Server der aktuellen NIS-Domain gespeichert wird. Außerdem können die Nicknames (Spitznamen, Abkürzungen) der Mapdateinamen über
ypmatch -x
erfragt werden. yppoll Das Programm yppoll gibt den Zeitstempel und den Masterserver einer NIS-Mapdatei zurück. Mit der Option -h server kann ein bestimmter Server angefragt werden, mit -d domain kann eine bestimmte NIS-Domain festgelegt werden. Ohne diese Schalter bezieht sich yppoll auf die aktuelle Domain, deren Mitglied wir sind und sucht sich den Server selbstständig (über ypbind). yppush Das Programm yppush dient dazu, die veränderten Map-Dateien eines Master-Servers an alle angeschlossenen Slave-Server weiterzuleiten. Normalerweise wird es vom Makefile aufgerufen, wenn Veränderungen an Orginal-Dateien vorgenommen wurden und die Zeile NOPUSH=true im Makefile auskommentiert ist. ypwhich Das Programm ypwhich gibt den NIS-Server oder den Verwalter der Master-Maps zurück. Mit der Option -d domain kann statt der aktuellen NIS-Domain eine andere angegeben werden, deren NIS-Server dann zurückgegeben wird. Wird dem Befehl ein Rechnername mitgegeben, so wird ypwhich nicht den NIS-Server unseres Rechners, sondern den des übergebenen Hostnamens zurückgeben.
Einrichten eines NIS Slave Servers
Ein Slave-Server hat primär ähnliche Aufgaben wie ein Masterserver, mit dem Unterschied, dass alle Veränderungen wie etwa Passwörter nur auf dem Masterserver vorgenommen werden. Der Masterserver sorgt dafür, dass seine Informationen auch dem Slave-Server übermittelt werden, so dass im Falle eines Falles, wenn der Masterserver gerade nicht erreichbar ist, der Slave-Server einspringen kann.
Die erste und auch logische Voraussetzung für den Betrieb eines Slave-Servers ist es, dass bereits ein Masterserver existiert. Die zweite Voraussetzung ist, dass der Rechner, der als Slave-Server konfiguriert werden soll, bereits als NIS-Client konfiguriert wurde.
Um den Rechner jetzt als Slave-Server einzurichten genügt der Aufruf von
ypinit -s Masterserver
Durch die Angabe von -s Masterserver wird der angegebene Masterserver veranlasst, seine Maps zu übertragen. Der Name des Slave-Servers sollte dann manuell in die Datei /var/yp/ypservers eingetragen werden.
Auf dem Masterserver sollte (automatisch) durch das Init-Script von NIS bereits das Programm rpc.ypxfrd gestartet worden sein, das sich darum kümmert, das Änderungen an Maps automatisch an den Slave-Server weitergegeben werden.
Netzgruppen
Auch wenn Netzgruppen nicht alleine mit NIS zu tun haben (zumindest seit Einführung der glibc) sind sie hier noch einmal Thema. Es handelt sich um Gruppen von Usern, die in der Datei /etc/netgroup definiert werden. Sie haben nichts mit den normalen Usergruppen von Unix/Linux gemein, sondern ermöglichen es, bestimmten Usern einen Login auf bestimmten Rechnern zu erlauben oder zu verbieten.
Wenn ein Netz über NIS verwaltet wird, dann haben wir auf den ersten Blick zwar die Situation, dass so endlich eine zentrale Verwaltung der User möglich ist, aber auf den zweiten Blick kommt der Nachteil hinzu, dass jetzt alle User des Netzes (bzw. alle, die in der passwd-Map auf dem NIS-Server eingetragen sind) sich jetzt auf jedem Rechner einloggen können. Das kann eventuell nicht gewünscht sein.
Wir haben zwar oben die Möglichkeit kennengelernt, dass wir über Einträge in der lokalen /etc/passwd einzelne User ausschließen können, indem wir Einträge in der Form
-Username::::::
vornehmen und in /etc/nsswitch.conf den Kompatibilitätsmodus aktivieren. Das kann in einem großen Netz allerdings sehr aufwendig sein, wenn wir jetzt in jedem Rechner hunderte von Usern ausschließen müssen. Der Vorteil von NIS wäre gleich wieder dahin…
Die Datei /etc/netgroup bietet uns die Möglichkeit, Gruppen von Usern zu definieren, die dann in /etc/passwd als erlaubte User (mit führendem +) oder als verbotene User (mit führendem -) eingetragen werden können. Die Definition von Usergruppen in dieser Datei läuft nach dem Schema
Gruppenname (host,user,domain) (host,user,domain) ...
Jeder User wird also als ein User eines Rechners und einer Domain verstanden. Wenn Einträge weggelassen werden, dann gelten sie als Wildcards, meinen also z.B. alle hosts. Eine Gruppe „poweruser“ könnte also netzweit so formuliert werden:
poweruser (,efka,) (,peter,) (,hans,)
Damit wären die drei User efka, peter und hans Mitglieder der Gruppe Poweruser, egal auf welchem Host und in welcher Domain. Ein Eintrag in der lokalen Datei /etc/passwd könnte jetzt folgendermaßen aussehen:
+@poweruser:::::: -:*::::::/bin/false
Damit wären jetzt nur die Mitglieder der Gruppe poweruser berechtigt, sich auf dem Rechner einzuloggen. Gruppennamen werden in der Passwortdatei durch ein führendes @-Zeichen gekennzeichnet.
Genausogut ist es natürlich möglich, bestimmte Gruppen auszuschließen, indem statt einem Pluszeichen eben ein Minuszeichen Verwendung findet.
In /etc/netgroup können Gruppen auch aus anderen Gruppen bestehen, es wäre also möglich zu schreiben:
poweruser (,efka,) (,peter,) (,hans,) daus (,michael,) (,otto,) (,karl,) alle poweruser daus (,chef,)
Die Gruppe alle bestünde jetzt also aus den Mitgliedern der Gruppe poweruser und denen der Gruppe daus und dem User chef.
Der Trick an der ganzen Sache ist jetzt natürlich wieder der, dass die Datei /etc/netgroup auch über NIS verwaltet wird. Das heisst, alle Gruppen sind auf allen Rechnern gleich, aber es gibt z.B. für jeden Rechner eine Gruppe, die die User zusammenfasst, die auf ihm arbeiten dürfen. In der zentralen Datei /etc/netgroup des NIS-Servers könnten so Gruppen für jede Workstation des Netzes formuliert werden:
rechner1user (,hans,) (,peter,) (,michael,) rechner2user (,otto,) (,karl,) (,gabi,) (,hans,) rechner3user (,petra,) (,karl,) (,hugo,)
Auf Rechner1 wäre jetzt eben ein Eintrag mit +@rechner1user:::::: in /etc/passwd, auf Rechner2 ein entsprechender mit +@rechner2user:::::: und so weiter. Um einem User jetzt zu erlauben, sich auf einem bestimmten Rechner einzuloggen, muss so nur der Eintrag in die Netzgruppe dieses Rechners erfolgen.