In practice this means that when you attempt to, for example, telnet to a Solaris 9 box that has “nis” specified within nsswitch.conf, it will do a lookup on the passwd.byname map from NIS. If that map is a shadowed passwd file, it will assume the “x” password field is actually the hashed password, and therefore authentication will fail.

I came across this after discovering that users could not login to a Solaris 9 client after not doing so for a long time. Since they last logged in successfully the NIS server had been migrated from a Solaris 7 box to a Slackware 12.2 box. The bizarre part being that the Solaris 7 server did store passwords in a shadow file. While I can’t confirm it now that the Solaris 7 box is no longer with us, I believe that the Solaris 7 NIS server was combining the passwd and shadow files to provide merged output when the passwd map was queried. The Slackware/Linux NIS server certainly doesn’t do this and instead provides separate passwd and shadow maps.