Artisan Numérique

/système/sécurité/authentification/nis/ L'authentification avec NIS

Après avoir utilisé pendant un temps LDAP, j'en arrive à la conclusion que ce type de serveur est parfait pour une grande structure mais totalement ridicule pour un réseau domestique. D'un autre côté, on a aussi autre à faire de son temps que de s'amuser à répliquer les comptes, les droits, les groupes sur 5 machines. La solution intermédiaire est un bon vieux retour au source avec NIS.

Principe

NIS est un protocole d'origine SUN dont le but est de publier sur un réseau UNIX à peu prés toutes les bases de données traditionnelles au format ndbm et ainsi les rendre disponibles pour des clients, UNIX eux aussi.

Ces bases de données sont tout simplement /etc/passwd, /etc/shadow, /etc/group, /etc/hosts, /etc/services, /etc/protocols, etc. En utilisant les 3 premières citées, de la même manière qu'avec un serveur LDAP, ce protocole permet de s'authentifier partout sur le réseau. Et en utilisant /etc/hosts il serait aussi possible de se passer, plus ou moins de Bind mais il est souvent délicat de se passer de DNS, même pour une petite infrastructure.

Techniquement NIS, aussi appelé Yellow Pages, utiliser le même canal RPC que les transactions NFS. NFS, pour ceux qui ne le savent pas, est aussi un système d'origine SUN, permettant le partage de dossier dans le monde UNIX à l'instar de SMB/CIFS dans le monde Windows.

Lorsque l'on ne compte QUE des machines UNIX dans son réseau, et que ce réseau n'est pas composé de what-milles bécanes, NIS est une très bonne alternative à LDAP/Bind. Non pas qu'il soit plus performant, loin de là, mais surtout parce qu'il est simple, stable, vieux, solide, il ne bouge plus ou presque. Et surtout il ne menace pas de vous planter à chaque mise à jour parce qu'un ingénieur de chez Mandriva (ou autre) a décidé qu'il était absolument intolérable que le serveur bidulo ne soit chrooté dans /var avec des ACLs sécurisés par des jetons Kerberos 5 et encapsulé dans des transactions chiffrées vous obligeant à passer la nuit à tenter de comprendre pourquoi vous êtes devenu un inconnu sur votre propre système...

NIS se contente très simplement d'utiliser ces bons vieux fichiers pour en faire des bases de données toute bêtes et de les publier à la demande aux clients qui en ont besoin.

Installation du serveur

Pour commencer, une brassée de paquets à installer : portmap (si vous n'avez pas déjà un serveur NFS), ypserv, yp-tools et nscd. Ce dernier permet d'ajouter un cache configuré par défaut pour retenir les login/mot de passe un certain temps. Cela permet de limite les requêtes faites sur le serveur pour connaître le group ou l'uid de tel ou tel utilisateur.

Première étape, déclarer un nom de réseau NIS. Pour cela il faut modifier votre fichier /etc/sysconfig/netword :

HOSTNAME=mon_serveur.mon_domaine.net
NETWORKING=yes
NETWORKING_IPV6=NO

# mon nom de domaine
NISDOMAIN=mon_domaine.net
/etc/sysconfig/network

Le serveur qui va distribuer les informations est ypserv. Son fichier de paramétrage est /etc/ypserv.conf et généralement il contient déjà tout ce qu'il faut, vérifiez seulement que vous avez au moins cela :

dns: no
files: 30
slp: no
slp_timeout: 3600
xfr_check_port: yes
* : * : shadow.byname : port
* : * : passwd.adjunct.byname : port
/etc/ypserv.conf

Faites un man ypserv.conf pour les deux dernières lignes si vous voulez blinder un peu la sécurité. Personnellement, dans un LAN domestique totalement étanche, je m'en moque un peu.

Maintenant il nous faut initialiser notre serveur principal

root/usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers.  nephilia.karma-lab.net is in the list of NIS server hosts.  Please continue to add
the names for the other hosts, one per line.  When you are done with the
list, type a <control D>.
next host to add:  mon_serveur.mon_domaine.net
next host to add:# CTRL-D
The current list of NIS servers looks like this:

mon_serveur.mon_domaine.net

Is this correct?  [y/n: y]# y
We need a few minutes to build the databases...
Building /var/yp/karma-lab.net/ypservers...
Running /var/yp/Makefile...
gmake[1]: entrant dans le répertoire « /var/yp/karma-lab.net »
Updating passwd.byname...
...
Updating shadow.byname...
gmake[1]: quittant le répertoire « /var/yp/karma-lab.net »

mon_serveur.mon_domaine.net has been set up as a NIS master server.
root#

Là je n'ai donc que faire répondre oui à la question, rien de bien sorcier. Et... c'est tout... Le serveur est techniquement configuré ;-) Maintenant un bon ami administrateur m'a un jour expliqué que ce n'était pas parce que Linux n'avait à peu prés jamais besoin de redémarrer qu'il ne fallait pas le faire pour vérifier que tout se lançait correctement, surtout sur un serveur. Et il a grandement raison, donc maintenant, redémarrage. Tant pis pour le record d'uptime ;-).

Une fois le serveur redémarré, vous pouvez regarder si tout semble en place

rootavons nous le bon domaines ?
mon_domaine

le service Yellow Pages est-il public sur le service RPC ?
rootrpcinfo -p localhost
program no_version protocole  no_port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
100024    1   udp  55448  status
100024    1   tcp  34159  status
100004    2   udp    646  ypserv
100004    1   udp    646  ypserv
100004    2   tcp    649  ypserv
100004    1   tcp    649  ypserv
600100069    1   udp    677  fypxfrd
600100069    1   tcp    679  fypxfrd
100009    1   udp    679  yppasswdd
...

Tout semble bon, passons au paramétrage des clients. Si vous utilisez un serveur dhcpd, vous pouvez aussi ajouter la ligne option nis-domain "karma-lab.net"; dans votre subnet de sorte à réduire ne pas avoir à régler ce domaine sur les clients.

Paramétrage des clients UNIX

Cette fois nous devons installer ypbind, yp-tools et toujours portmap. Vous l'aurez compris, ypbind est le client de ypserv et son paramétrage se fait par le fichier /etc/yp.conf dans lequel nous allons indique notre domaine et l'adresse IP de notre serveur NIS.

domain mon_domaine.net  server 10.0.0.100
/etc/yp.conf

NIS se contente de distribuer l'information. Le choix de la source d'authentification en elle-même passe par glibc et est paramétrée par le fichier /etc/nsswitch.conf. C'est dans ce fichier que nous allons indiquer les sources à utiliser par ordre de priorité et par type d'action voulue :

passwd:     files nis
shadow:     files nis
group:      files nis  
hosts:      file  dns
/etc/nsswitch.conf

Ainsi configuré, pour chacune des 3 clefs de recherche nous cherchons en priorité dans le fichier local puis si rien n'y est trouvé, la source NIS.

Dans mon cas, vu que je conserver le serveur DNS/Bind, le service hosts n'utilise pas nis. Pour faire autrement, intercalez seulement nis entre file et dns. N'oubliez pas non plus de modifier /etc/hosts.conf pour ajouter nis à la liste order.

Le paramétrage est terminé dans le cas où vous utilisez un serveur dhcp (voir plus haut) et presque terminé dans le cas contraire où il nous faut encore modifier /etc/sysconfig/network pour ajouter la même entrée NISDOMAIN=mon_domaine que pour le serveur.

Là il s'agit de la version longue. Dans la version courte, utilisez simplement l'outil mandriva drakauth, sélectionnez NIS, donnez le nom du domaine et l'adresse IP du serveur et validez. L'outil se charge de récupérer les paquets manquants et de tout configurer. Coût de l'opération, 5 secondes...

Ceci fait, il ne nous reste plus qu'à tester :

nous n'avons pas encore redémarré le client donc le domaine NIS
n'est pas encore initialisé, on le fait à la main
rootnisdomainname mon_domaine.net

démarrage du service ypbind
rootservice ypbind start
Recherche du nom de domaine NIS...                              [  OK  ]
Recherche d'un serveur de domaine NIS : mon_serveur.mon_domaine.net

vérifions que nous avons bien accès aux données, par exemple passwd
rootypcat passwd
gaston:x:1010:1010::/home/gaston:/bin/bash
...

et Si vous utilisez en plus les hosts...
rootybcat hosts
10.0.0.11    tagazok.mon_domaine.net
...

on ping pour voir si la résolution se fait correctement
ping tagazok.mon_domaine.net
64 bytes from tagazok.mon_domaine (10.0.0.11): icmp_seq=1 ttl=64 time=0.015 ms
...

Après il faut bien sur tester une authentification mais tout devrait marcher sans problèmes.

Mise à jour des bases de données

Un point appréciable avec NIS est que c'est aussi simple à maintenir qu'à configurer. Voyons sur le serveur en combien de temps nous pouvons ajouter un utilisateur, son groupe, et sa machine (si vous utilisez la publication de /etc/hosts) :

ajout d'un groupe et d'un utilisateur
rootgroupadd totoches
rootuseradd josette -g totoches

ajout d'un nouveau host (si vous avez publié /etc/hosts)
rootecho "10.0.0.12 machine_josette.mon_domaine.net" >> /etc/hosts

Maintenant la formule magique pour propager les nouveautés :
rootmake -C /var/yp
gmake[1]: entrant dans le répertoire « /var/yp/mon_domaine.net »
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating netid.byname...
Updating shadow.byname...
gmake[1]: quittant le répertoire « /var/yp/mon_domaine.net »

En gros cela a du prendre 10 à 30 secondes selon votre rapidité à taper les commandes. Pour vérifier que ce n'est pas du bleuf, un petit tour sur une machine cliente s'impose :

vérification de l'utilisateur josette
rootid josette
uid=1011(josette) gid=1011(totoches) groupes=1011(totoches)

vérification du nouveau host (si vous avez publié /etc/hosts)
rootping machine_josette.mon_domain.net
64 bytes from machine_josette.mon_domaine (10.0.0.12): icmp_seq=1 ttl=64 time=0.015 ms

Voilà, terminé. Maintenant il faut comparer cela au temps que cela aurait pris avec un serveur LDAP avec myLdapAdmin ou mieux... à la main en ligne de commande...

Pour les portables

Le soucis avec les authentification centralisée et les portables c'est que ce dernier ne sont pas toujours connecté au réseau. Du coup, impossible de contacter le serveur NIS et par voir de conséquence impossible de s'authentifier.

Pour régler ce problème de manière élégante nous allons utiliser nscd de manière plus avancée en modifiant un peu sa configuration. L'idée est d'obtenir quelque chose comme cela pour son fichier de configuration /etc/nscd.conf

reload-count            unlimited
paranoia                no
enable-cache            passwd          yes
positive-time-to-live   passwd          604800
negative-time-to-live   passwd          20
suggested-size          passwd          211
check-files             passwd          yes
persistent              passwd          yes
shared                  passwd          yes

enable-cache            group           yes
positive-time-to-live   group           604800
negative-time-to-live   group           60
suggested-size          group           211
check-files             group           yes
persistent              group           yes
shared                  group           yes

enable-cache            hosts           no
/etc/nscd.conf

Ainsi configuré, le cache va être persistant, maintenu autant que fois que nécessaire (reload-count), d'une durée de vie de 7 jours (604800 secondes) et ce pour les tables passwd et group. A noter que passwd indique ce que c'est la table /etc/passwd distante qui est mise en cache, celle qui ne contient pas les mots de passe.

L'effet de cette configuration est qu'une fois nscd relancé, un utilisateur connecté au réseau qui s'authentifie peut continue à travailler sur sa machine même s'il est déconnecté du réseau. En revanche, s'il met fin à sa session, comme shadow n'est pas en cache, il ne pourra plus s'authentifier.

Pour pouvoir ouvrir une session hors du réseau la seule solution est... de ne pas utiliser de mot de passe et préférer une authentification par empreinte digitale, par clef usb, etc.

Conclusion

J'étais passé de NIS à LDAP il y a un peu plus d'un an, pensant que ça allait me simplifier la vie. J'avoue que cela a été instructif car LDAP est un monde à part entière qu'il est pertinent d'au moins connaître un peu. Mais ce retour à NIS a été un vrai soulagement car même si c'est un petit réseau local, une partie de la complexité (le groupe d'accès à telle ou telle ressource via le net, le pote bidulo de passage sur le réseau, le bon ami à qui l'on crée un compte pour qu'il mate la machine pendant qu'on se dore la pilule, l'ajout de droits temporaire à la copine bidulette pour télécharger une vidéo, etc.) reste la même que pour un réseau plus grand à la différence que l'on a autre chose à faire de son temps que de jouer les administrateurs système...