>I set up a linux machine with shadow enabled as a nis client. Ypcat
>and ypmatch do not show the encrypted passwords; however, the problem
>is that the linux client haven't been able to authenticate users
>using the password map on the nis server.
If you are running a RedHat system, the chances are that you are using
libpwdb. While some of the ideas and the motivation behind pwdb are
good, the design is poor and the implementation is hopeless. When I
made our Linux and Solaris machines work together, I chose to try and
debug pwdb. I regret that decision; there are parts of the code that
could not have ever worked and so have never been tested, and the code
isn't finished anyway. The following should explain why you can't log in.
strings /lib/libpwdb.so | grep '\(shadow\.byname\|passwd\.adjunct\)' | wc -l
Edit /etc/pam.d/* and use pam_unix rather than pam_pwdb. You should
then be using the password functions in glibc which understand
passwd.adjunct and shadow.byname. passwd.adjunct is handled by
fiddling the result of getpw*, whereas shadow.byname is handle by
getspnam. Pick whichever takes your fancy. If you believe in password
aging, you might have a slight preference for shadow.byname, but don't
rely on it for expiring accounts unless you use pam on _all_ methods
by which users start new sessions. (Compare 'ldd /usr/sbin/crond' on a
RedHat machine and a Solaris machine and spot the missing library.)
I replaced the password program with 'ssh -t master_host passwd'. (You
don't want to use yppasswdd if you care about password file locking.)
Finally, I patched my libc to use netid.byname for initgroups(),
rather than reading the entire group.nyname map - one line at a time.
That was for libc5 - glibc2 is still broken in this respect but the
code is _much_ cleaner so it should be easy to fix. If you have
few entries in the groups map and you don't start atrun from cron, you
might not care to fix this.
If I you have any choice in the matter, don't touch nis with a barge-pole.