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.
Note : 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.
nisdomainname="test-domain"Cette ligne définie le nom de domaine NIS, test-domain, à la configuration du réseau (e.g. au démarrage).
nis_server_enable="YES"Demandera à FreeBSD de lancer les processus du serveur NIS dès que le réseau est en fonctionnement.
nis_yppasswdd_enable="YES"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.
Note : 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)).
Note : 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:
ellington# ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors.
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:
ellington# vi /var/yp/Makefile
Vous devez commenter la ligne
NOPUSH = "True"
(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 à:
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.
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:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
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:
nisdomainname="test-domain" nis_client_enable="YES"
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:
+:::::::::
Note : 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.
Note : 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.
Note : 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:
# autorise les connexions depuis la machine locale -- obligatoire 127.0.0.1 255.255.255.255 # autorise les connexions de n'importe quelle machine # du réseau 192.168.128.0 192.168.128.0 255.255.255.0 # autorise les connexions de n'importe quelle machine # entre 10.0.0.0 et 10.0.15.255 # y compris les machines du laboratoire de test 10.0.0.0 255.255.240.0
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.
Note : 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:
basie# vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie# cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie#
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 -utilisateur à chaque fichier 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
ellington# 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 (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)
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.
Note : 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:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3Vous 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:
ellington# 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:
ellington% 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
+@IT_EMP:::::::::
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 ~utilisateur ne fonctionnera pas, et 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.
Avertissement : 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:
+@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin
Les lignes correspondantes pour les stations de travail normales seraient:
+@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin
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:
BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS
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/nologin
Une 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:
# Définir tout d'abord les groupes d'utilisateurs IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Définir, maintenant, des groupes basés sur les rôles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Et un groupe pour les tâches spéciales # Permettre à echo et golf d'accéder à notre machine anti-virus SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # les groupes réseau basés sur un ensemble de machines # Nos principaux serveurs WAR BIGSRV FAMINE BIGSRV # L'utilisateur india a besoin d'un accès à ce serveur POLLUTION BIGSRV (,india,test-domain) # # Celle-ci est très importante et nécessite plus de restrictions d'accès DEATH IT_EMP # # La machine anti-virus mentionnée précédemment ONE SECURITY # # Restreindre l'accès à une machine à un seul utilisateur TWO (,hotel,test-domain) # [...d'autres groupes suivent]
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_client_enable="YES" # run client stuff as well nis_client_flags="-S 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:
default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Entrées suivantes omises]
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
Note : 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:
crypt_default = des blf md5
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.
| Précédent | Sommaire | Suivant |
| Système de fichiers réseau (NFS) | Niveau supérieur | Configuration réseau automatique (DHCP) |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <[email protected]>.
Pour les questions sur cette documentation, contactez <[email protected]>.