La Situation est celle ci, Un serveur NIS freebsd et un client NIS linux (Redhat 5.2).
En voulant activer le NIS sur mon client linux je me suis heurter a un problème de password, tout marchait parfaitement mais voila les utilisateurs NIS ne pouvaient pas se connecter ... tres embêtant. Heureusement il existe plusieurs methodes pour résoudre ce probleme de compatibilité entre les deux OS.

Avant d'expliquer en detail les solutions possibles revenons sur les bases et le pourquoi du probleme.

NIS

NIS est un protocole permetant une centralisation des informations sur le reseau, comme les utilisateurs, les machines ou les périphériques. On peut le voir comme un annuaire du style de LDAP par exemple.
Le serveur génére des "MAPS" dans lequelles sont stockés les informations et les clients demandent au serveur NIS un champ en lui passant une clé (Nom d'un utilisateur et le serveur lui donne le password crypté)

Mise en place de NIS sur un client Linux:
Rien de plus simple il y a juste quelques fichiers a modifier pour que cela marche.
Editer /etc/sysconfig/network et y ajouter :

NISDOMAIN=your_nis_dommain

Editer /etc/yp.conf et ajouter la ligne suivante

domain your_nis_domain server ip_nis_server

Editer le fichier /etc/nsswitch comme ceci:

passwd:     files nis
shadow:     files nis
group:      files nis

Et ajouter dans /etc/passwd la ligne suivante a la fin du fichier. Elle sert a indiquer d'aller chercher le password dans la base NIS pour les utilisateurs non système.

+::::::

Le probleme rencontré viens du fait que BSD et Linux utilise gère les shadow password de differentes façon.

Dans un Linux, les password cryptés sont stockés dans le fichier /etc/shadow, et n'est lisible que par des processus root. Le fichier /etc/passwd contient les info sur l'utilisateur mais son password est remplacé par un "x" qui indique a root d'aller cherhcer la version crypté dans /etc/shadow

lohik:x:1000:1000:lohik,,,:/home/lohik:/bin/bash

Dans un BSD cela change un petit peu car le mot de passe crypté est stocké dans /etc/passwd.master, et le caractere dans /etc/passwd pour indiquer que les passwd est crypté est le "*"

lohik:*:1000:1000:lohik,,,:/home/lohik:/bin/bash

Le probleme qui se pose est que notre serveur NIS sous FreeBSD renvoie aux clients Linux un champ avec un "*", ce qu'ils ne comprennent pas et donc il devient impossible de se logger avec un utilisateur NIS.
Il y a plusieurs methodes pour bypasser ce petit probleme.

Methode 1:

La premiere methode consiste a forcer le client linux a voir que le champ password est un "x" et non un "*"
Sur le client NIS il suffit d'ajouter cette ligne a la fin du fichier /etc/passwd a la place de celle vu précédemment.

+:x:::::

Comme expliquer plus haut le "+" indique d'aller prendre le password dans la base NIS mais ici on a rajouter un "x", se qui force donc le champ deux (password dans /etc/passwd) a "x" et donc a la machine linux que le password est a aller chercher dans le NIS shadow.

Methode 2:

La deuxieme methode quand elle permet de stocker le password directement dans le /etc/passwd, et donc de ne pas a avoir a interpreter le "*". Pour cela il faut être coté serveur FreeBSD et éditer le fichier /var/yp/Makefile et decommenter la ligne UNSECURE="True"

If you want to use a FreeBSD NIS server to serve non-FreeBSD client
# (i.e. clients who expect the password field in the passwd maps to be
# valid) then uncomment this line. This will cause $YPDIR/passwd to
# be generated with valid password fields. This is insecure: FreeBSD
# normally only serves the master.passwd maps (which have real encrypted
# passwords in them) to the superuser on other FreeBSD machines, but
# non-FreeBSD clients (e.g. SunOS, Solaris (without NIS+), IRIX, HP-UX,
# etc...) will only work properly in 'unsecure' mode.
UNSECURE="True"
--------------------------------

Puis recreer les MAPS

Les password cryptés seront maintenant directement dans /etc/passwd 

lohik:$1$Emi8uZrE$VRQt3YWWZfw5hIsyB00:1000:1000:lohik,,,:/home/lohik:/bin/bash

Le problème est que maintenant les password cryptes sont directement accessible, et pour securiser cela il faut bien sur enlever certaines commandes aux utilisateurs lambda, comme ypcat ou bien gettent

chmod 700 usr/bin/ypcat
chmod 700 usr/bin/getent

Voila qui devrait suffir et marcher maintenant.