NIS, qui signifie “Network Information Services” (services d'information réseau), fut développé par Sun Microsystems pour centraliser l'administration de systèmes UNIX® (à l'origine SunOS™). C'est devenu aujourd'hui un standard industriel; tous les systèmes importants de type UNIX® (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, etc.) supportent NIS.
NIS était appelé au départ “Yellow Pages” (page jaunes), mais étant donné que c'était marque déposée, Sun changea le nom. L'ancienne appelation (et yp) est toujours rencontrée et utilisée.
C'est un système client/serveur basé sur les RPCs qui permet à un groupe de machines d'un domaine NIS de partager un ensemble de fichiers de configuration communs. Cela permet à un administrateur système de mettre en place des clients NIS avec un minimum de configuration et d'ajouter, modifier ou supprimer les informations de configuration à partir d'un unique emplacement.
C'est similaire au système de domaine Windows NT®; bien que l'implémentation interne des deux n'est pas du tout identique, les fonctionnalités de base sont comparables.
Il existe plusieurs termes et processus utilisateurs que vous rencontrerez lors de la configuration de NIS sous FreeBSD, que vous vouliez mettre en place un serveur NIS ou un client NIS:
Terme | Description |
---|---|
Nom de domaine NIS | Un serveur maître NIS et tous ses clients (y compris ses serveurs esclaves) ont un domaine NIS. Similaire au nom de domaine Windows NT®, le nom de domaine NIS n'a rien à voir avec le système DNS. |
rpcbind | Doit tourner afin d'activer les RPC (Remote Procedure Call, appel de procédures distantes, un protocole réseau utilisé par NIS). Si rpcbind ne tourne pas, il sera impossible de faire fonctionner un serveur NIS, ou jouer le rôle d'un client NIS. |
ypbind | Fait pointer un client NIS vers son serveur NIS. Il récupérera le nom de domaine NIS auprès du système, et en utilisant les RPC, se connectera au serveur. ypbind est le coeur de la communication client-serveur dans un environnement NIS; si ypbind meurt sur une machine cliente, elle ne sera pas en mesure d'accéder au serveur NIS. |
ypserv | Ne devrait tourner que sur les serveurs NIS, c'est le processus serveur en lui-même. Si ypserv(8) meurt, alors le serveur ne pourra plus répondre aux requêtes NIS (avec un peu de chance, un serveur esclave prendra la relève). Il existe des implémentations de NIS (mais ce n'est pas le cas de celle de FreeBSD), qui n'essayent pas de se reconnecter à un autre serveur si le serveur utilisé précédemment meurt. Souvent, la seule solution dans ce cas est de relancer le processus serveur (ou même redémarrer le serveur) ou le processus ypbind sur le client. |
rpc.yppasswdd | Un autre processus qui ne devrait tourner que sur les serveurs maître NIS; c'est un “daemon” qui permettra aux clients de modifier leur mot de passe NIS. Si ce “daemon” ne tourne pas, les utilisateurs devront ouvrir une session sur le serveur maître NIS et y changer à cet endroit leur mot de passe. |
Dans un environnement NIS il y a trois types de machines: les serveurs maîtres, les serveurs esclaves et les clients. Les serveurs centralisent les informations de configuration des machines. Les serveurs maîtres détiennent l'exemplaire de référence de ces informations, tandis que les serveurs esclaves en ont un double pour assurer la redondance. Les clients attendent des serveurs qu'ils leur fournissent ces informations.
Le contenu de nombreux fichiers peut être
partagé de cette manière. Les fichiers
master.passwd
,
group
, et hosts
sont
fréquemment partagés par l'intermédiaire
de NIS. A chaque fois qu'un processus d'une machine cliente a
besoin d'une information qu'il trouverait normalement
localement dans un de ces fichiers, il émet une
requête au serveur NIS auquel il est rattaché
pour obtenir cette information.
Un serveur NIS maître.
Ce serveur, analogue à un contrôleur de
domaine Windows NT® primaire, gère les fichiers
utilisés par tous les clients NIS. Les fichiers
passwd
, group
,
et les autres fichiers utilisés par les clients NIS
résident sur le serveur maître.
Il est possible pour une machine d'être un serveur NIS maître pour plus qu'un domaine NIS. Cependant, ce cas ne sera pas abordé dans cette introduction, qui suppose un environnement NIS relativement petit.
Serveurs NIS esclaves. Similaire aux contrôleurs de domaine Windows NT® de secours, les serveurs NIS esclaves possèdent une copie des fichiers du serveur NIS maître. Les serveurs NIS esclaves fournissent la redondance nécessaire dans les environnements importants. Ils aident également à à la répartition de la charge du serveur maître: les clients NIS s'attachent toujours au serveur NIS dont ils reçoivent la réponse en premier, y compris si c'est la réponse d'un serveur esclave.
Clients NIS. Les clients NIS, comme la plupart des stations de travail Windows NT®, s'identifient auprès du serveur NIS (ou le contrôleur de domaine Windows NT® dans le cas de stations de travail Windows NT®) pour l'ouverture de sessions.
Cette section traitera de la configuration d'un exemple d'environnement NIS.
Supposons que vous êtes l'administrateur d'un
petit laboratoire universitaire. Ce laboratoire dispose de
15 machines FreeBSD, et ne possède pas actuellement de
point central d'administration; chaque machine a ses propres
fichiers /etc/passwd
et
/etc/master.passwd
. Ces fichiers sont
maintenus à jour entre eux grâce à des
interventions manuelles; actuellement quand vous ajoutez un
utilisateur pour le laboratoire, vous devez exécuter
adduser
sur les 15 machines. Cela doit
changer, vous avez donc décidé de convertir le
laboratoire à l'utilisation de NIS en utilisant deux
machines comme serveurs.
La configuration du laboratoire ressemble à quelque chose comme:
Nom de machine | Adresse IP | Rôle de la machine |
---|---|---|
ellington | 10.0.0.2 | Maître NIS |
coltrane | 10.0.0.3 | Esclave NIS |
basie | 10.0.0.4 | Station de travail |
bird | 10.0.0.5 | Machine cliente |
cli[1-11] | 10.0.0.[6-17] | Autres machines clientes |
Si vous mettez en place un système NIS pour la première fois, c'est une bonne idée de penser à ce que vous voulez en faire. Peu importe la taille de votre réseau, il y a quelques décisions à prendre.
Ce n'est pas le “nom de domaine” dont vous avez l'habitude. Il est plus exactement appelé “nom de domaine NIS”. Quand un client diffuse des requêtes pour obtenir des informations, il y inclut le nom de domaine NIS auquel il appartient. C'est ainsi que plusieurs serveurs d'un même réseau peuvent savoir lequel d'entre eux doit répondre aux différentes requêtes. Pensez au nom de domaine NIS comme le nom d'un groupe de machines qui sont reliées entre elles.
Certains choisissent d'utiliser leur nom de domaine Internet pour nom de domaine NIS. Ce n'est pas conseillé parce que c'est une source de confusion quand il faut résoudre un problème réseau. Le nom de domaine NIS devrait être unique sur votre réseau et est utile s'il décrit le groupe de machines qu'il représente. Par exemple, le département artistique de Acme Inc. pourrait avoir “acme-art” comme nom de domaine NIS. Pour notre exemple, nous supposerons que vous avez choisi le nom test-domain.
Cependant, certains systèmes d'exploitation (notamment SunOS™) utilisent leur nom de domaine NIS pour nom de domaine Internet. Si une ou plusieurs machines sur votre réseau présentent cette restriction, vous devez utiliser votre nom de domaine Internet pour nom de domaine NIS.
Il y a plusieurs choses à garder à l'esprit quand on choisit une machine destinée à être un serveur NIS. Un des problèmes du NIS est le degré de dépendance des clients vis à vis du serveur. Si un client ne peut contacter le serveur de son domaine NIS, la plupart du temps la machine n'est plus utilisable. L'absence d'information sur les utilisateurs et les groupes bloque la plupart des systèmes. Vous devez donc vous assurer de choisir une machine qui ne sera pas redémarré fréquemment, ni utilisée pour du développement. Idéalement, le serveur NIS devrait être une machine dont l'unique utilisation serait d'être un serveur NIS. Si vous avez un réseau qui n'est pas très chargé, il peut être envisagé de mettre le serveur NIS sur une machine fournissant d'autres services, gardez juste à l'esprit que si le serveur NIS n'est pas disponible à un instant donné, cela affectera tous vos clients NIS.
La copie de référence de toutes les
informations NIS est stockée sur une seule machine
appelée serveur NIS maître. Les bases de
données utilisées pour le stockage de ces
informations sont appelées tables NIS (“NIS
maps”). Sous FreeBSD ces tables se trouvent dans
/var/yp/[domainname]
où
[domainname]
est le nom du domaine NIS
concerné. Un seul serveur NIS peut gérer
plusieurs domaines à la fois, il peut donc y avoir
plusieurs de ces répertoires, un pour chaque domaine.
Chaque domaine aura son propre jeu de tables.
Les serveurs NIS maîtres et esclaves traitent toutes les requêtes NIS à l'aide du “daemon” ypserv. ypserv reçoit les requêtes des clients NIS, traduit le nom de domaine et le nom de table demandés en chemin d'accès à la base de données correspondante et transmet l'information de la base de données au client.
Selon vos besoins, la configuration d'un serveur NIS
maître peut être relativement simple. FreeBSD
offre par défaut un support direct du NIS. Tout ce
dont vous avez besoin est d'ajouter les lignes qui suivent
au fichier /etc/rc.conf
, et FreeBSD
s'occupera du reste pour vous.
Cette ligne définie le nom de domaine NIS,
test-domain
, à la
configuration du réseau (e.g. au
démarrage).
Demandera à FreeBSD de lancer les processus du serveur NIS dès que le réseau est en fonctionnement.
Ceci activera le “daemon” rpc.yppasswdd, qui, comme mentionné précedement, permettra aux utilisateurs de modifier leur mot de passe à partir d'une machine cliente.
Selon votre configuration NIS, vous aurez peut-être à ajouter des entrées supplémentaires. Consultez la section sur les serveurs NIS qui sont également des clients NIS, plus bas, pour plus de détails.
Maintenant, tout ce que vous devez faire est
d'exécuter la commande
/etc/netstart
en tant que
super-utilisateur. Elle configurera tout en utilisant les
valeurs que vous avez définies dans
/etc/rc.conf
.
Les tables NIS sont des fichiers
de base de données, qui sont conservés dans le
répertoire /var/yp
. Elles sont
générées à partir des fichiers
de configuration du répertoire /etc
du serveur NIS
maître, avec une exception: le fichier
/etc/master.passwd
. Et cela pour une
bonne raison, vous ne voulez pas divulguer les mots de passe
pour l'utilisateur root
et autres
comptes d'administration aux autres serveurs du domaine NIS.
Par conséquent, avant d'initialiser les tables NIS,
vous devrez faire:
#
cp /etc/master.passwd /var/yp/master.passwd
#
cd /var/yp
#
vi master.passwd
Vous devrez effacer toutes les entrées
concernant les comptes système
(bin
, tty
,
kmem
, games
,
etc.), tout comme les comptes que vous ne désirez
pas propager aux clients NIS (par exemple
root
et tout autre compte avec un UID
0 (super-utilisateur)).
Assurez-vous que le fichier
/var/yp/master.passwd
n'est pas
lisible par son groupe ou le reste du monde (mode 600)!
Utilisez la commande chmod
si
nécessaire.
Cela achevé, il est temps d'initialiser les
tables NIS! FreeBSD dispose d'une procédure
appelée ypinit
pour le faire
à votre place (consultez sa page de manuel pour plus
d'informations). Notez que cette procédure est
disponible sur la plupart des systèmes d'exploitation
du type UNIX®, mais pas tous. Sur Digital UNIX/Compaq
Tru64 UNIX, elle est appelée
ypsetup
. Comme nous voulons
générer les tables pour un maître NIS,
nous passons l'option -m
à
ypinit
. Pour générer les
tables NIS, en supposant que vous avez effectué les
étapes précédentes, lancez:
#
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.ypinit
devrait avoir
créé /var/yp/Makefile
à partir de
/var/yp/Makefile.dist
. Une fois
créé, ce fichier suppose que vous être
dans un environnement composé uniquement de
machines FreeBSD et avec un seul serveur. Comme
test-domain
dispose également
d'un serveur esclave, vous devez éditer
/var/yp/Makefile
:
#
vi /var/yp/Makefile
Vous devez commenter la ligne
(si elle n'est pas déjà commentée).
Configurer un serveur NIS esclave est encore plus
simple que de configurer un serveur maître. Ouvrez
une session sur le serveur esclave et éditez le
fichier /etc/rc.conf
comme
précédemment. La seule différence est
que nous devons maintenant utiliser l'option
-s
avec ypinit
.
L'option -s
a besoin du nom du serveur NIS
maître, donc notre ligne de commande ressemblera
à:
#
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.Vous devriez avoir un répertoire appelé
/var/yp/test-domain
. Des copies des
tables du serveur NIS maître devraient se trouver
dans ce répertoire. Vous devrez vous assurer que
ces tables restent à jour. Les entrées
suivantes dans /etc/crontab
sur vos
serveurs esclaves s'en chargeront:
Ces deux lignes obligent le serveur esclave à synchroniser ses tables avec celles du serveur maître. Bien que ces entrées ne soient pas indispensables puisque le serveur maître essaye de s'assurer que toute modification de ses tables NIS soit répercutée à ses serveurs esclaves et comme l'information sur les mots de passe est vitale pour les systèmes qui dépendent du serveur, il est bon de forcer les mises à jour. C'est d'autant plus important sur les réseaux chargés où il n'est pas certain que les mises à jour soient intégrales.
Maintenant, exécutez la commande
/etc/netstart
sur le serveur esclave,
ce qui lancera le serveur NIS.
Un client NIS établit une connexion avec un
serveur NIS donné par l'intermédiaire du
“daemon” ypbind.
ypbind consulte le nom de domaine
par défaut du système (défini par la
commande domainname
), et commence
à diffuser des requêtes RPC sur le
réseau local. Ces requêtes précisent le
nom de domaine auquel ypbind
essaye de se rattacher. Si un serveur configuré pour
ce domaine reçoit une des requêtes
diffusées, il répond à
ypbind, qui enregistrera
l'adresse du serveur. S'il y a plusieurs serveurs
disponibles (un maître et plusieurs esclaves par
example), ypbind utilisera
l'adresse du premier à répondre. Dès
lors, le système client dirigera toutes ses
requêtes NIS vers ce serveur.
ypbind enverra de temps en temps
des requêtes “ping” au serveur pour
s'assurer qu'il fonctionne toujours. S'il ne reçoit
pas de réponse dans un laps de temps raisonnable,
ypbind considérera ne plus
être attaché au domaine et recommencera
à diffuser des requêtes dans l'espoir de
trouver un autre serveur.
Configurer une machine FreeBSD en client NIS est assez simple.
Editez le fichier
/etc/rc.conf
et ajoutez les lignes
suivantes afin de définir le nom de domaine NIS
et lancez ypbind au
démarrage du réseau:
Pour importer tous les mots de passe disponibles
du serveur NIS, effacez tous les comptes utilisateur de
votre fichier /etc/master.passwd
et
utilisez vipw
pour ajouter la ligne
suivante à la fin du fichier:
Cette ligne permet à chaque utilisateur
ayant un compte valide dans les tables de mots de
passe du serveur d'avoir un compte sur le client. Il
y a plusieurs façons de configurer votre client
NIS en modifiant cette ligne. Consultez la section
groupes
réseau plus bas pour plus
d'informations. Pour en savoir plus, reportez-vous
à l'ouvrage Managing NFS and
NIS
de chez O'Reilly.
Vous devriez conservez au moins un compte local
(i.e. non-importé via NIS) dans votre fichier
/etc/master.passwd
et ce compte
devrait également être membre du groupe
wheel
. Si quelque chose se
passe mal avec NIS, ce compte peut être
utilisé pour ouvrir une session à
distance, devenir root
, et
effectuer les corrections nécessaires.
Pour importer tous les groupes disponibles du
serveur NIS, ajoutez cette ligne à votre fichier
/etc/group
:
Une fois que c'est fait, vous devriez être en
mesure d'exécuter ypcat passwd
et voir la table des mots de passe du serveur NIS.
De façon générale, n'importe quel
utilisateur distant peut émettre une requête RPC
à destination de ypserv(8) et
récupérer le contenu de vos tables NIS, en
supposant que l'utilisateur distant connaisse votre nom de
domaine. Pour éviter ces transactions non
autorisées, ypserv(8) dispose d'une
fonctionnalité appelée “securenets”
qui peut être utilisée pour restreindre
l'accès à un ensemble donné de machines.
Au démarrage, ypserv(8) tentera de charger les
informations sur les “securenets” à partir
d'un fichier nommé
/var/yp/securenets
.
Ce chemin d'accès peut varier en fonction du
chemin d'accès défini par l'option
-p
. Ce fichier contient des entrées
sous la forme de définitions de réseau et d'un
masque de sous-réseau séparé par une
espace. Les lignes commençant par un “#”
sont considérées comme des commentaires. Un
exemple de fichier securenets
peut
ressembler à ceci:
Si ypserv(8) reçoit une requête d'une
adresse qui satisfait à ces règles, il la traite
normalement. Si une adresse ne correspond pas aux
règles, la requête sera ignorée et un
message d'avertissement sera enregistré. Si le fichier
/var/yp/securenets
n'existe pas,
ypserv
autorisera les connexions à
partir de n'importe quelle machine.
Le programme ypserv
supporte
également l'outil TCP Wrapper
de Wietse Venema. Cela permet à l'administrateur
d'utiliser les fichiers de configuration de
TCP Wrapper pour contrôler les
accès à la place de
/var/yp/securenets
.
Bien que ces deux mécanismes de contrôle d'accès offrent une certaine sécurité, il sont, de même que le test du port privilégié, vulnérables aux attaques par “usurpation” d'adresses. Tout le trafic relatif à NIS devrait être bloqué par votre coupe-feu.
Les serveurs utilisant
/var/yp/securenets
pourront
échouer à traiter les requêtes de
clients NIS légitimes avec des implémentation
TCP/IP archaïques. Certaines de ces
implémentations positionnent à zéro les
bits de la partie machine de l'adresse IP lors de diffusions
et/ou sont incapables respecter le masque de
sous-réseau lors du calcul de l'adresse de diffusion.
Alors que certains de ces problèmes peuvent
être corrigés en modifiant la configuration du
client, d'autres problèmes peuvent forcer le retrait
des systèmes clients fautifs ou l'abandon de
/var/yp/securenets
.
Utiliser /var/yp/securenets
sur un
serveur avec une implémentation TCP/IP archaïque
est une mauvaise idée et sera à l'origine de
pertes de la fonctionnalité NIS pour une grande
partie de votre réseau.
L'utilisation du système TCP Wrapper augmente les temps de latence de votre serveur NIS. Le délai supplémentaire peut être suffisamment long pour dépasser le délai d'attente des programmes clients, tout particulièrement sur des réseaux chargés ou avec des serveurs NIS lents. Si un ou plusieurs de vos systèmes clients souffrent de ces symptômes, vous devrez convertir les systèmes clients en question en serveurs esclaves NIS et les forcer à se rattacher à eux-mêmes.
Dans notre laboratoire, il y a une machine
basie
qui est supposée être une
station de travail de la faculté. Nous ne voulons pas
retirer cette machine du domaine NIS, le fichier
passwd
sur le serveur maître NIS
contient les comptes pour la faculté et les
étudiants. Que pouvons-nous faire?
Il existe une méthode pour interdire à
certains utilisateurs d'ouvrir une session sur une machine,
même s'ils sont présents dans la base de
données NIS. Pour cela, tout ce dont vous avez besoin
de faire est d'ajouter
-nom_utilisateur
à la fin du fichier
/etc/master.passwd
sur la machine
cliente, où nom_utilisateur
est le nom de l'utilisateur auquel vous désirez refuser
l'accès. Ceci doit être fait de
préférence avec vipw
, puisque
vipw
contrôlera vos changements au
fichier /etc/master.passwd
, et
régénérera automatiquement la base de
données à la fin de l'édition. Par
exemple, si nous voulions interdire l'ouverture de session
à l'utilisateur bill
sur la
machine basie
nous ferions:
#
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#
La méthode présentée dans la section précédente fonctionne relativement bien si vous avez besoin de règles spécifiques pour un petit nombre d'utilisateurs et/ou de machines. Sur les réseaux plus important, vous oublierez d'interdire l'accès aux machines sensibles à certains utilisateurs, ou vous devrez même modifier chaque machine séparément, perdant par là même les avantages du NIS: l'administration centralisée.
La solution des développeurs du NIS pour ce problème est appelé groupes réseau (“netgroups”). Leur objet et définition peuvent être comparés aux groupes utilisés par les systèmes UNIX®. La principale différence étant l'absence d'identifiants (ID) numériques et la capacité de définir un groupe réseau à l'aide de comptes utilisateur et d'autres groupes réseau.
Les groupes réseau furent développés pour gérer des réseaux importants et complexes avec des centaines de machines et d'utilisateurs. C'est une bonne option si vous êtes forcés de faire avec une telle situation. Cependant leur complexité rend impossible une explication avec des exemples simples. L'exemple utilisé dans le reste de cette section met en évidence ce problème.
Supposons que l'introduction avec succès de NIS dans votre laboratoire a retenu l'attention de vos supérieurs. Votre mission suivante est d'étendre la couverture de votre domaine NIS à d'autres machines sur le campus. Les deux tables contiennent les noms des nouveaux utilisateurs et des nouvelles machines ainsi qu'une courte description de chacun.
Nom(s) d'utilisateurs | Description |
---|---|
alpha ,
beta | Les employés du département IT (“Information Technology“) |
charlie ,
delta | Les nouveaux apprentis du département IT |
echo ,
foxtrott ,
golf , ... | Les employés ordinaires |
able ,
baker , ... | Les internes actuels |
Nom(s) de machines | Description |
---|---|
war , death ,
famine ,
pollution | Vos serveurs les plus importants. Seuls les employés du département IT sont autorisés à ouvrir des sessions sur ces machines. |
pride , greed ,
envy , wrath ,
lust , sloth | Serveurs moins importants. Tous les membres du laboratoire IT sont autorisés à ouvrir des sessions sur ces machines. |
one , two ,
three , four ,
... | Stations de travail ordinaires. Seuls les employés réels sont autorisés à utiliser ces machines. |
trashcan | Une très vielle machine sans données sensibles. Même les internes peuvent utiliser cette machine. |
Si vous avez essayé d'implémenter ces
restrictions en bloquant séparément chaque
utilisateur, vous avez dû ajouter une ligne
-
à chaque fichier utilisateur
passwd
de chaque
système pour chaque utilisateur non-autorisé
à ouvrir une session sur le système. Si vous
omettez ne serait-ce qu'une entrée, vous aurez des
problèmes. Il doit être possible de faire cela
lors de la configuration initiale, cependant vous
finirez par oublier d'ajouter les lignes
pour de nouveaux utilisateurs lors d'opérations
quotidiennes. Après tout, Murphy était
quelqu'un d'optimiste.
Traiter cette situation avec les groupes réseau présente plusieurs avantages. Chaque utilisateur n'a pas besoin d'être traité séparément; vous assignez un utilisateur à un ou plusieurs groupes réseau et autorisez ou refusez l'ouverture de session à tous les membres du groupe réseau. Si vous ajoutez une nouvelle machine, vous n'aurez à définir les restrictions d'ouverture de session que pour les groupes réseau. Ces modifications sont indépendantes les unes des autres, plus de “pour chaque combinaison d'utilisateur et de machine faire...” Si votre configuration NIS est réfléchie, vous n'aurez à modifier qu'une configuration centrale pour autoriser ou refuser l'accès aux machines.
La première étape est l'initialisation de la table NIS du groupe réseau. La version FreeBSD d'ypinit(8) ne crée pas de table par défaut, mais son implémentation NIS la supportera une fois créée. Pour créer une table vide, tapez simplement
#
vi /var/yp/netgroup
et commencez à ajouter du contenu. Pour notre exemple, nous avons besoin de quatre groupes réseau: les employées du département IT, les apprentis du département IT, les employés normaux et les internes.
IT_EMP
, IT_APP
etc.
sont les noms des groupes réseau. Chaque groupement
entre parenthèses ajoute un ou plusieurs comptes
utilisateurs aux groupes. Les trois champs dans un groupement
sont:
Le nom de la/les machine(s) où les éléments suivants sont valides. Si vous ne précisez pas un nom de machine, l'entrée est valide sur toutes les machines. Si vous précisez un nom de machine, vous pénétrerez dans un royaume obscure, d'horreur et de confusion totale.
Le nom du compte qui appartient au groupe réseau.
Le domaine NIS pour le compte. Vous pouvez importer les comptes d'autres domaines NIS dans votre groupe réseau si vous êtes une de ces personnes malchanceuses avec plus d'un domaine NIS.
Chacun de ces champs peut contenir des jokers. Consultez la page de manuel netgroup(5) pour plus de détails.
Les noms de groupes réseau plus long que 8 caractères ne devraient pas être utilisés, tout particulièrement si vous avez des machines utilisant d'autres systèmes d'exploitation dans votre domaine NIS. Les noms sont sensibles à la casse des caractères; utiliser des majuscules pour vos noms de groupes réseau est une méthode simple pour distinguer les utilisateurs, les machines et les noms de groupes réseau.
Certains clients NIS (autres que FreeBSD) ne peuvent gérer les groupes réseau avec un grand nombre d'entrées. Par exemple, certaines anciennes versions de SunOS™ commencent à causer des problèmes si un groupe réseau contient plus de 15 entrées. Vous pouvez contourner cette limite en créant plusieurs sous-groupes réseau avec 15 utilisateurs ou moins et un véritable groupe réseau constitué des sous-groupes réseau:
Vous pouvez répéter ce processus si vous avez besoin de plus de 255 utilisateurs dans un seul groupe réseau.
Activer et propager votre nouvelle table NIS est simple:
#
cd /var/yp
ellington#
make
Ceci générera les trois tables NIS
netgroup
,
netgroup.byhost
et
netgroup.byuser
. Utilisez ypcat(1)
pour contrôler si vos nouvelles tables NIs sont
disponibles:
%
ypcat -k netgroup
ellington%
ypcat -k netgroup.byhost
ellington%
ypcat -k netgroup.byuser
La sortie devrait être semblable au contenu de
/var/yp/netgroup
. La deuxième
commande ne produira pas de sortie si vous n'avez pas
précisé les groupes réseau
spécifiques à une machine. La troisième
commande peut être utilisée pour obtenir les
listes des groupes réseau pour un utilisateur.
La configuration du client est plutôt simple. Pour
configurer le serveur war
, vous devez lancer
vipw(8) et remplacer la ligne
par
Maintenant, seules les données pour les
utilisateurs définis dans le groupe réseau
IT_EMP
sont importées dans la base
de données de mots de passe de war
et
seuls ces utilisateurs sont autorisés à ouvrir
une session.
Malheureusement, cette limitation s'applique
également à la fonction ~
de
l'interpréteur de commandes et toutes les routines de
conversion entre nom d'utilisateur et identifiant
numérique d'utilisateur. En d'autres termes,
cd ~
ne fonctionnera pas, et utilisateur
ls -l
affichera
l'ID numérique à la place du nom d'utilisateur
et find . -user joe -print
échouera
avec le message d'erreur No such user.
Pour corriger cela, vous devrez importer toutes les
entrées d'utilisateurs sans leur autoriser
l'ouverture de session sur vos serveurs.
Cela peut être fait en ajoutant une autre ligne au
fichier /etc/master.passwd
. Cette ligne
devrait contenir:
+:::::::::/sbin/nologin
, signifiant
“Importer toutes les entrées mais remplacer
l'interpréteur de commandes avec
/sbin/nologin
dans les entrées
importées”. Vous pouvez remplacer n'importe quel
champ dans l'entrée passwd
en
plaçant une valeur par défaut dans votre fichier
/etc/master.passwd
.
Assurez-vous que
+:::::::::/sbin/nologin
est placée
après +@IT_EMP:::::::::
. Sinon,
tous les comptes utilisateur importés du NIS auront
/sbin/nologin
comme interpréteur
de commandes.
Après cette modification, vous ne devrez uniquement
que modifier une des tables NIS si un nouvel employé
rejoint le département IT. Vous pourrez utiliser une
approche similaire pour les serveurs moins importants en
remplaçant l'ancienne ligne
+:::::::::
dans leur version locale de
/etc/master.passwd
avec quelque chose de
semblable à ceci:
Les lignes correspondantes pour les stations de travail normales seraient:
Tout était parfait jusqu'au changement de politique
quelques semaines plus tard: le département IT
commença à engager des internes. Les internes
du département IT sont autorisés à
utiliser les stations de travail normales et les serveurs les
moins importants; les apprentis du département IT sont
autorisés à ouvrir des sessions sur les serveurs
principaux. Vous ajoutez alors un nouveau groupe
réseau IT_INTERN
, ajoutez les
nouveaux internes IT à ce groupe réseau et
commencez à modifier la configuration sur chaque
machine... Comme disait l'ancien: “Erreurs dans la
planification centralisée mènent à un
désordre général”.
La capacité de NIS à créer des
groupes réseau à partir d'autres groupes
réseau peut être utilisée pour
éviter de telles situations. Une possibilité
est la création de groupes réseau basés
sur le rôle du groupe. Par exemple vous pourriez
créer un groupe réseau appelé
BIGSRV
pour définir les restrictions
d'ouverture de session pour les serveurs importants, un autre
groupe réseau appelé SMALLSRV
pour les serveurs moins importants et un troisième
groupe réseau nommé USERBOX
pour les stations de travail normales. Chacun de ces groupes
réseau contient les groupes réseau
autorisés à ouvrir des sessions sur ces
machines. Les nouvelles entrées pour la table NIS de
groupes réseau devrait ressembler à ceci:
Cette méthode qui consiste à définir des restrictions d'ouverture de session fonctionne relativement bien si vous pouvez définir des groupes de machines avec des restrictions identiques. Malheureusement, ceci est une exception et pas une généralité. La plupart du temps, vous aurez besoin de définir des restrictions d'ouverture de session par machine.
La définition de groupes réseau
spécifiques aux machines est une autre
possibilité pour traiter la modification de politique
soulignée précédemment. Dans ce
scénario, le fichier
/etc/master.passwd
de chaque machine
contient deux lignes débutant par “+”. La
première ajoute un groupe réseau avec les
comptes autorisés à ouvrir une session sur cette
machine, la seconde ajoute tous les comptes avec
l'interpréteur de commandes
/sbin/nologin
. C'est une bonne
idée d'utiliser des majuscules pour le nom de la
machine ainsi que celui du groupe réseau. Dans
d'autres termes, les lignes en question devraient être
semblables à:
NOMMACHINE
:::::::::
+:::::::::/sbin/nologinUne fois cette tâche achevée pour toutes vos
machines, vous n'aurez plus jamais à modifier les
versions locales du fichier
/etc/master.passwd
. Tous les changements
futurs peuvent être gérés en modifiant la
table NIS. Voici un exemple d'une table de groupes
réseau possible pour ce scénario avec quelques
petits plus:
Si vous utilisez une sorte de base de données pour gérer vos comptes utilisateur, vous devriez pouvoir créer la première partie de la table avec les outils de votre base de données. De cette façon, les nouveaux utilisateurs auront automatiquement accès aux machines.
Dernier avertissement: il n'est pas toujours conseillé d'utiliser des groupes réseau basés sur les machines. Si vous déployez quelques douzaines ou même centaines de machines identiques pour des laboratoires pour étudiants, vous devriez utiliser des groupes basés sur les types d'utilisateurs plutôt que sur les machines pour conserver la taille de la table NIS dans des limites raisonnables.
Il y a un certain nombre de choses que vous devrez effectuer différemment maintenant que vous êtes dans un environnement NIS.
A chaque fois que vous désirez ajouter un
utilisateur au laboratoire, vous devez l'ajouter
uniquement sur le serveur NIS et
vous devez ne pas oublier de reconstruire les
tables NIS. Si vous oubliez de le faire, le
nouvel utilisateur ne pourra pas ouvrir de session en dehors
du serveur maître NIS. Par exemple, si nous devons
ajouter au laboratoire un nouvel utilisateur
jsmith
, nous ferions:
#
pw useradd jsmith
#
cd /var/yp
#
make test-domain
Vous pouvez lancer adduser jsmith
à la place de pw useradd
jsmith
.
Conservez les comptes d'administration en dehors des tables NIS. Vous ne voulez pas propager les comptes et mots de passe d'administration sur les machines qui auront des utilisateurs qui ne devraient pas avoir accès à ces comptes.
Sécurisez les serveurs maître et esclave NIS, et réduisez leur temps d'arrêt. Si quelqu'un tente soit d'attaquer soit de simplement arrêter ces machines, de nombreuses personnes ne pourront plus ouvrir de session dans le laboratoire.
C'est la principale faiblesse d'un système d'administration centralisée. Si vous ne protégez pas vos serveurs NIS, vous aurez à faire face à de nombreux utilisateurs mécontents!
ypserv sous FreeBSD offre un support des clients NIS version 1. L'implémentation NIS de FreeBSD utilise uniquement le protocole NIS version 2, cependant d'autres implémentations disposent du support pour le protocole version 1 pour des raisons de compatibilité avec d'anciens systèmes. Les “daemons” ypbind fournis avec ces systèmes tenteront de s'attacher à un serveur NIS version 1 même s'ils n'en ont pas besoin (et ils pourront continuer à diffuser des requêtes pour en trouver un même après avoir reçu une réponse d'un serveur NIS version 2). Notez que bien que les requêtes des clients normaux soient supportées, cette version d'ypserv ne supporte pas les requêtes de transfert de tables version 1; par conséquent il n'est pas possible de l'utiliser comme serveur maître ou esclave avec des serveurs NIS plus anciens qui ne supportent que la version 1 du protocole. Heureusement, il n'y a, aujourd'hui, presque plus de serveurs de ce type actifs.
Il faut faire attention quand on utilise ypserv dans un domaine avec plusieurs serveurs NIS qui sont également des clients NIS. Il est en général préférable de forcer les serveurs de se rattacher à eux-mêmes plutôt que de les laisser diffuser des requêtes de rattachement et éventuellement se rattacher réciproquement les uns aux autres. Il peut en résulter de curieux problèmes si l'un des serveurs tombe et que d'autres en dépendent. Tous les clients finiront par dépasser leur délai d'attente et se tenteront de se rattacher à d'autres serveurs, mais ce délai peut être considérable et le problème persistera puisque les serveurs peuvent à nouveau se rattacher les uns aux autres.
Vous pouvez obliger une machine à se rattacher
à un serveur particulier en exécutant
ypbind
avec l'option -S
.
Si vous ne désirez pas faire cela à la main
à chaque fois que vous redémarrez votre serveur
NIS, vous pouvez ajouter les lignes suivantes à votre
fichier /etc/rc.conf
:
NIS domain
,server
"Voir la page de manuel de ypbind(8) pour plus d'informations.
Un des problèmes les plus courants que l'on rencontre en mettant en oeuvre NIS est celui de la compatibilité des formats de mots de passe. Si votre serveur NIS utilise des mots de passe chiffrés avec l'algorithme DES, il ne supportera que les clients utilisant également DES. Par exemple, si vous avez des client NIS Solaris™ sur votre réseau, alors vous aurez presque certainement besoin d'utiliser des mots de passe chiffrés avec le système DES.
Pour déterminer quel format vos serveurs et clients
utilisent, consultez le fichier
/etc/login.conf
. Si la machine est
configurée pour utiliser des mots de passe
chiffrés avec DES, alors la classe
default
contiendra une entrée comme
celle-ci:
D'autres valeurs possibles pour la capacité
passwd_format
sont blf
et md5
(respectivement pour les chiffrages
de mots de passe Blowfish et MD5).
Si vous avez modifié le fichier
/etc/login.conf
, vous devrez
également regénérer la base de
données des capacités de classes de session, ce
qui est accompli en exécutant la commande suivante en
tant que root
:
#
cap_mkdb /etc/login.conf
Le format des mots de passe utilisés dans
/etc/master.passwd
ne sera pas mis
à jour avant qu'un utilisateur ne change son mot de
passe pour la première fois
après la
régénération de la base de données des
capacités de classes de session.
Ensuite, afin de s'assurer que les mots de passe sont
chiffrés avec le format que vous avez choisi, vous
devez vérifier que l'entrée
crypt_default
dans le fichier
/etc/auth.conf
donne la priorité
au format de mots de passe choisi. Par exemple, quand les
mots de passe DES sont utilisés, l'entrée
serait:
En suivant les points précédents sur chaque serveur et client NIS sous FreeBSD, vous pouvez être sûr qu'ils seront tous d'accord sur le format de mot de passe utilisé dans le réseau. Si vous avez des problèmes d'authentification sur un client NIS, c'est probablement la première chose à vérifier. Rappelez-vous: si vous désirez mettre en place un serveur NIS pour un réseau hétérogène, vous devrez probablement utiliser DES sur tous les systèmes car c'est le standard le plus courant.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.