NIS, dat staat voor Netwerkinformatiediensten (Network Information Services), is ontwikkeld door Sun Microsystems om het beheer van UNIX® (origineel SunOS™) systemen te centraliseren. Tegenwoordig is het eigenlijk een industriestandaard geworden. Alle grote UNIX® achtige systemen (Solaris™, HP-UX, AIX®, Linux®, NetBSD, OpenBSD, FreeBSD, enzovoort) ondersteunen NIS.
NIS stond vroeger bekend als Yellow Pages, maar vanwege problemen met het handelsmerk heeft Sun de naam veranderd. De oude term, en yp, wordt nog steeds vaak gebruikt.
Het is een op RPC-gebaseerd cliënt/serversysteem waarmee een groep machines binnen een NIS-domein een gezamenlijke verzameling met instellingenbestanden kan delen. Hierdoor kan een beheerder NIS-systemen opzetten met een minimaal aantal instellingen en vanaf een centrale lokatie instellingen toevoegen, verwijderen en wijzigen.
Het is te vergelijken met het Windows NT® domeinsysteem en hoewel de interne implementatie van de twee helemaal niet overeenkomt, is de basisfunctionaliteit vergelijkbaar.
Er zijn een aantal termen en belangrijke gebruikersprocessen die een rol spelen bij het implementeren van NIS op FreeBSD, zowel bij het maken van een NIS-server als bij het maken van een systeem dan NIS-cliënt is:
Term | Beschrijving |
---|---|
NIS-domeinnaam | Een NIS-masterserver en al zijn cliënten (inclusief zijn slave master) hebben een NIS-domeinnaam. Vergelijkbaar met een Windows NT® domeinnaam, maar de NIS-domeinnaam heeft niets te maken met DNS. |
rpcbind | Moet draaien om RPC (Remote Procedure Call in te schakelen, een netwerkprotocol dat door NIS gebruikt wordt). Als rpcbind niet draait, dan kan er geen NIS-server draaien en kan een machine ook geen NIS-cliënt zijn. |
ypbind | “Verbindt” een NIS-cliënt aan zijn NIS-server. Dat gebeurt door met de NIS-domeinnaam van het systeem en door het gebruik van RPC te verbinden met de server. ypbind is de kern van cliënt-server communicatie in een NIS-omgeving. Als ypbind op een machine stopt, dan kan die niet meer bij de NIS-server komen. |
ypserv | Hoort alleen te draaien op NIS-servers. Dit is het NIS-serverproces zelf. Als ypserv(8) stopt, dan kan de server niet langer reageren op NIS-verzoeken (hopelijk is er dan een slaveserver om het over te nemen). Er zijn een aantal implementaties van NIS, maar niet die op FreeBSD, die geen verbinding met een andere server proberen te maken als de server waarmee ze verbonden waren niet meer reageert. In dat geval is vaak het enige dat werkt het serverproces herstarten (of zelfs de hele server) of het ypbind-proces op de cliënt. |
rpc.yppasswdd | Nog een proces dat alleen op NIS-masterservers hoort te draaien. Dit is een daemon waarbij NIS-cliënten hun NIS-wachtwoorden kunnen wijzigen. Als deze daemon niet draait, moeten gebruikers zich aanmelden op de NIS-masterserver en daar hun wachtwoord wijzigen. |
Er zijn drie typen hosts in een NIS-omgeving: master servers, slaveservers en cliënten. Servers zijn het centrale depot voor instellingen voor een host. Masterservers bevatten de geautoriseerd kopie van die informatie, terwijl slaveservers die informatie spiegelen voor redundantie. Cliënten verlaten zich op de servers om hun die informatie ter beschikking te stellen.
Op deze manier kan informatie uit veel bestanden gedeeld
worden. De bestanden master.passwd
,
group
en hosts
worden meestal via NIS gedeeld. Als een proces op een
cliënt informatie nodig heeft die normaliter in een van die
lokale bestanden staat, dan vraagt die het in plaats daarvan aan
de NIS-servers waarmee hij verbonden is.
Een NIS-masterserver. Deze
server onderhoudt, analoog aan een Windows NT® primaire
domeincontroller, de bestanden die door alle
NIS-cliënten gebruikt worden. De bestanden
passwd
, group
en
andere bestanden die door de NIS-cliënten gebruikt
worden staan op de masterserver.
Het is mogelijk om één machine master server te laten zijn voor meerdere NIS-domeinen. Dat wordt in deze inleiding echter niet beschreven, omdat die uitgaat van een relatief kleine omgeving.
NIS-slaveservers. Deze zijn te vergelijken met Windows NT® backup domain controllers. NIS-slaveservers beheren een kopie van de bestanden met gegevens op de NIS-master. NIS-slaveservers bieden redundantie, die nodig is in belangrijke omgevingen. Ze helpen ook om de belasting te verdelen met de master server: NIS-cliënten maken altijd een verbinding met de NIS-server die het eerst reageert en dat geldt ook voor antwoorden van slaveservers.
NIS-cliënten. NIS-cliënten authenticeren, net als de meeste Windows NT® werkstations, tegen de NIS-server (of de Windows NT® domain controller in het geval van Windows NT® werkstations) bij het aanmelden.
Dit onderdeel behandelt het opzetten van een NIS-voorbeeldomgeving.
Er wordt uitgegaan van een beheerder van een klein
universiteitslab. Dat lab, dat bestaat uit FreeBSD machines,
kent op dit moment geen centraal beheer. Iedere machine heeft
zijn eigen /etc/passwd
en
/etc/master.passwd
. Die bestanden worden
alleen met elkaar in lijn gehouden door handmatige
handelingen. Als er op dit moment een gebruiker aan het lab
wordt toegevoegd, moet adduser
op alle 15
machines gedraaid worden. Dat moet natuurlijk veranderen en
daarom is besloten het lab in te richten met NIS, waarbij twee
machines als server worden gebruikt.
Het lab ziet er ongeveer als volgt uit:
Machinenaam | IP-adres | Rol Machine |
---|---|---|
ellington | 10.0.0.2 | NIS-master |
coltrane | 10.0.0.3 | NIS-slave |
basie | 10.0.0.4 | Wetenschappelijk werkstation |
bird | 10.0.0.5 | Cliënt machine |
cli[1-11] | 10.0.0.[6-17] | Andere cliënt machines |
Bij het voor de eerste keer instellen van een NIS-schema is het verstandig eerst na te denken over hoe dat opgezet moet worden. Hoe groot een netwerk ook is, er moeten een aantal beslissingen gemaakt worden.
Dit is wellicht niet de bekende “domeinnaam”. Daarom wordt het ook de “NIS-domeinnaam” genoemd. Bij de broadcast van een cliënt om informatie wordt ook de naam van het NIS-domein waar hij onderdeel van uitmaakt meegezonden. Zo kunnen meerdere servers op een netwerk bepalen of er antwoord gegeven dient te worden op een verzoek. De NIS-domeinnaam kan voorgesteld worden als de naam van een groep hosts die op een of andere manier aan elkaar gerelateerd zijn.
Sommige organisaties kiezen hun Internet-domeinnaam als
NIS-domeinnaam. Dat wordt niet aangeraden omdat het voor
verwarring kan zorgen bij het debuggen van netwerkproblemen.
De NIS-domeinnaam moet uniek zijn binnen een netwerk en het
is handig als die de groep machines beschrijft waarvoor hij
geldt. Zo kan bijvoorbeeld de financiële afdeling van
Acme Inc. als NIS-domeinnaam “acme-fin” hebben.
In dit voorbeeld wordt de naam
test-domain
gekozen.
Sommige besturingssystemen gebruiken echter (met name SunOS™) hun NIS-domeinnaam als hun Internet-domeinnaam. Als er machines zijn op een netwerk die deze restrictie kennen, dan moet de Internet-domeinnaam als de naam voor het NIS-domeinnaam gekozen worden.
Bij het kiezen van een machine die als NIS-server wordt gebruikt zijn er een aantal aandachtspunten. Een van de onhandige dingen aan NIS is de afhankelijkheid van de cliënten van de server. Als een cliënt de server voor zijn NIS-domein niet kan bereiken, dan wordt die machine vaak onbruikbaar. Door het gebrek aan gebruiker- en groepsinformatie bevriezen de meeste systemen. Daarom moet er een machine gekozen worden die niet vaak herstart hoeft te worden of wordt gebruikt voor ontwikkeling. De NIS-server is in het meest ideale geval een alleenstaande server die als enige doel heeft NIS-server te zijn. Als een netwerk niet zwaar wordt gebruikt, kan de NIS-server op een machine die ook andere diensten aanbiedt gezet worden, maar het blijft belangrijk om ervan bewust te zijn dat als de NIS-server niet beschikbaar is, dat nadelige invloed heeft op alle NIS-cliënten.
De hoofdversies van alle NIS-informatie staan opgeslagen
op één machine die de NIS-masterserver heet. De
databases waarin de informatie wordt opgeslagen heten
NIS-afbeeldingen. In FreeBSD worden die afbeeldingen opgeslagen
in /var/yp/[domeinnaam]
waar
[domeinnaam]
de naam is van het
NIS-domein dat wordt bediend. Een enkele NIS-server kan
tegelijkertijd meerdere NIS-domeinen ondersteunen en het is
dus mogelijk dat er meerdere van zulke mappen zijn, een voor
ieder ondersteund domein. Ieder domein heeft zijn eigen
onafhankelijke verzameling afbeeldingen.
In NIS-master- en -slaveservers worden alle NIS-verzoeken
door de daemon ypserv
afgehandeld.
ypserv
is verantwoordelijk voor het
ontvangen van inkomende verzoeken van NIS-cliënten, het
vertalen van de gevraagde domeinnaam en mapnaam naar een pad
naar het corresponderende databasebestand en het terugsturen
van de database naar de cliënten.
Het opzetten van een master NIS-server kan erg
eenvoudig zijn, afhankelijk van de behoeften. FreeBSD heeft
ondersteuning voor NIS als basisfunctie. Alleen de volgende
regels hoeven aan /etc/rc.conf
toegevoegd te worden en FreeBSD doet de rest:
nisdomainname="test-domain"
Deze regel stelt de NIS-domeinnaam in op
test-domain
bij het instellen van het
netwerk (bij het opstarten).
nis_server_enable="YES"
Dit geeft FreeBSD aan de NIS-serverprocessen te starten als het netwerk de volgende keer wordt opgestart.
nis_yppasswdd_enable="YES"
Dit schakelt de daemon rpc.yppasswdd
in die, zoals al eerder aangegeven, cliënten
toestaat om hun NIS-wachtwoord vanaf een
cliënt-machine te wijzigen.
Afhankelijk van de inrichting van NIS, kunnen er nog meer instellingen nodig zijn. In het onderdeel NIS-servers die ook NIS-cliënten zijn staan meer details.
Draai na het instellen van bovenstaande regels het commando
/etc/netstart
als supergebruiker. Het zal alles
voor u instellen, gebruikmakende van de waarden die u in
/etc/rc.conf
heeft ingesteld. Start als
laatste stap, voor het initialiseren van de NIS-afbeeldingen, de
daemon ypserv handmatig:
#
service ypserv start
Die NIS-afbeeldingen zijn
databasebestanden die in de map /var/yp
staan. Ze worden gemaakt uit de bestanden met instellingen
uit de map /etc
van de NIS-master, met
één uitzondering:
/etc/master.passwd
. Daar is een goede
reden voor, want het is niet wenselijk om de wachtwoorden
voor root
en andere administratieve
accounts naar alle servers in het NIS-domein te sturen.
Daar moet voor het initialiseren van de NIS-afbeeldingen het
volgende uitgevoerd worden:
#
cp /etc/master.passwd /var/yp/master.passwd
#
cd /var/yp
#
vi master.passwd
Dan horen alle systeemaccounts verwijderd te worden
(bin
, tty
,
kmem
, games
,
enzovoort) en alle overige accounts waarvoor het niet
wenselijk is dat ze op de NIS-cliënten terecht komen
(bijvoorbeeld root
en alle andere UID 0
(supergebruiker) accounts).
/var/yp/master.passwd
hoort niet
te lezen te zijn voor een groep of voor de wereld (dus
modus 600)! Voor het aanpassen van de rechten kan
chmod
gebruikt worden.
Als dat is gedaan, kunnen de NIS-afbeeldingen
geïnitialiseerd worden. Bij FreeBSD zit een script
ypinit
waarmee dit kan (in de hulppagina
staat meer informatie). Dit script is beschikbaar op de
meeste UNIX® besturingssystemen, maar niet op allemaal.
Op Digital UNIX/Compaq Tru64 UNIX heet het
ypsetup
. Omdat er afbeeldingen voor een
NIS-master worden gemaakt, wordt de optie
–m
meegegeven aan
ypinit
. Aangenomen dat de voorgaande
stappen zijn uitgevoerd, kunnen de NIS-afbeeldingen gemaakt
worden op de volgende manier:
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
[..uitvoer van het maken van de afbeeldingen..] NIS Map update completed. ellington has been setup as an YP master server without any errors.
ypinit
hoort
/var/yp/Makefile
gemaakt te hebben uit
/var/yp/Makefile.dist
. Als dit bestand is
gemaakt, neemt dat bestand aan dat er in een omgeving met
een enkele NIS-server wordt gewerkt met alleen
FreeBSD-machines. Omdat test-domain
ook een
slaveserver bevat, dient
/var/yp/Makefile
gewijzigd te
worden:
ellington#
vi /var/yp/Makefile
Als de onderstaande regel niet al uitgecommentarieerd is, dient dat alsnog te gebeuren:
NOPUSH = "True"
Het opzetten van een NIS-slaveserver is nog makkelijker
dan het opzetten van de master. Dit kan door aan te melden
op de slaveserver en net als voor de masterserver
/etc/rc.conf
te wijzigen. Het enige
verschil is dat nu de optie –s
gebruikt wordt voor het draaien van
ypinit
. Met de optie
–s
moet ook de naam van de NIS-master
meegegeven worden. Het commando ziet er dus als volgt uit:
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.
Nu hoort er een map
/var/yp/test-domain
te zijn waarin
kopieë van de NIS-masterserver afbeeldingen staan. Die
moeten bijgewerkt blijven. De volgende regel in
/etc/crontab
op de slaveservers regelt
dat:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
Met de bovenstaande twee regels wordt de slave gedwongen zijn afbeeldingen met de afbeeldingen op de masterserver te synchroniseren. Dit is niet verplicht omdat de masterserver automatisch probeert veranderingen aan de NIS-afbeeldingen door te geven aan zijn slaves. Echter, vanwege het belang van correcte wachtwoordinformatie op andere cliënten die van de slaveserver afhankelijk zijn, is het aanbevolen om specifiek de wachtwoordafbeeldingen vaak tot bijwerken te dwingen. Dit is des te belangrijker op drukke netwerken, omdat daar het bijwerken van afbeeldingen niet altijd compleet afgehandeld hoeft te worden.
Nu kan ook op de slaveserver het commando
/etc/netstart
uitgevoerd worden, dat op
zijn beurt de NIS-server start.
Een NIS-cliënt maakt wat heet een verbinding
(binding) met een NIS-server met de daemon
ypbind
. ypbind
controleert het standaarddomein van het systeem (zoals
ingesteld met domainname
) en begint met het
broadcasten van RPC-verzoeken op het lokale netwerk. Die
verzoeken bevatten de naam van het domein waarvoor
ypbind
een binding probeert te maken. Als
een server die is ingesteld om het gevraagde domein te
bedienen een broadcast ontvangt, dan antwoordt die aan
ypbind
dat dan het IP-adres van de server
opslaat. Als er meerdere servers beschikbaar zijn, een master
en bijvoorbeeld meerdere slaves, dan gebruikt
ypbind
het adres van de eerste server die
antwoord geeft. Vanaf dat moment stuurt de cliënt alle
NIS-verzoeken naar die server. ypbind
“pingt” de server zo nu en dan om te controleren
of die nog draait. Als er na een bepaalde tijd geen antwoord
komt op een ping, dan markeert ypbind
het
domein als niet verbonden en begint het broadcasten opnieuw,
in de hoop dat er een andere server wordt gelocaliseerd.
Het opzetten van een FreeBSD machine als NIS-cliënt is redelijk doorzichtig:
Wijzig /etc/rc.conf
en voeg de
volgende regels toe om de NIS-domeinnaam in te stellen
en ypbind
mee te laten starten bij
het starten van het netwerk:
nisdomainname="test-domain" nis_client_enable="YES"
Om alle mogelijke regels voor accounts uit de
NIS-server te halen, dienen alle gebruikersaccounts uit
/etc/master.passwd
verwijderd te
worden en dient met vipw
de volgende
regel aan het einde van het bestand geplaatst te
worden:
+:::::::::
Door deze regel wordt alle geldige accounts
in de wachtwoordafbeelding van de NIS-server toegang
gegeven. Er zijn veel manieren om de NIS-cliënt
in te stellen door deze regel te veranderen. In het
onderdeel netgroepen
hieronder staat meer informatie. Zeer gedetailleerde
informatie staat in het boek NFS en NIS
beheren
van O'Reilly.
Er moet tenminste één lokale account
behouden blijven (dus niet geïmporteerd via NIS)
in /etc/master.passwd
en die
hoort ook lid te zijn van de groep
wheel
. Als er iets mis is met
NIS, dan kan die account gebruikt worden om via het
netwerk aan te melden, root
te
worden en het systeem te repareren.
Om alle groepen van de NIS-server te importeren, kan
de volgende regel aan /etc/group
toegevoegd worden:
+:*::
Voer, om de NIS-cliënt onmiddelijk te starten, de volgende commando's als supergebruiker uit:
#
/etc/netstart
#
service ypbind start
Na het afronden van deze stappen zou met ypcat
passwd
de passwd map van de NIS-server te zien
moeten zijn.
In het algemeen kan iedere netwerkgebruiker een RPC-verzoek
doen uitgaan naar ypserv(8) en de inhoud van de
NIS-afbeeldingen ontvangen, mits die gebruiker de domeinnaam
kent. Omdat soort ongeautoriseerde transacties te voorkomen,
ondersteunt ypserv(8) de optie “securenets”,
die gebruikt kan worden om de toegang te beperken tot een
opgegeven aantal hosts. Bij het opstarten probeert
ypserv(8) de securenets informatie te laden uit het bestand
/var/yp/securenets
.
Dit pad kan verschillen, afhankelijk van het pad dat
opgegeven is met de optie –p
. Dit
bestand bevat regels die bestaan uit een netwerkspecificatie
en een netwerkmasker, gescheiden door witruimte. Regels die
beginnen met #
worden als commentaar
gezien. Een voorbeeld van een securenetsbestand zou er zo uit
kunnen zien:
# 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
Als ypserv(8) een verzoek ontvangt van een adres dat
overeenkomt met een van de bovenstaande regels, dan wordt dat
verzoek normaal verwerkt. Als er geen enkele regel op het
verzoek van toepassing is, dan wordt het verzoek genegeerd en
wordt er een waarschuwing gelogd. Als het bestand
/var/yp/securenets
niet bestaat, dan
accepteert ypserv
verbindingen van iedere
host.
Het programma ypserv
ondersteunt ook het
pakket TCP Wrapper van Wietse Venema.
Daardoor kan een beheerder de instellingenbestanden van
TCP Wrapper gebruiken voor
toegangsbeperking in plaats van
/var/yp/securenets
.
Hoewel beide methoden van toegangscontrole enige vorm van beveiliging bieden, zijn ze net als de geprivilegieerde poorttest kwetsbaar voor “IP spoofing” aanvallen. Al het NIS-gerelateerde verkeer hoort door een firewall tegengehouden te worden.
Servers die gebruik maken van
/var/yp/securenets
kunnen wellicht
legitieme verzoeken van NIS-cliënten weigeren als die
gebruik maken van erg oude TCP/IP-implementaties. Sommige van
die implementaties zetten alle host bits op nul als ze een
broadcast doen en/of kijken niet naar het subnetmasker als ze
het broadcastadres berekenen. Hoewel sommige van die
problemen opgelost kunnen worden door de instellingen op de
cliënt aan te passen, zorgen andere problemen voor het
noodgedwongen niet langer kunnen gebruiker van NIS voor die
cliënt of het niet langer gebruiken van
/var/yp/securenets
.
Het gebruik van /var/yp/securenets
op een server met zo'n oude implementatie van TCP/IP is echt
een slecht idee en zal leiden tot verlies van
NIS-functionaliteit voor grote delen van een netwerk.
Het gebruik van het pakket TCP Wrapper leidt tot langere wachttijden op de NIS-server. De extra vertraging kan net lang genoeg zijn om een timeout te veroorzaken in cliëntprogramma's, in het bijzonder als het netwerk druk is of de NIS-server traag is. Als een of meer cliënten last hebben van dat symptoom, dan is het verstandig om de cliëntsysteem in kwestie NIS-slaveserver te maken en naar zichzelf te laten wijzen.
In het lab staat de machine basie
, die
alleen faculteitswerkstation hoort te zijn. Het is niet
gewenst die machine uit het NIS-domein te halen, maar het
passwd
bestand op de master NIS-server
bevat nu eenmaal accounts voor zowel de faculteit als de
studenten. Hoe kan dat opgelost worden?
Er is een manier om het aanmelden van specifieke gebruikers
op een machine te weigeren, zelfs als ze in de NIS-database
staan. Daarvoor hoeft er alleen maar
–gebruikersnaam
met het juiste aantal dubbele punten (zoals bij andere regels) aan het
einde van /etc/master.passwd
op de
cliëntmachine toegevoegd te worden, waar
gebruikersnaam
de gebruikersnaam van de
gebruiker die niet mag aanmelden is. De regel met de geblokkeerde
gebruiker moet voor de regel met +
staan om
NIS-gebruikers toe te staan. Dit gebeurt bij voorkeur
met vipw
, omdat vipw
de wijzigingen aan /etc/master.passwd
controleert en ook de wachtwoord database opnieuw bouwt na het
wijzigen. Om bijvoorbeeld de gebruiker
bill
te kunnen laten aanmelden op
basie
:
basie#
vipw
[voeg -bill::::::::: aan het einde toe, 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#
De methode uit het vorige onderdeel werkt prima als er maar voor een beperkt aantal gebruikers en/of machines speciale regels nodig zijn. Op grotere netwerken gebeurt het gewoon dat er wordt vergeten om een aantal gebruikers de aanmeldrechten op gevoelige machines te ontnemen of dat zelfs iedere individuele machine aangepast moet worden, waardoor het voordeel van NIS teniet wordt gedaan: centraal beheren.
De ontwikkelaars van NIS hebben dit probleem opgelost met netgroepen. Het doel en de semantiek kunnen vergeleken worden met de normale groepen die gebruikt worden op UNIX® bestandssystemen. De belangrijkste verschillen zijn de afwezigheid van een numeriek ID en de mogelijkheid om een netgroep aan te maken die zowel gebruikers als andere netgroepen bevat.
Netgroepen zijn ontwikkeld om gebruikt te worden voor grote, complexe netwerken met honderden gebruikers en machines. Aan de ene kant is dat iets Goeds. Aan de andere kant is het wel complex en bijna onmogelijk om netgroepen met een paar eenvoudige voorbeelden uit te leggen. Dat probleem wordt in de rest van dit onderdeel duidelijk gemaakt.
Stel dat de succesvolle implementatie van NIS in het lab de interesse heeft gewekt van een centrale beheerclub. De volgende taak is het uitbreiden van het NIS-domein met een aantal andere machines op de campus. De onderstaande twee tabellen bevatten de namen van de nieuwe gebruikers en de nieuwe machines met een korte beschijving.
Gebruikersnamen | Beschrijving |
---|---|
alpha ,
beta | Gewone medewerkers van de IT-afdeling |
charlie ,
delta | Junior medewerkers van de IT-afdeling |
echo ,
foxtrott ,
golf , ... | Gewone medewerkers |
able ,
baker , ... | Stagiairs |
Machinenamen | Beschrijving |
---|---|
war , death ,
famine ,
pollution | De belangrijkste servers. Alleen senior medewerkers van de IT-afdeling mogen hierop aanmelden. |
pride , greed ,
envy , wrath ,
lust , sloth | Minder belangrijke servers. Alle leden van de IT-afdeling mogen aanmelden op deze machines. |
one , two ,
three , four ,
... | Gewone werkstations. Alleen echte medewerkers mogen zich op deze machines aanmelden. |
trashcan | Een erg oude machine zonder kritische data. Zelfs de stagiair mag deze doos gebruiken. |
Als deze restricties ingevoerd worden door iedere gebruiker
afzonderlijk te blokkeren, dan wordt er een
-user
regel per
systeem toegevoegd aan de passwd
voor
iedere gebruiker die niet mag aanmelden op dat systeem. Als er
maar één regel wordt vergeten, kan dat een
probleem opleveren. Wellicht lukt het nog dit juist in te
stellen bij de bouw van een machine, maar het wordt
echt vergeten de regels toe te voegen voor
nieuwe gebruikers in de productiefase. Murphy was tenslotte een
optimist.
Het gebruik van netgroepen biedt in deze situatie een aantal voordelen. Niet iedere gebruiker hoeft separaat afgehandeld te worden. Een gebruik kan aan een of meer groepen worden toegevoegd en aanmelden kan voor alle leden van zo'n groep worden toegestaan of geweigerd. Als er een nieuwe machine wordt toegevoegd, dan hoeven alleen de aanmeldrestricties voor de netgroepen te worden ingesteld. Als er een nieuwe gebruiker wordt toegevoegd, dan hoeft die alleen maar aan de juiste netgroepen te worden toegevoegd. Die veranderingen zijn niet van elkaar afhankelijk: geen “voor iedere combinatie van gebruiker en machine moet het volgende ...”. Als de NIS-opzet zorgvuldig is gepland, dan hoeft er maar één instellingenbestand gewijzigd te worden om toegang tot machines te geven of te ontnemen.
De eerst stap is het initialiseren van de NIS-afbeelding netgroup. ypinit(8) van FreeBSD maakt deze map niet standaard, maar als die is gemaakt, ondersteunt de NIS-implementatie hem wel. Een lege map wordt als volgt gemaakt:
ellington#
vi /var/yp/netgroup
Nu kan hij gevuld worden. In het gebruikte voorbeeld zijn tenminste vier netgroepen: IT-medewerkers, IT-junioren, gewone medewerkers en stagiars.
IT_MW (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) STAGS (,able,test-domain) (,baker,test-domain)
IT_MW
, IT_APP
enzovoort, zijn de namen van de netgroepen. Iedere groep tussen
haakjes bevat een of meer gebruikersnamen voor die groep. De
drie velden binnen een groep zijn:
De naam van de host of namen van de hosts waar de volgende onderdelen geldig zijn. Als er geen hostnaam wordt opgegeven dan is de regel geldig voor alle hosts. Als er wel een hostnaam wordt opgegeven, dan wordt een donker, spookachtig en verwarrend domein betreden.
De naam van de account die bij deze netgroep hoort.
Het NIS-domein voor de account. Er kunnen accounts uit andere NIS-domeinen geïmporteerd worden in een netgroep als een beheerder zo ongelukkig is meerdere NIS-domeinen te hebben.
Al deze velden kunnen jokerkarakters bevatten. Details daarover staan in netgroup(5).
De naam van een netgroep mag niet langer zijn dan acht karakters, zeker niet als er andere besturingssystemen binnen een NIS-domein worden gebruikt. De namen zijn hoofdlettergevoelig: alleen hoofdletters gebruiken voor de namen van netgroepen is een makkelijke manier om onderscheid te kunnen maken tussen gebruikers-, machine- en netgroepnamen.
Sommige NIS-cliënten (andere dan die op FreeBSD draaien) kunnen niet omgaan met netgroepen met veel leden. Sommige oudere versies van SunOS™ gaan bijvoorbeeld lastig doen als een netgroep meer dan 15 leden heeft. Dit kan omzeild worden door meerdere subnetgroepen te maken met 15 gebruikers of minder en een echte netgroep die de subnetgroepen bevat:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3
Dit proces kan herhaald worden als er meer dan 225 gebruikers in een netgroep moeten.
Het activeren en distribueren van de nieuwe NIS-map is eenvoudig:
ellington#
cd /var/yp
ellington#
make
Hiermee worden drie nieuwe NIS-afbeeldingen gemaakt:
netgroup
,
netgroup.byhost
en
netgroup.byuser
. Met ypcat(1) kan
bekeken worden op de nieuwe NIS-afbeeldingen beschikbaar zijn:
ellington%
ypcat -k netgroup
ellington%
ypcat -k netgroup.byhost
ellington%
ypcat -k netgroup.byuser
De uitvoer van het eerste commando hoort te lijken op de
inhoud van /var/yp/netgroup
. Het tweede
commando geeft geen uitvoer als er geen host-specifieke
netgroepen zijn ingesteld. Het derde commando kan gebruikt
worden om een lijst van netgroepen voor een gebruiker op te
vragen.
Het instellen van de cliënt is redelijk eenvoudig. Om
de server war
in te stellen hoeft alleen met
vipw(8) de volgende regel in de regel daarna vervangen te
worden:
+:::::::::
Vervang de bovenstaande regel in de onderstaande.
+@IT_MW:::::::::
Nu worden alleen de gebruikers die in de netgroep
IT_MW
geïmporteerd in de
wachtwoorddatabase van de host war
, zodat
alleen die gebruikers zich kunnen aanmelden.
Helaas zijn deze beperkingen ook van toepassing op de
functie ~
van de shell en alle routines
waarmee tussen gebruikersnamen en numerieke gebruikers ID's
wordt gewisseld. Met andere woorden: cd
~user
werkt niet,
ls –l
toont het numerieke ID in plaats
van de gebruikersnaam en find . –user joe
–print
faalt met de foutmelding No
such user. Om dit te repareren moeten alle
gebruikers geïmporteerd worden, zonder ze het
recht te geven aan te melden op een server.
Dit kan gedaan worden door nog een regel aan
/etc/master.passwd
toe te voegen:
+:::::::::/sbin/nologin
Dit betekent “importeer alle gebruikers, maar vervang
de shell door /sbin/nologin
”. Ieder
veld in een passwd
regel kan door een
standaardwaarde vervangen worden in
/etc/master.passwd
.
De regel +:::::::::/sbin/nologin
moet
na +@IT_MW:::::::::
komen. Anders krijgen
alle gebruikers die uit NIS-komen
/sbin/nologin
als aanmeldshell.
Na deze wijziging hoeft er nog maar één
NIS-afbeelding gewijzigd te worden als er een nieuwe medewerker
komt bij de IT-afdeling. Dezelfde aanpak kan gebruikt worden
voor de minder belangrijke servers door de oude regel
+:::::::::
in de lokale versie van
/etc/master.passwd
door iets als het
volgende te vervangen:
+@IT_MW::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin
Voor normale werkstations zijn het de volgende regels:
+@IT_MW::::::::: +@USERS::::::::: +:::::::::/sbin/nologin
En dat zou allemaal leuk en aardig zijn als er niet na een
paar weken een beleidsverandering komt: de IT-afdeling gaat
stagiairs aannemen. De IT-stagiairs mogen de normale
werkstations en de minder belangrijke servers gebruiken en de
juniorbeheerders mogen gaan aanmelden op de hoofdservers. Dat
kan door een nieuwe groep IT_STAG
te maken en
de nieuwe IT-stagiairs toe te voegen aan die netgroep en dan de
instellingen op iedere machine te gaan veranderen. Maar zoals
het spreekwoord zegt: “Fouten in een centrale planning
leiden tot complete chaos.”
Deze situaties kunnen voorkomen worden door gebruik te maken
van de mogelijkheid in NIS om netgroepen in netgroepen op te
nemen. Het is mogelijk om rolgebaseerde netgroepen te maken.
Er kan bijvoorbeeld een netgroep BIGSRV
gemaakt worden om het aanmelden op de belangrijke servers te
beperken en er kan een andere netgroep
SMALLSRV
voor de minder belangrijke servers
zijn en een derde netgroep met de naam
USERBOX
voor de normale werkstations. Al die
netgroepen kunnen de netgroepen bevatten die op die machines
mogen aanmelden. De nieuwe regels in de NIS-afbeelding netgroup
zien er dan zo uit:
BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS
Deze methode voor het instellen van aanmeldbeperkingen werkt redelijk goed als er groepen van machines gemaakt kunnen worden met identieke beperkingen. Helaas blijkt dat eerder uitzondering dan regel. Meestal moet het mogelijk zijn om per machine in te stellen wie zich wel en wie zich niet mogen aanmelden.
Daarom is het ook mogelijk om via machinespecifieke
netgroepen de hierboven aangegeven beleidswijziging op te
vangen. In dat scenario bevat
/etc/master.passwd
op iedere machine twee
regels die met “+” beginnen. De eerste voegt de
netgroep toe met de accounts die op de machine mogen aanmelden
en de tweede voegt alle andere accounts toe met
/sbin/nologin
als shell. Het is verstandig
om als naam van de netgroep de machinenaam in
“HOOFDLETTERS” te gebruiken. De regels zien er
ongeveer als volgt uit:
+@MACHINENAAM
:::::::::
+:::::::::/sbin/nologin
Als dit voor alle machines is gedaan, dan hoeven de lokale
versies van /etc/master.passwd
nooit meer
veranderd te worden. Alle toekomstige wijzigingen kunnen dan
gemaakt worden door de NIS-afbeelding te wijzigen. Hieronder
staat een voorbeeld van een mogelijke netgroep map voor het
beschreven scenario met een aantal toevoegingen:
# Definieer eerst de gebruikersgroepen IT_MW (,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) ITSTAG (,kilo,test-domain) (,lima,test-domain) D_STAGS (,able,test-domain) (,baker,test-domain) # # En nu een aantal groepen op basis van rollen USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS # # Een een groep voor speciale taken. # Geef echo en golf toegang tot de anti-virus machine. SECURITY IT_MW (,echo,test-domain) (,golf,test-domain) # # Machinegebaseerde netgroepen # Hoofdservers WAR BIGSRV FAMINE BIGSRV # Gebruiker india heeft toegang tot deze server nodig. POLLUTION BIGSRV (,india,test-domain) # # Deze is erg belangrijk en heeft strengere toegangseisen nodig. DEATH IT_MW # # De anti-virus machine als hierboven genoemd. ONE SECURITY # # Een machine die maar door 1 gebruiker gebruikt mag worden. TWO (,hotel,test-domain) # [...hierna volgen de andere groepen]
Als er een soort database wordt gebruikt om de gebruikersaccounts te beheren, dan is het in ieder geval nodig dat ook het eerste deel van de afbeelding met de databaserapportagehulpmiddelen gemaakt kan worden. Dan krijgen nieuwe gebruikers automatisch toegang tot de machines.
Nog een laatste waarschuwing: het is niet altijd aan te raden gebruik te maken van machinegebaseerde netgroepen. Als er tientallen of zelfs honderden gelijke machines voor bijvoorbeeld studentenruimtes worden uitgerold, dan is het verstandiger rolgebaseerde netgroepen te gebruiken in plaats van machinegebaseerde netgroepen om de grootte van de NIS-afbeelding binnen de perken te houden.
In een NIS-omgeving werken een aantal dingen wel anders.
Als er een gebruiker toegevoegd moet worden, dan moet
die alleen toegevoegd worden aan de
master NIS-server en mag niet vergeten worden dat
de NIS-afbeeldingen herbouwd moeten worden. Als
dit wordt vergeten, dan kan de nieuwe gebruiker nergens
anders aanmelden dan op de NIS-master. Als bijvoorbeeld een
nieuwe gebruiker jsmith
toegevoegd moet
worden:
#
pw useradd jsmith
#
cd /var/yp
#
make test-domain
Er kan ook adduser jsmith
in plaats
van pw useradd jsmith
gebruikt
worden.
De beheeraccounts moeten buiten de NIS-afbeeldingen gehouden worden. Het is niet handig als de beheeraccounts en wachtwoorden naar machines waarop gebruikers zich aanmelden die geen toegang tot die informatie horen te hebben zouden gaan.
De NIS-master en slave moeten veilig blijven en zo min mogelijk niet beschikbaar zijn. Als de machine wordt gehackt of als hij wordt uitgeschakeld, dan kunnen er in theorie nogal wat mensen niet meer aanmelden.
Dit is de belangrijkste zwakte van elk gecentraliseerd beheersysteem. Als de NIS-servers niet goed beschermd worden, dan worden veel gebruikers boos!
ypserv voor FreeBSD biedt wat ondersteuning voor NIS v1 cliënten. De NIS-implementatie van FreeBSD gebruikt alleen het NIS v2 protocol, maar andere implementaties bevatten ondersteuning voor het v1 protocol voor achterwaartse compatibiliteit met oudere systemen. De ypbind-daemons die bij deze systemen zitten proberen een binding op te zetten met een NIS v1 server, hoewel dat niet per se ooit nodig is (en ze gaan misschien nog wel door met broadcasten nadat ze een antwoord van een v2 server hebben ontvangen). Het is belangrijk om te melden dat hoewel ondersteuning voor gewone cliëntoproepen aanwezig is, deze versie van ypserv geen overdrachtsverzoeken voor v1-afbeeldingen af kan handelen. Daarom kan ypserv niet gebruikt worden als master of slave in combinatie met oudere NIS-servers die alleen het v1 protocol ondersteunen. Gelukkig worden er in deze tijd niet meer zoveel van deze servers gebruikt.
Het is belangrijk voorzichtig om te gaan met het draaien van ypserv in een multi-server domein waar de server machines ook NIS-cliënten zijn. Het is in het algemeen verstandiger om de servers te dwingen met zichzelf te binden dan ze toe te staan een bindverzoek te broadcasten en het risico te lopen dat ze een binding met elkaar maken. Er kunnen vreemde fouten optreden als een van de servers plat gaat als er andere servers van die server afhankelijk zijn. Na verloop van tijd treedt op de cliënten wel een timeout op en verbinden ze met een andere server, maar de daarmee gepaard gaande vertraging kan aanzienlijk zijn en de foutmodus is nog steeds van toepassing, omdat de servers dan toch weer opnieuw een verbinding met elkaar kunnen vinden.
Het is mogelijk een host aan een specifieke server te binden
door aan ypbind
de vlag
–S
mee te geven. Om dit niet iedere keer
handmatig na een herstart te hoeven uitvoeren, kan de volgende
regel worden opgenomen in /etc/rc.conf
van
de NIS-server:
nis_client_enable="YES" # start ook het cliënt gedeelte nis_client_flags="-SNIS domain
,server
"
In ypbind(8) staat meer informatie.
Een van de meest voorkomende problemen bij het implementeren van NIS is de compatibiliteit van het wachtwoordformaat. Als een NIS-server wachtwoorden gebruikt die met DES gecodeerd zijn, dan kunnen alleen cliënten die ook DES gebruiken ondersteund worden. Als er bijvoorbeeld Solaris™ NIS-cliënten in een netwerk zijn, dan moet er vrijwel zeker gebruik gemaakt worden van met DES gecodeerde wachtwoorden.
Van welk formaat cliënten en servers gebruik maken is
te zien in /etc/login.conf
. Als een host
gebruik maakt van met DES gecodeerde wachtwoorden, dan staat er
in de klasse default
een regel als de
volgende:
default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Overige regels weggelaten]
Andere mogelijke waarden voor
passwd_format
zijn
blf
en md5
(respectievelijk voor Blowfish en MD5 gecodeerde
wachtwoorden).
Als er wijzigingen gemaakt zijn aan
/etc/login.conf
dan moet de
login capability database herbouwd worden door het volgende
commando als root
uit te voeren:
#
cap_mkdb /etc/login.conf
Het formaat van de wachtwoorden die al in
/etc/master.passwd
staan worden niet
bijgewerkt totdat een gebruiker zijn wachtwoord voor de eerste
keer wijzigt nadat de login capability
database is herbouwd.
Om te zorgen dat de wachtwoorden in het gekozen formaat zijn
gecodeerd, moet daarna gecontroleerd worden of de waarde
crypt_default
in
/etc/auth.conf
de voorkeur geeft aan het
gekozen formaat. Om dat te realiseren dient het gekozen formaat
vooraan gezet te worden in de lijst. Als er bijvoorbeeld
gebruik gemaakt wordt van DES gecodeerde wachtwoorden, dan hoort
de regel er als volgt uit te zien:
crypt_default = des blf md5
Als de bovenstaande stappen op alle FreeBSD gebaseerde NIS-servers en cliënten zijn uitgevoerd, dan is het zeker dat ze het allemaal eens zijn over welk wachtwoordformaat er op het netwerk wordt gebruikt. Als er problemen zijn bij de authenticatie op een NIS-cliënt, dan is dit een prima startpunt voor het uitzoeken waar de problemen vandaan komen. Nogmaals: als er een NIS-server in een heterogene omgeving wordt geplaatst, dan is het waarschijnlijk dat er gebruik gemaakt moet worden van DES op alle systemen, omdat dat de laagst overeenkomende standaard is.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.