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.
Es gibt verschiedene Begriffe und Anwenderprozesse, auf die Sie stoßen werden, wenn Sie NIS unter FreeBSD einrichten, egal ob Sie einen Server oder einen Client konfigurieren:
Begriff | Beschreibung |
---|---|
NIS-Domänenname | Ein 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. |
rpcbind | Muss laufen, damit RPC (Remote Procedure Call, ein von NIS verwendetes Netzwerkprotokoll) funktioniert. NIS-Server sowie Clients funktionieren ohne rpcbind nicht. |
ypbind | „Bindet“ 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. |
ypserv | Sollte 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.yppasswdd | Ein 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. |
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.
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.
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.
Dieser Abschnitt beschreibt an Hand eines Beispiels die Einrichtung einer NIS-Umgebung.
Nehmen wir an, Sie seien der Administrator eines kleinen
Universitätsnetzes. 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; legen Sie einen neuen Benutzer an,
so muss dies auf allen fünfzehn Rechnern manuell
erledigt werden (unter Verwendung von
adduser
). Da diese Lösung sehr
ineffizient ist, soll das Netzwerk in Zukunft NIS verwenden,
wobei zwei der Rechner als Server dienen sollen.
In Zukunft soll das Netz also wie folgt aussehen:
Rechnername | IP-Adresse | Rechneraufgabe |
---|---|---|
ellington | 10.0.0.2 | NIS-Master |
coltrane | 10.0.0.3 | NIS-Slave |
basie | 10.0.0.4 | Workstation der Fakultät |
bird | 10.0.0.5 | Clientrechner |
cli[1-11] | 10.0.0.[6-17] | Verschiedene andere Clients |
Wenn Sie NIS das erste Mal einrichten, ist es ratsam, sich zuerst über die Vorgangsweise Gedanken zu machen. Unabhängig von der Größe Ihres Netzwerks müssen Sie stets einige Entscheidungen treffen.
Dies muss nicht der „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 Ihres 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 unser Beispiel verwenden
wir den NIS-Domänennamen
test-domain
.
Es gibt jedoch auch Betriebssysteme (vor allem SunOS™), die als NIS-Domänennamen den Name der Internetdomäne verwenden. Wenn dies für einen oder mehrere Rechner Ihres Netzwerks zutrifft, müssen Sie den Namen der Internetdomäne als Ihren NIS-Domänennamen verwenden.
Wenn Sie einen NIS-Server einrichten wollen, müssen Sie einige Dinge beachten. 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 Sie ein Netzwerk haben, das nicht zu stark ausgelastet ist, ist es auch möglich, den NIS-Server als weiteren Dienst auf einem anderen Rechner laufen zu lassen. Denken Sie aber daran, dass ein Ausfall des NIS-Servers alle NIS-Clients betrifft.
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.
Abhängig von Ihren Anforderungen ist die
Einrichtung eines NIS-Masterservers relativ einfach, da
NIS von FreeBSD bereits in der Standardkonfiguration
unterstützt wird. Sie müssen nur folgende
Zeilen in /etc/rc.conf
einfügen:
Diese Zeile setzt den NIS-Domänennamen auf
test-domain
, wenn Sie das Netzwerk
initialisieren (beispielsweise nach einem Systemstart).
Dadurch werden die NIS-Serverprozesse gestartet.
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.
In Abhängigkeit von Ihrer NIS-Konfiguration können weitere Einträge erforderlich sein. Weitere Informationen finden Sie im Abschnitt NIS-Server, die auch als NIS-Clients arbeiten.
Nachdem Sie obige Parameter konfiguriert haben, müssen
Sie nur noch /etc/netstart
als Superuser
ausführen, um alles entsprechend Ihren Vorgaben in der
Datei /etc/rc.conf
einzurichten.
Bevor Sie die NIS-Maps einrichten können, müssen Sie
nun noch den ypserv-Daemon
manuell starten:
#
/etc/rc.d/ypserv start
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 Sie die Passwörter für Ihr
root
- oder andere
Administratorkonten nicht an alle Server der NIS-Domäne
verteilen wollen. Bevor Sie also die NIS-Maps des
Masterservers einrichten, sollten Sie Folgendes tun:
#
cp /etc/master.passwd /var/yp/master.passwd
#
cd /var/yp
#
vi master.passwd
Entfernen Sie alle Systemkonten
(wie bin
, tty
,
kmem
oder games
),
sowie alle Konten, die Sie nicht an die NIS-Clients
weitergeben wollen (beispielsweise root
und alle Konten mit der UID 0 (=Superuser).
Stellen Sie sicher, dass
/var/yp/master.passwd
weder von der
Gruppe noch von der Welt gelesen werden kann (Zugriffsmodus
600)! Ist dies nicht der Fall, ändern Sie dies mit
chmod
.
Nun können Sie die NIS-Maps initialisieren.
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:
#
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 Sie in einer
NIS-Umgebung mit nur einem Server arbeiten und dass alle
Clients unter FreeBSD laufen. Da
test-domain
aber auch über einen
Slaveserver verfügt, müssen Sie
/var/yp/Makefile
entsprechend anpassen:
#
vi /var/yp/Makefile
Sie sollten die Zeile
auskommentieren (falls dies nicht bereits der Fall ist).
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:
#
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.Sie sollten nun über das Verzeichnis
/var/yp/test-domain
verfügen.
Die Kopien der NIS-Masterserver-Maps sollten sich in diesem
Verzeichnis befinden. Allerdings müssen Sie diese
auch aktuell halten. Die folgenden Einträge in
/etc/crontab
erledigen diese Aufgabe:
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.
Ein NIS-Client bindet
sich unter
Verwendung des ypbind
-Daemons an einen
NIS-Server. ypbind
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.
Einen FreeBSD-Rechner als NIS-Client einzurichten, ist recht einfach.
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:
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:
Diese Zeile legt für alle gültigen
Benutzerkonten der NIS-Server-Maps einen Zugang an.
Es gibt verschiedene Wege, Ihren 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.
Sie sollten zumindest ein lokales Benutzerkonto,
das nicht über NIS importiert wird, in Ihrer
/etc/master.passwd
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.
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
#
/etc/rc.d/ypbind start
Nachdem Sie diese Schritte erledigt haben, sollten Sie
mit ypcat passwd
die
passwd-Map
des NIS-Servers anzeigen
können.
Im Allgemeinen kann jeder entfernte Anwender einen RPC an
ypserv(8) schicken, um den Inhalt Ihrer NIS-Maps abzurufen,
falls er Ihren 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 der Datei
/var/yp/securenets
zu laden.
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:
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.
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 Ihrer 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 Ihres 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 Ihrer Clientsysteme dieses Problem aufweisen, sollten Sie die betreffenden Clients in NIS-Slaveserver umwandeln, und diese an sich selbst binden.
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 müssen
Sie lediglich an diesem Rechner den Eintrag
-
an
das Ende von Benutzername
/etc/master.passwd
setzen,
wobei Benutzername
der zu
blockierende Benutzername ist. Diese Änderung sollte
bevorzugt durch vipw
erledigt werden, da
vipw
Ihre Ä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, gehen wir wie folgt vor:
#
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#
Die im letzten Abschnitt beschriebene Methode eignet sich besonders, wenn Sie spezielle Regeln für wenige Benutzer oder wenige Rechner benötigen. In großen Netzwerken werden Sie 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, wenn Sie von dieser Situation betroffen sind. 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 Ihre erfolgreiche Einführung von NIS die Aufmerksamkeit Ihrer Vorgesetzten geweckt hat. Ihre nächste Aufgabe besteht nun darin, Ihre 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 ,
beta | Beschäftigte der IT-Abteilung |
charlie ,
delta | Die neuen Lehrlinge der IT-Abteilung |
echo ,
foxtrott ,
golf , ... | Normale Mitarbeiter |
able ,
baker , ... | Externe Mitarbeiter |
Rechnername(n) | Beschreibung |
---|---|
war , death ,
famine , pollution | Ihre wichtigsten Server. Nur IT-Fachleute dürfen sich an diesen Rechnern anmelden. |
pride , greed ,
envy , wrath ,
lust , sloth | Weniger 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. |
trashcan | Ein sehr alter Rechner ohne kritische Daten. Sogar externe Mitarbeiter dürfen diesen Rechner verwenden. |
Wollten Sie diese Einschränkungen umsetzen, indem Sie
jeden Benutzer einzeln blockieren, müssten Sie auf jedem
System für jeden Benutzer eine entsprechende Zeile in
passwd
einfügen. Wenn Sie nur einen
Eintrag vergessen, haben Sie ein Problem. Es mag noch angehen,
dies während der ersten Installation zu erledigen, im
täglichen Betrieb werden Sie allerdings
mit Sicherheit einmal vergessen, die
entsprechenden Einträge anzulegen. Vergessen Sie nicht:
Murphy war Optimist.
Die Verwendung von Netzgruppen hat in dieser Situation mehrere Vorteile. Sie müssen nicht jeden Benutzer einzeln verwalten; weisen Sie stattdessen den Benutzer einer Netzgruppe zu und erlauben oder verbieten Sie allen Mitglieder dieser Gruppe die Anmeldung an einem Server. Wenn Sie einen neuen Rechner hinzufügen, müssen Sie Zugangsbeschränkungen nur für die Netzgruppen festlegen. Legen Sie einen neuen Benutzer an, müssen Sie ihn nur einer oder mehrere Netzgruppen zuweisen. 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 Sie die Einrichtung von NIS sorgfältig geplant haben, müssen Sie nur noch eine zentrale Konfigurationsdatei bearbeiten, 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:
#
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 Externe.
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:
Der Name des Rechners, auf dem die folgenden Werte gültig sind. Legen Sie keinen Rechnernamen fest, ist der Eintrag auf allen Rechnern gültig. Dadurch gehen Sie vielen Problemen aus dem Weg.
Der Name des Benutzerkontos, der zu dieser Netzgruppe gehört.
Die NIS-Domäne für das Benutzerkonto. Sie können Benutzerkonten von anderen NIS-Domänen in Ihre Netzgruppe importieren, wenn Sie mehrere NIS-Domänen verwalten.
Jedes Feld kann Wildcards enthalten. Die Einzelheiten entnehmen Sie bitte netgroup(5).
Netzgruppennamen sollten nicht länger als 8 Zeichen sein, vor allem dann, wenn Sie Rechner mit verschiedenen Betriebssystemen in Ihrer NIS-Domäne haben. 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. Sie können dieses Problem umgehen, indem Sie mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern anlegen und diese Subnetzgruppen wiederum in einer Netzgruppe zusammenfassen:
Sie können diesen Vorgang wiederholen, wenn Sie mehr als 255 Benutzer in einer einzigen Netzgruppe benötigen.
Das Aktivieren und Verteilen Ihre neuen NIS-Map ist einfach:
#
cd /var/yp
ellington#
make
Dadurch werden die NIS-Maps netgroup
,
netgroup.byhost
und
netgroup.byuser
erzeugt. Prüfen Sie
die Verfügbarkeit Ihrer neuen NIS-Maps mit ypcat(1).
%
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 Sie rechnerspezifische
Netzgruppen erzeugt haben. Der dritte Befehl gibt die
Netzgruppen nach Benutzern sortiert aus.
Die Einrichtung der Clients ist einfach. Sie müssen
lediglich auf dem Server war
vipw(8) aufrufen und die Zeile
durch
ersetzen.
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 ~
ist nicht
möglich, user
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 Sie alle Benutzereinträge
importieren, ohne ihnen jedoch zu erlauben, sich an
Ihrem 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. Sie
können jedes Feld dieses Eintrages ersetzen, indem Sie
einen Standardwert in /etc/master.passwd
eintragen.
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.
Danach müssen Sie nur mehr eine einzige NIS-Map
ändern, wenn ein neuer Mitarbeiter berücksichtigt
werden muss. Für weniger wichtige Server gehen Sie analog
vor, indem Sie den alten Eintrag +:::::::::
in den lokalen Versionen von
/etc/master.passwd
durch folgende
Einträge ersetzen:
Die entsprechenden Zeilen für normale Arbeitsplätze lauten:
Ab jetzt wäre alles wunderbar, allerdings ändert
sich kurz darauf die Firmenpolitik: Die IT-Abteilung beginnt
damit, externe Mitarbeiter zu beschäftigen. Externe
dürfen sich an normalen Arbeitsplätzen sowie an den
weniger wichtigen Servern anmelden. Die IT-Lehrlinge
dürfen sich nun auch an den Hauptservern anmelden. Sie
legen also die neue Netzgruppe IT_INTERN
an,
weisen Ihr die neuen IT-Externen 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:
Diese Methode funktioniert besonders gut, wenn Sie Rechner in Gruppen mit identischen Beschränkungen einteilen können. Unglücklicherweise ist dies die Ausnahme und nicht die Regel. Meistens werden Sie die Möglichkeit zur rechnerspezischen Zugangsbeschränkung benötigen.
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/nologinWenn Sie dies für alle Rechner erledigt haben, werden
Sie die lokalen Versionen von
/etc/master.passwd
nie mehr verändern
müssen. Alle weiteren Änderungen geschehen über
die NIS-Maps. Nachfolgend ein Beispiel für eine
mögliche Netzgruppen-Map, die durch einige Besonderheiten
erweitert wurde:
Wenn Sie eine Datenbank verwenden, um Ihre Benutzerkonten zu verwalten, sollten Sie den ersten Teil der NIS-Map mit Ihren Datenbanktools erstellen können. Auf diese Weise haben neue Benutzer automatisch Zugriff auf die Rechner.
Eine letzte Warnung: Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Sie Dutzende oder gar Hunderte identische Rechner einrichten müssen, sollten Sie rollenbasierte Netzgruppen verwenden, um die Grösse der NISs-Maps in Grenzen zu halten.
Nachdem Sie Ihre NIS-Umgebung eingerichtet haben, müssen Sie einige Dinge anders als bisher erledigen.
Jedes Mal, wenn Sie einen neuen Benutzer anlegen wollen,
tun Sie dies ausschließlich am
NIS-Masterserver. Außerdem
müssen Sie anschließend die
NIS-Maps neu erzeugen. Wenn Sie diesen Punkt vergessen,
kann sich der neue Benutzer nur am
NIS-Masterserver anmelden. Wenn Sie also den neuen Benutzer
jsmith
anlegen, gehen Sie
folgerndermassen vor:
#
pw useradd jsmith
#
cd /var/yp
#
make test-domain
Statt pw useradd jsmith
könnten
Sie auch adduser jsmith
verwenden.
Tragen Sie die Administratorkonten nicht in die NIS-Maps ein. Administratorkonten und Passwörter dürfen nicht auf Rechnern verbreitet werden, auf denen sich Benutzer anmelden können, die auf diese Konten keine 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 Sie Ihre NIS-Server nicht schützen, werden Sie viele verärgerte Anwender haben.
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. Daher 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.
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.
Sie können einen Rechner durch die Verwendung von
ypbind
sowie der Option -S
zwingen, sich an einen bestimmten Server zu binden. Um diesen
Vorgang zu automatisieren, können Sie folgende Zeilen in
/etc/rc.conf
einfügen:
NIS domain
,server
"Lesen Sie ypbind(8), wenn Sie weitere Informationen benötigen.
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 auf Ihrem Netzwerk beispielsweise Solaris™ NIS-Clients befinden, müssen die Passwörter 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:
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
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:
Wenn Sie alle FreeBSD NIS-Server und NIS-Clients entsprechend den obigen Schritten eingestellt haben, wird im ganzen Netzwerk dasselbe Passwortformat verwendet. Falls Sie Probleme mit der Authentifizierung eines NIS-Clients haben, kontrollieren Sie die verwendeten Passwortformate. In einer heterogenen Umgebung werden Sie DES benutzen 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>.