30.4. NIS/YP – Network Information Service

Beigetragen von Bill Swingle.
Erweitert von Eric Ogren und Udo Erdelhoff.

30.4.1. Was ist NIS?

NIS wurde von Sun Microsystems entwickelt, um UNIX®-Systeme (ursprünglich SunOS™) zentral verwalten zu können. Mittlerweile hat es sich zu einem Industriestandard entwickelt, der von allen wichtigen UNIX®-Systemen (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD und anderen) unterstützt wird.

NIS war ursprünglich als Yellow Pages bekannt, aus markenrechtlichen Gründen wurde der Name aber geändert. Die alte Bezeichnung (sowie die Abkürzung YP) wird aber nach wie vor häufig verwendet.

Bei NIS handelt es sich um ein RPC-basiertes Client/Server-System. Eine Gruppe von Rechnern greift dabei innerhalb einer NIS-Domäne auf gemeinsame Konfigurationsdateien zu. Ein Systemadministrator wird dadurch in die Lage versetzt, NIS-Clients mit minimalem Aufwand einzurichten, sowie Änderungen an der Systemkonfiguration von einem zentralen Ort aus durchzuführen.

Die Funktion entspricht dem Domänensystem von Windows NT®; auch wenn sich die interne Umsetzung unterscheidet, sind die Basisfunktionen vergleichbar.

30.4.2. NIS-Begriffe und -Prozesse

Es gibt verschiedene Begriffe und Anwenderprozesse, die erläutert werden, wenn NIS unter FreeBSD implementiert wird, unabhängig davon, ob das System ein NIS-Server oder ein NIS-Client ist:

BegriffBeschreibung
NIS-DomänennameEin NIS-Masterserver sowie alle Clients (inklusive der Slaveserver) haben einen NIS-Domänennamen. Dieser hat (ähnlich den Windows NT®-Domänennamen) nichts mit DNS zu tun.
rpcbindMuss laufen, damit RPC (Remote Procedure Call, ein von NIS verwendetes Netzwerkprotokoll) funktioniert. NIS-Server sowie Clients funktionieren ohne rpcbind nicht.
ypbindBindet einen NIS-Client an seinen NIS-Server. Der Client bezieht den NIS-Domänennamen vom System und stellt über das RPC-Protokoll eine Verbindung zum NIS-Server her. ypbind ist der zentrale Bestandteil der Client-Server-Kommunikation in einer NIS-Umgebung. Wird >ypbind auf einem Client beendet, ist dieser nicht mehr in der Lage, auf den NIS-Server zuzugreifen.
ypservSollte nur auf dem NIS-Server laufen, da es sich um den Serverprozess selbst handelt. Wenn ypserv(8) nicht mehr läuft, kann der Server nicht mehr auf NIS-Anforderungen reagieren (wenn ein Slaveserver existiert, kann dieser als Ersatz fungieren). Einige NIS-Systeme (allerdings nicht das von FreeBSD) versuchen allerdings erst gar nicht, sich mit einem anderen Server zu verbinden, wenn der bisher verwendete Server nicht mehr reagiert. Die einzige Lösung dieses Problems besteht dann darin, den Serverprozess (oder gar den Server selbst) oder den ypbind-Prozess auf dem Client neu zu starten.
rpc.yppasswddEin weiterer Prozess, der nur auf dem NIS-Masterserver laufen sollte. Es handelt sich um einen Daemonprozess, der es NIS-Clients ermöglicht, sich auf dem NIS-Masterserver anzumelden, um ihr Passwort zu ändern.

30.4.3. Wie funktioniert NIS?

In einer NIS-Umgebung gibt es drei Rechnerarten: Masterserver, Slaveserver und Clients. Server dienen als zentraler Speicherort für Rechnerkonfigurationen. Masterserver speichern die maßgebliche Kopie dieser Informationen, während Slaveserver diese Informationen aus Redundanzgründen spiegeln. Die Clients beziehen ihre Informationen immer vom Server.

Auf diese Art und Weise können Informationen aus verschiedenen Dateien von mehreren Rechnern gemeinsam verwendet werden. master.passwd, group, und hosts werden oft gemeinsam über NIS verwendet. Immer, wenn ein Prozess auf einem Client auf Informationen zugreifen will, die normalerweise in lokalen Dateien vorhanden wären, wird stattdessen eine Anfrage an den NIS-Server gestellt, an den der Client gebunden ist.

30.4.3.1. Arten von NIS-Rechnern

  • Ein NIS-Masterserver verwaltet, ähnlich einem Windows NT®-Domänencontroller, die von allen NIS-Clients gemeinsam verwendeten Dateien. passwd, group, sowie verschiedene andere von den Clients verwendete Dateien existieren auf dem Masterserver.

    Anmerkung:

    Ein Rechner kann auch für mehrere NIS-Domänen als Masterserver fungieren. Dieser Abschnitt konzentriert sich im Folgenden allerdings auf eine relativ kleine NIS-Umgebung.

  • NIS-Slaveserver. Ähnlich einem Windows NT®-Backupdomänencontroller, verwalten NIS-Slaveserver Kopien der Daten des NIS-Masterservers. NIS-Slaveserver bieten die Redundanz, die für kritische Umgebungen benötigt wird. Zusätzlich entlasten Slaveserver den Masterserver: NIS-Clients verbinden sich immer mit dem NIS-Server, der zuerst reagiert. Dieser Server kann auch ein Slaveserver sein.

  • NIS-Clients. NIS-Clients identifizieren sich gegenüber dem NIS-Server (ähnlich den Windows NT®-Workstations), um sich am Server anzumelden.

30.4.4. NIS/YP konfigurieren

Dieser Abschnitt beschreibt an Hand eines Beispiels die Einrichtung einer NIS-Umgebung.

30.4.4.1. Planung

Nehmen wir an, es handelt sich um ein kleines Universitätsnetz. Dieses Netz besteht aus fünfzehn FreeBSD-Rechnern, für die derzeit keine zentrale Verwaltung existiert. Jeder Rechner hat also eine eigene Version von /etc/passwd und /etc/master.passwd. Diese Dateien werden manuell synchron gehalten; wird ein neuer Benutzer angelegt, so muss dies auf allen fünfzehn Rechnern manuell erledigt werden. Dieses Universitätsnetz würde eindeutig von der Installation von zwei NIS-Servern profitieren.

In Zukunft soll das Netz also wie folgt aussehen:

RechnernameIP-AdresseRechneraufgabe
ellington10.0.0.2NIS-Master
coltrane10.0.0.3NIS-Slave
basie10.0.0.4Workstation der Fakultät
bird10.0.0.5Clientrechner
cli[1-11]10.0.0.[6-17]Verschiedene andere Clients

Wenn erstmalig ein NIS-Schema eingerichtet wird, sollte es im Vorraus sorgfältig geplant werden. Unabhängig von der Größe des Netzwerks müssen einige Entscheidungen im Rahmen des Planungsprozesses getroffen werden.

30.4.4.1.1. Einen NIS-Domänennamen wählen

Dies muss nicht der übliche Domainname sein. Es handelt sich vielmehr um den NIS-Domainnamen. Wenn ein Client Informationen anfordert, ist in dieser Anforderung der Name der NIS-Domäne enthalten. Dadurch weiß jeder Server im Netzwerk, auf welche Anforderung er antworten muss. Stellen Sie sich den NIS-Domänennamen als den Namen einer Gruppe von Rechnern vor, die etwas gemeinsam haben.

Manchmal wird der Name der Internetdomäne auch für die NIS-Domäne verwendet. Dies ist allerdings nicht empfehlenswert, da dies bei der Behebung von Problemen verwirrend sein kann. Der Name der NIS-Domäne sollte innerhalb des Netzwerks einzigartig sein. Hilfreich ist es, wenn der Name die Gruppe der in ihr zusammengefassten Rechner beschreibt. Die Kunstabteilung von Acme Inc. hätte daher die NIS-Domäne acme-art. Für dieses Beispiel wird der Name test-domain verwendet.

Es gibt jedoch auch Betriebssysteme (vor allem SunOS™), die als NIS-Domänennamen den Namen der Internetdomäne verwenden. Wenn dies für einen oder mehrere Rechner des Netzwerks zutrifft, muss der Name der Internetdomäne als NIS-Domänennamen verwendet werden.

30.4.4.1.2. Anforderungen an den Server

Wenn ein NIS-Server einrichtet wird, müssen einige Dinge beachtet werden. Eine unangenehme Eigenschaft von NIS ist die Abhängigkeit der Clients vom Server. Wenn sich der Client nicht über den Server mit seiner NIS-Domäne verbinden kann, wird der Rechner oft unbenutzbar, da das Fehlen von Benutzer- und Gruppeninformationen zum Einfrieren des Clients führt. Daher sollten Sie für den Server einen Rechner auswählen, der nicht regelmäßig neu gestartet werden muss und der nicht für Testversuche verwendet wird. Idealerweise handelt es sich um einen alleinstehenden Rechner, dessen einzige Aufgabe es ist, als NIS-Server zu dienen. Wenn das Netzwerk nicht zu stark ausgelastet ist, ist es auch möglich, den NIS-Server als weiteren Dienst auf einem anderen Rechner laufen zu lassen. Wenn jedoch ein NIS-Server ausfällt, wirkt sich dies negativ auf alle NIS-Clients aus.

30.4.4.2. NIS-Server

Die verbindlichen Kopien aller NIS-Informationen befinden sich auf einem einzigen Rechner, dem NIS-Masterserver. Die Datenbanken, in denen die Informationen gespeichert sind, bezeichnet man als NIS-Maps. Unter FreeBSD werden diese Maps unter /var/yp/[domainname] gespeichert, wobei [domainname] der Name der NIS-Domäne ist. Ein einzelner NIS-Server kann gleichzeitig mehrere NIS-Domänen verwalten, daher können auch mehrere Verzeichnisse vorhanden sein. Jede Domäne verfügt über ein eigenes Verzeichnis sowie einen eigenen, von anderen Domänen unabhängigen Satz von NIS-Maps.

NIS-Master- und Slaveserver verwenden den ypserv-Daemon, um NIS-Anfragen zu bearbeiten. ypserv empfängt eingehende Anfragen der NIS-Clients, ermittelt aus der angeforderten Domäne und Map einen Pfad zur entsprechenden Datenbank, und sendet die angeforderten Daten von der Datenbank zum Client.

30.4.4.2.1. Einen NIS-Masterserver einrichten

Abhängig von den Anforderungen ist die Einrichtung eines NIS-Masterservers relativ einfach, da NIS von FreeBSD bereits in der Standardkonfiguration unterstützt wird. Er muss nur durch Hinzufügen der folgenden Zeilen in /etc/rc.conf aktiviert werden:

  1. nisdomainname="test-domain"

    Diese Zeile setzt den NIS-Domänennamen auf test-domain, wenn Sie das Netzwerk initialisieren (beispielsweise nach einem Systemstart).

  2. nis_server_enable="YES"

    Dadurch werden die NIS-Serverprozesse gestartet.

  3. nis_yppasswdd_enable="YES"

    Durch diese Zeile wird der rpc.yppasswdd-Daemon aktiviert, der, wie bereits erwähnt, die Änderung von NIS-Passwörtern von einem Client aus ermöglicht.

Anmerkung:

In Abhängigkeit der NIS-Konfiguration können weitere Einträge erforderlich sein. Weitere Informationen finden sich im Abschnitt NIS-Server, die auch als NIS-Clients arbeiten.

Nachdem obige Parameter konfiguriert wurden, muss noch /etc/netstart als Superuser ausgeführt werden, um alles entsprechend den Vorgaben in /etc/rc.conf einzurichten. Als letzter Schritt muss, bevor die NIS-Maps einrichtet werden können, ypserv-Daemon manuell gestartet werden:

# service ypserv start
30.4.4.2.2. Die NIS-Maps initialisieren

NIS-Maps sind Datenbanken, die sich im Verzeichnis /var/yp befinden. Sie werden am NIS-Masterserver aus den Konfigurationsdateien unter /etc erzeugt. Einzige Ausnahme: /etc/master.passwd. Dies ist auch sinnvoll, da die Passwörter für root- oder andere Administratorkonten nicht an alle Server der NIS-Domäne verteilt werden sollten. Deshalb werden die primären Passwort-Dateien konfiguriert, bevor die NIS-Maps initialisiert werden:

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

Es ist ratsam, alle Systemkonten (wie bin, tty, kmem oder games), sowie alle Konten, die nicht an die NIS-Clients weitergeben werden sollen, wie beispielsweise root und alle Konten mit der UID 0 (=Superuser) zu entfernen.

Anmerkung:

Es muss dafür gesorgt werden, dass /var/yp/master.passwd weder von der Gruppe noch von der Welt gelesen werden kann (Zugriffsmodus 600)! Dafür kann das Kommando chmod entsprechend benutzt werden.

Nun können die NIS-Maps initialisiert werden. FreeBSD verwendet dafür das Skript ypinit (lesen Sie dazu auch ypinit(8)). Dieses Skript ist auf fast allen UNIX®-Betriebssystemen verfügbar. Bei Digitals UNIX/Compaq Tru64 UNIX nennt es sich allerdings ypsetup. Da wir Maps für einen NIS-Masterserver erzeugen, verwenden wir ypinit mit der Option -m. Nachdem Sie die beschriebenen Aktionen durchgeführt haben, erzeugen Sie nun die NIS-Maps:

ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server   :  ellington
next host to add:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..output from map generation..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

Dadurch erzeugt ypinit /var/yp/Makefile aus der Datei /var/yp/Makefile.dist. Durch diese Datei wird festgelegt, dass in einer NIS-Umgebung mit nur einem Server gearbeitet wird und dass alle Clients unter FreeBSD laufen. Da test-domain aber auch über einen Slaveserver verfügt, muss /var/yp/Makefile entsprechend angepasst werden:

ellington# vi /var/yp/Makefile

Sie sollten die Zeile

NOPUSH = "True"

auskommentieren (falls dies nicht bereits der Fall ist).

30.4.4.2.3. Einen NIS-Slaveserver einrichten

Ein NIS-Slaveserver ist noch einfacher einzurichten als ein Masterserver. Melden Sie sich am Slaveserver an und ändern Sie /etc/rc.conf analog zum Masterserver. Der einzige Unterschied besteht in der Verwendung der Option -s, wenn Sie ypinit aufrufen. Die Option -s erfordert den Namen des NIS-Masterservers, daher sieht unsere Ein- und Ausgabe wie folgt aus:

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.

Es sollte nun ein Verzeichnis namens /var/yp/test-domain existieren. Die Kopien der NIS-Masterserver-Maps sollten sich in diesem Verzeichnis befinden. Allerdings müssen diese Daten immer aktuell sein. Die folgenden Einträge in /etc/crontab des NIS-Slaveservers erledigen diese Aufgabe:

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

Diese zwei Zeilen zwingen den Slaveserver, seine Maps mit denen des Masterservers zu synchronisieren. Diese Einträge sind nicht zwar nicht unbedingt nötig, da der Masterserver automatisch versucht, alle Änderungen seiner NIS-Maps an seine Slaveserver weiterzugeben. Da Passwortinformationen aber auch für nur vom Slaveserver abhängige Systeme vital sind, ist es eine gute Idee, diese Aktualisierungen zu erzwingen. Besonders wichtig ist dies in stark ausgelasteten Netzen, in denen Map-Aktualisierungen unvollständig sein könnten.

Führen Sie nun /etc/netstart auch auf dem Slaveserver aus, um den NIS-Server erneut zu starten.

30.4.4.3. NIS-Clients

Ein NIS-Client bindet sich unter Verwendung des ypbind-Daemons an einen NIS-Server. Das ypbind-Kommando prüft die Standarddomäne des Systems (die durch domainname gesetzt wird), und beginnt RPCs über das lokale Netzwerk zu verteilen (broadcast). Diese Anforderungen legen den Namen der Domäne fest, für die ypbind eine Bindung erzeugen will. Wenn der Server der entsprechenden Domäne eine solche Anforderung erhält, schickt er eine Antwort an ypbind. ybind speichert daraufhin die Adresse des Servers. Wenn mehrere Server verfügbar sind (beispielsweise ein Master- und mehrere Slaveserver), verwendet ypbind die erste erhaltene Adresse. Ab diesem Zeitpunkt richtet der Client alle Anfragen an genau diesen Server. ypbind pingt den Server gelegentlich an, um sicherzustellen, dass der Server funktioniert. Antwortet der Server innerhalb eines bestimmten Zeitraums nicht (Timeout), markiert ypbind die Domäne als ungebunden und beginnt erneut, RPCs über das Netzwerk zu verteilen, um einen anderen Server zu finden.

30.4.4.3.1. Einen NIS-Client konfigurieren

Einen FreeBSD-Rechner als NIS-Client einzurichten, ist recht einfach.

  1. Fügen Sie folgende Zeilen in /etc/rc.conf ein, um den NIS-Domänennamen festzulegen, und um ypbind bei der Initialisierung des Netzwerks zu starten:

    nisdomainname="test-domain"
    nis_client_enable="YES"
  2. Um alle Passworteinträge des NIS-Servers zu importieren, löschen Sie alle Benutzerkonten in /etc/master.passwd und fügen mit vipw folgende Zeile am Ende der Datei ein:

    +:::::::::

    Anmerkung:

    Diese Zeile legt für alle gültigen Benutzerkonten der NIS-Server-Maps einen Zugang an. Es gibt verschiedene Wege, den NIS-Client durch Änderung dieser Zeile zu konfigurieren. Lesen Sie dazu auch den Abschnitt über Netzgruppen weiter unten. Weitere detaillierte Informationen finden Sie im Buch Managing NFS and NIS von O'Reilly.

    Anmerkung:

    Denken Sie daran, zumindest ein lokales Benutzerkonto, das nicht über NIS importiert wird, in Ihrer /etc/master.passwd zu behalten. Dieser Benutzer sollte außerdem ein Mitglied der Gruppe wheel sein. Wenn es mit NIS Probleme gibt, können Sie diesen Zugang verwenden, um sich anzumelden, root zu werden und das Problem zu beheben.

  3. Um alle möglichen Gruppeneinträge vom NIS-Server zu importieren, fügen Sie folgende Zeile in /etc/group ein:

    +:*::

Um den NIS-Client sofort zu starten, führen Sie als Superuser die folgenden Befehle aus:

# /etc/netstart
# service ypbind start

Danach sollte ypcat passwd die passwd-Map des NIS-Servers anzeigen können.

30.4.5. Sicherheit unter NIS

Im Allgemeinen kann jeder entfernte Anwender einen RPC an ypserv(8) schicken, um den Inhalt der NIS-Maps abzurufen, falls er den NIS-Domänennamen kennt. Um solche unautorisierten Transaktionen zu verhindern, unterstützt ypserv(8) securenets, durch die man den Zugriff auf bestimmte Rechner beschränken kann. ypserv(8) versucht, beim Systemstart die Informationen über securenets aus /var/yp/securenets zu laden.

Anmerkung:

Die Datei securenets kann auch in einem anderen Verzeichnis stehen, das mit der Option -p angegeben wird. Diese Datei enthält Einträge, die aus einer Netzwerkadresse und einer Netzmaske bestehen, die durch Leerzeichen getrennt werden. Kommentarzeilen beginnen mit #. /var/yp/securnets könnte beispielsweise so aussehen:

# allow connections from local host -- mandatory
127.0.0.1     255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0      255.255.240.0

Wenn ypserv(8) eine Anforderung von einer zu diesen Regeln passenden Adresse erhält, wird die Anforderung bearbeitet. Gibt es keine passende Regel, wird die Anforderung ignoriert und eine Warnmeldung aufgezeichnet. Wenn /var/yp/securenets nicht vorhanden ist, erlaubt ypserv Verbindungen von jedem Rechner aus.

ypserv unterstützt auch das TCP-Wrapper-Paket von Wietse Venema. Mit diesem Paket kann der Administrator für Zugriffskontrollen die Konfigurationsdateien von TCP-Wrapper anstelle von /var/yp/securenets verwenden.

Anmerkung:

Während beide Kontrollmechanismen einige Sicherheit gewähren, beispielsweise durch privilegierte Ports, sind sie gegenüber IP spoofing-Attacken verwundbar. Jeder NIS-Verkehr sollte daher von einer Firewall blockiert werden.

Server, die /var/yp/securenets verwenden, können Schwierigkeiten bei der Anmeldung von Clients haben, die ein veraltetes TCP/IP-Subsystem besitzen. Einige dieser TCP/IP-Subsysteme setzen alle Rechnerbits auf Null, wenn Sie einen Broadcast durchführen und/oder können die Subnetzmaske nicht auslesen, wenn sie die Broadcast-Adresse berechnen. Einige Probleme können durch Änderungen der Clientkonfiguration behoben werden. Andere hingegen lassen sich nur durch das Entfernen des betreffenden Rechners aus dem Netzwerk oder den Verzicht auf /var/yp/securenets umgehen.

Die Verwendung von /var/yp/securenets auf einem Server mit einem solch veralteten TCP/IP-Subsystem ist eine sehr schlechte Idee, die zu einem Verlust der NIS-Funktionalität für große Teile Ihres Netzwerks führen kann.

Die Verwendung der TCP-Wrapper verlangsamt die Reaktion des NIS-Servers. Diese zusätzliche Reaktionszeit kann in Clientprogrammen zu Timeouts führen. Dies vor allem in Netzwerken, die stark ausgelastet sind, oder nur über langsame NIS-Server verfügen. Wenn ein oder mehrere der Clientsysteme dieses Problem aufweisen, sollten Sie die betreffenden Clients in NIS-Slaveserver umwandeln, und diese an sich selbst binden.

30.4.6. Bestimmte Benutzer an der Anmeldung hindern

In unserem Labor gibt es den Rechner basie, der nur für Mitarbeiter der Fakultät bestimmt ist. Wir wollen diesen Rechner nicht aus der NIS-Domäne entfernen, obwohl passwd des NIS-Masterservers Benutzerkonten sowohl für Fakultätsmitarbeiter als auch für Studenten enthält. Was können wir also tun?

Es gibt eine Möglichkeit, bestimmte Benutzer an der Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn diese in der NIS-Datenbank vorhanden sind. Dazu muss lediglich an diesem Rechner der Eintrag -Benutzername und die richtige Anzahl von Doppelpunkten an das Ende von /etc/master.passwd gesetzt werden, wobei Benutzername der zu blockierende Benutzername ist. Die Zeile mit dem geblockten Benutzer muss dabei vor der + Zeile, für zugelassene Benutzer stehen. Diese Änderung sollte bevorzugt durch vipw erledigt werden, da vipw Änderungen an /etc/master.passwd auf Plausibilität überprüft und nach erfolgter Änderung die Passwortdatenbank automatisch aktualisiert. Um also den Benutzer bill an der Anmeldung am Rechner basie zu hindern, geht man wie folgt vor:

basie# vipw
[add -bill to the end, exit]
vipw: rebuilding the database...
vipw: done

basie# cat /etc/master.passwd

root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
-bill:::::::::
+:::::::::

basie#

30.4.7. Netzgruppen verwenden

Beigetragen von Udo Erdelhoff.

Die im letzten Abschnitt beschriebene Methode eignet sich besonders, wenn spezielle Regeln für wenige Benutzer oder wenige Rechner benötigt werden. In großen Netzwerken werden Administratoren allerdings mit Sicherheit vergessen, einige Benutzer von der Anmeldung an bestimmten Rechnern auszuschließen. Oder sie werden gezwungen sein, jeden Rechner einzeln zu konfigurieren. Dadurch verlieren sie aber den Hauptvorteil von NIS: die zentrale Verwaltung.

Die Lösung für dieses Problem sind Netzgruppen. Ihre Aufgabe und Bedeutung ist vergleichbar mit normalen, von UNIX-Dateisystemen verwendeten Gruppen. Die Hauptunterschiede sind das Fehlen einer numerischen ID sowie die Möglichkeit, Netzgruppen zu definieren, die sowohl Benutzer als auch andere Netzgruppen enthalten.

Netzgruppen wurden entwickelt, um große, komplexe Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. Sie sind also von Vorteil in solchen Situationen. Andererseits ist es dadurch beinahe unmöglich, Netzgruppen mit einfachen Beispielen zu erklären. Das hier verwendete Beispiel veranschaulicht dieses Problem.

Nehmen wir an, dass die erfolgreiche Einführung von NIS die Aufmerksamkeit eines Vorgesetzten geweckt hat. Die nächste Aufgabe besteht nun darin, die NIS-Domäne um zusätzliche Rechner zu erweitern. Die folgenden Tabellen enthalten die neuen Benutzer und Rechner inklusive einer kurzen Beschreibung.

Benutzername(n)Beschreibung
alpha, betaBeschäftigte der IT-Abteilung
charlie, deltaDie neuen Lehrlinge der IT-Abteilung
echo, foxtrott, golf, ...Normale Mitarbeiter
able, baker, ...Externe Mitarbeiter
Rechnername(n)Beschreibung
war, death, famine, pollutionDie wichtigsten Server. Nur IT-Fachleute dürfen sich an diesen Rechnern anmelden.
pride, greed, envy, wrath, lust, slothWeniger wichtige Server. Alle Mitarbeiter der IT-Abteilung dürfen sich auf diesen Rechnern anmelden.
one, two, three, four, ...Gewöhnliche Arbeitsrechner. Nur die wirklichen Mitarbeiter dürfen diese Rechner verwenden.
trashcanEin sehr alter Rechner ohne kritische Daten. Sogar externe Mitarbeiter dürfen diesen Rechner verwenden.

Beim Versuch, diese Einschränkungen umzusetzen, indem jeder Benutzer einzeln blockiert wird, müsste auf jedem System für jeden Benutzer eine entsprechende Zeile in passwd eingefügt werden. Wird nur ein Eintrag vergessen, kann das erhebliche Probleme verursachen. Es mag noch möglich sein, dies während der Erstinstallation zu erledigen, im täglichen Betrieb kann jedoch jemand vergessen, die entsprechenden Einträge für neue Benutzer anzulegen.

Die Verwendung von Netzgruppen hat in dieser Situation mehrere Vorteile. Nicht jeder Benutzer muss einzeln verwaltet werden; stattdessen werden die Benutzer einer Netzgruppe zugewiesen und allen Mitgliedern dieser Gruppe wird die Anmeldung an einem Server erlaubt oder verwehrt. Wird ein neuer Rechner hinzugefügt, müssen die Zugangsbeschränkungen nur für die Netzgruppen festlegelegt werden. Wird ein neuer Benutzer angelegt, muss er nur einer oder mehreren Netzgruppen zugewiesen werden. Diese Veränderungen sind voneinander unabhängig; Anweisungen der Form für diese Kombination aus Benutzer und Rechner mache Folgendes ... sind nicht mehr nötig. Wenn die Einrichtung von NIS sorgfältig geplant wurde, muss nur noch eine zentrale Konfigurationsdatei bearbeitet werden, um den Zugriff auf bestimmte Rechner zu erlauben oder zu verbieten.

Der erste Schritt ist die Initialisierung der NIS-Maps der Netzgruppe. ypinit(8) kann dies unter FreeBSD nicht automatisch durchführen. Sind die Maps aber erst einmal erzeugt, werden sie jedoch von NIS problemlos unterstützt. Um eine leere Map zu erzeugen, geben Sie Folgendes ein:

ellington# vi /var/yp/netgroup

Danach legen Sie die Einträge an. Für unser Beispiel benötigen wir mindestens vier Netzgruppen: IT-Beschäftige, IT-Lehrlinge, normale Beschäftigte sowie Praktikanten.

IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)

Bei IT_EMP, IT_APP usw. handelt es sich um Netzgruppennamen. In den Klammern werden diesen Netzgruppen jeweils ein oder mehrere Benutzerkonten hinzugefügt. Die drei Felder in der Klammer haben folgende Bedeutung:

  1. Der Name des Rechners, auf dem die folgenden Werte gültig sind. Wird kein Rechnername festgelegt, ist der Eintrag auf allen Rechnern gültig. Wenn ein Rechnername angegeben ist, muss auf viele Einzelheiten in dieser Konfiguration geachtet werden.

  2. Der Name des Benutzerkontos, der zu dieser Netzgruppe gehört.

  3. Die NIS-Domäne für das Benutzerkonto. Benutzerkonten können von anderen NIS-Domänen in eine Netzgruppe importiert werden.

Jedes Feld kann Wildcards enthalten. Die Einzelheiten entnehmen Sie bitte netgroup(5).

Anmerkung:

Netzgruppennamen sollten nicht länger als 8 Zeichen sein, insbesondere wenn Rechner mit verschiedenen Betriebssystemen in der NIS-Domäne betrieben werden. Es wird zwischen Groß- und Kleinschreibung unterschieden. Die Verwendung von Großbuchstaben für Netzgruppennamen ermöglicht eine leichte Unterscheidung zwischen Benutzern, Rechnern und Netzgruppen.

Einige NIS-Clients (dies gilt nicht für FreeBSD) können keine Netzgruppen mit einer großen Anzahl von Einträgen verwalten. Einige ältere Versionen von SunOS™ haben beispielsweise Probleme, wenn Netzgruppen mehr als fünfzehn Einträge enthalten. Diese Grenze kann umgangen werden, indem mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern anlegt und diese Subnetzgruppen wiederum in einer Netzgruppe zusammengefasst wird:

BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

Wiederholen Sie diesen Vorgang , wenn Sie mehr als 225 Benutzer in einer einzigen Netzgruppe benötigen.

Das Aktivieren und Verteilen der neuen NIS-Map ist einfach:

ellington# cd /var/yp
ellington# make

Dadurch werden die NIS-Maps netgroup, netgroup.byhost und netgroup.byuser erzeugt. Prüfen Sie die Verfügbarkeit der neuen NIS-Maps mit ypcat(1).

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

Die Ausgabe des ersten Befehls gibt den Inhalt von /var/yp/netgroup wieder. Der zweite Befehl erzeugt nur dann eine Ausgabe, wenn rechnerspezifische Netzgruppen erzeugt wurden. Der dritte Befehl gibt die Netzgruppen nach Benutzern sortiert aus.

Die Einrichtung der Clients ist einfach. Es muss lediglich auf dem Server war vipw(8) aufgerufen werden und die Zeile

+:::::::::

durch

+@IT_EMP:::::::::

ersetzt werden.

Ab sofort werden nur noch die Daten der in der Netzgruppe IT_EMP vorhandenen Benutzer in die Passwortdatenbank von war importiert. Nur diese Benutzer dürfen sich am Server anmelden.

Unglücklicherweise gilt diese Einschränkung auch für die ~-Funktion der Shell und für alle Routinen, die auf Benutzernamen und numerische Benutzer-IDs zugreifen. Oder anders formuliert, cd ~user ist nicht möglich, ls -l zeigt die numerische Benutzer-ID statt dem Benutzernamen und find . -user joe -print erzeugt die Fehlermeldung No such user. Um dieses Problem zu beheben, müssen alle Benutzereinträge importiert werden, ohne ihnen jedoch zu erlauben, sich am Server anzumelden.

Dazu fügen Sie eine weitere Zeile in /etc/master.passwd ein. Diese Zeile sollte ähnlich der folgenden aussehen:

+:::::::::/sbin/nologin, was in etwa Importiere alle Einträge, aber ersetze die Shell in den importierten Einträgen durch /sbin/nologin entspricht. Es ist möglich, jedes Feld der passwd-Einträge zu ersetzen, indem ein einen Standardwert in /etc/master.passwd eingetragen wird.

Warnung:

Stellen Sie sicher, dass die Zeile +:::::::::/sbin/nologin nach der Zeile +@IT_EMP::::::::: eingetragen ist. Sonst haben alle via NIS importierten Benutzerkonten /sbin/nologin als Loginshell.

Nach dieser Änderung muss die NIS-Map nur noch geändert werden, wenn ein neuer Mitarbeiter der IT-Abteilung beitritt. Ein ähnlicher Ansatz für weniger wichtige Server kann durch das Ersetzten des alten Eintrags +::::::::: in der lokalen Version von /etc/master.passwd mit etwas wie folgt verwendet werden:

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

Die entsprechenden Zeilen für normale Arbeitsplätze lauten:

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

Ab jetzt wäre alles wunderbar, allerdings ändert sich kurz darauf die Firmenpolitik: Die IT-Abteilung beginnt damit, Praktikanten zu beschäftigen. Praktikanten dürfen sich an normalen Arbeitsplätzen sowie an den weniger wichtigen Servern anmelden. Die IT-Praktikanten dürfen sich nun auch an den Hauptservern anmelden. Sie legen also die neue Netzgruppe IT_INTERN an, weisen Ihr die neuen IT-Praktikanten als Benutzer zu und beginnen damit, die Konfiguration auf jedem einzelnen Rechner zu ändern. Halt! Sie haben gerade die alte Regel Fehler in der zentralisierten Planung führen zu globaler Verwirrung. bestätigt.

Da NIS in der Lage ist, Netzgruppen aus anderen Netzgruppen zu bilden, lassen sich solche Situationen leicht vermeiden. Eine Möglichkeit ist die Erzeugung rollenbasierter Netzgruppen. Sie könnten eine Netzgruppe BIGSRV erzeugen, um den Zugang zu den wichtigsten Servern zu beschränken, eine weitere Gruppe SMALLSRV für die weniger wichtigen Server und eine dritte Netzgruppe USERBOX für die normalen Arbeitsplatzrechner. Jede dieser Netzgruppen enthält die Netzgruppen, die sich auf diesen Rechnern anmelden dürfen. Die Einträge der Netzgruppen in der NIS-Map sollten ähnlich den folgenden aussehen:

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

Diese Methode funktioniert besonders gut, wenn Rechner in Gruppen mit identischen Beschränkungen eingeteilt werden können. Unglücklicherweise ist dies die Ausnahme und nicht die Regel. Meistens wird die Möglichkeit zur rechnerspezischen Zugangsbeschränkung benötigt.

Rechnerspezifische Netzgruppen sind die zweite Möglichkeit, um mit den oben beschriebenen Änderungen umzugehen. In diesem Szenario enthält /etc/master.passwd auf jedem Rechner zwei mit + beginnende Zeilen. Die erste Zeile legt die Netzgruppe mit den Benutzern fest, die sich auf diesem Rechner anmelden dürfen. Die zweite Zeile weist allen anderen Benutzern /sbin/nologin als Shell zu. Verwenden Sie auch hier (analog zu den Netzgruppen) Großbuchstaben für die Rechnernamen. Die Zeilen sollten also ähnlich den folgenden aussehen:

+@BOXNAME:::::::::
+:::::::::/sbin/nologin

Sobald dies für alle Rechner erledigt ist, müssen die lokalen Versionen von /etc/master.passwd nie mehr verändert werden. Alle weiteren Änderungen geschehen über die NIS-Maps. Nachfolgend ein Beispiel für eine mögliche Netzgruppen-Map, die durch einige Besonderheiten erweitert wurde:

# Define groups of users first
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Now, define some groups based on roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR       BIGSRV
FAMINE    BIGSRV
# User india needs access to this server
POLLUTION  BIGSRV  (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH     IT_EMP
#
# The anti-virus-machine mentioned above
ONE       SECURITY
#
# Restrict a machine to a single user
TWO       (,hotel,test-domain)
# [...more groups to follow]
      

Wenn eine Datenbank verwendet wird, um Benutzerkonten zu verwalten, kann es möglich sein, den ersten Teil der NIS-Map mit den Datenbanktools zu erstellen. Auf diese Weise haben neue Benutzer automatisch Zugriff auf die Rechner.

Eine letzte Warnung: Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Dutzende oder gar Hunderte identische Rechner einrichtet werden müssen, sollten rollenbasierte Netzgruppen verwendet werden, um die Grösse der NISs-Maps in Grenzen zu halten.

30.4.8. Weitere wichtige Punkte

Nachdem die Rechner in der NIS-Umgebung eingerichtet sind, müssen Administratoren einige Dinge anders als bisher erledigen.

  • Jedes Mal, wenn ein neuer Benutzer angelegt wird, muss er am NIS-Masterserver hinzugefügt und die NIS-Maps anschließend neu erzeugt werden. Wird dieser Punkt vergessen, kann sich der neue Benutzer nur am NIS-Masterserver anmelden. Wenn wir also den neuen Benutzer jsmith anlegen, gehen wir folgerndermassen vor:

    # pw useradd jsmith
    # cd /var/yp
    # make test-domain

    Statt pw useradd jsmith kann auch adduser jsmith verwendet werden.

  • Tragen Sie die Administratorkonten nicht in die NIS-Maps ein. Dies ist unerwünscht und stellt ein Sicherheitsrisiko dar. Diese Benutzer und Passwörter sollten nicht auf alle Maschinen verteilt werden. Vor allem, wenn sich Benutzer anmelden können, die auf diese Konten keinen Zugriff haben sollen.

  • Sichern Sie die NIS-Master- und Slaveserver und minimieren Sie die Ausfallzeiten. Wenn diese Rechner gehackt oder einfach nur ausgeschaltet werden, haben viele Leute keinen Netzwerkzugriff mehr.

    Dies ist die größte Schwäche jeder zentralen Verwaltung. Wenn die NIS-Server nicht geschützt sind, wird es viele verärgerte Anwender und ein unzufriedenes Management geben.

30.4.9. Kompatibilität zu NIS v1

ypserv unterstützt NIS v1 unter FreeBSD nur eingeschränkt. Die NIS-Implementierung von FreeBSD verwendet nur NIS v2, andere Implementierungen unterstützen aus Gründen der Abwärtskompatibilität mit älteren Systemen auch NIS v1. Die mit diesen Systemen gelieferten ypbind-Daemonen versuchen, sich an einen NIS-v1-Server zu binden (Dies selbst dann, wenn sie ihn nie benötigen. Außerdem versuchen Sie auch dann, einen v1-Server zu erreichen, wenn Sie zuvor eine Antwort von einem v2-Server erhalten.). Während normale Clientaufrufe unter FreeBSD unterstützt werden, sind Anforderungen zum Transfer von v1-Maps nicht möglich. Zudem kann FreeBSD nicht als Client oder Server verwendet werden, wenn ein NIS-Server vorhanden ist, der nur NIS v1 unterstützt. Glücklicherweise sollte es heute keine Server mehr geben, die nur NIS v1 unterstützen.

30.4.10. NIS-Server, die auch als NIS-Clients arbeiten

Wenn Sie ypserv in einer Multi-Serverdomäne verwenden, in der NIS-Server gleichzeitig als NIS-Clients arbeiten, ist es eine gute Idee, diese Server zu zwingen, sich an sich selbst zu binden. Damit wird verhindert, dass Bindeanforderungen gesendet werden und sich die Server gegenseitig binden. Sonst könnten seltsame Fehler auftreten, wenn ein Server ausfällt, auf den andere Server angewiesen sind. Letztlich werden alle Clients einen Timeout melden, und versuchen, sich an andere Server zu binden. Die dadurch entstehende Verzögerung kann beträchtlich sein. Außerdem kann der Fehler erneut auftreten, da sich die Server wiederum aneinander binden könnten.

Ein Rechner kann durch die Verwendung von ypbind sowie der Option -S gezwungen werden, sich an einen bestimmten Server zu binden. Um diesen Vorgang zu automatisieren, können folgende Zeilen in /etc/rc.conf eingefügt werden:

nis_client_enable="YES"	# run client stuff as well
nis_client_flags="-S NIS domain,server"

Lesen Sie ypbind(8), wenn Sie weitere Informationen benötigen.

30.4.11. Passwortformate

Unterschiedliche Passwortformate sind das Hauptproblem, das beim Einrichten eines NIS-Servers auftreten kann. Wenn der NIS-Server mit DES verschlüsselte Passwörter verwendet, werden nur Clients unterstützt, die ebenfalls DES benutzen. Wenn sich im Netzwerk beispielsweise Solaris™ NIS-Clients befinden, müssen die Passwörter sehr wahrscheinlich mit DES verschlüsselt werden.

Welches Format die Server und Clients verwenden, steht in /etc/login.conf. Wenn ein System Passwörter mit DES verschlüsselt, enthält die default-Klasse einen Eintrag wie den folgenden:

default:\
	:passwd_format=des:\
	:copyright=/etc/COPYRIGHT:\
	[weitere Einträge]

Mögliche Werte für passwd_format sind unter anderem blf und md5 (mit Blowfish und MD5 verschlüsselte Passwörter).

Wenn die Datei /etc/login.conf geändert wird, muss die Login-Capability Datenbank neu erstellt werden. Geben Sie dazu als root den folgenden Befehl ein:

# cap_mkdb /etc/login.conf

Anmerkung:

Das Format der schon in /etc/master.passwd befindlichen Passwörter wird erst aktualisiert, wenn ein Benutzer sein Passwort ändert, nachdem die Datenbank neu erstellt wurde.

Damit die Passwörter auch im gewählten Format abgespeichert werden, muss mit crypt_default in der Datei /etc/auth.conf die richtige Priorität der Formate eingestellt werden. Das gewählte Format sollte als Erstes in der Liste stehen. Sollen die Passwörter mit DES verschlüsselt werden, verwenden Sie den folgenden Eintrag:

crypt_default	=	des blf md5

Wenn alle FreeBSD NIS-Server und NIS-Clients entsprechend den obigen Schritten eingestellt sind, wird im ganzen Netzwerk dasselbe Passwortformat verwendet. Falls Benutzer Probleme mit der Authentifizierung eines NIS-Clients haben, kontrollieren Sie die verwendeten Passwortformate. In einer heterogenen Umgebung wird wahrscheinlich DES benutzt werden müssen, da dies der meist unterstützte Standard ist.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.