Hi managers!
Sorry for the INCREDIBLE delay (over five weeks) for this summary, but the
customers sysadm - they have one since a month - took so long implementing
the fix and reporting back. He manages some PC networks also, so that was
probably the reason ;-)
Original question:
>
> Here a strange YP-related problem one of our customers is experiencing.
> Users "stored" in the YP maps cannot login on the YP client machines
> anymore. It seems that getpwuid(3) is returning "bad" passwords for these
> users from the YP map.
>
> The whole story:
>
> YP master is a SS-IPX (espresso) with 64 meg RAM, internal 200 meg disk,
> two 1 GB external disks, 150 meg streamer and a CD-ROM drive running 4.1.3
> and Sybase on a kernel reconfigured for Sybase. The YP clients (campari and
> tiramisu) are SS-1s with 24 meg RAM, internal 200 meg disk, both also running
> 4.1.3, both running generic kernels. All machines are one the same ethernet,
> no subnets.
>
> Apparently YP master espresso was removed for some days and they had campari
> replacing it for the time. After espresso came back they did not reconfigure
> campari, it went on acting as a second YP master for the same domain as host
> espresso! (they claim everything worked ok)
>
> I discovered this situation yesterday evening. So I killed ypserv and ypbind
> on campari and removed /var/yp/<domainname> and /var/yp/binding. On tiramisu
> I kill ypbind. Then I brought /etc/passwd of the machines back in sync (deleted
> "all" users from the local file on campari). Then I did a "ypmake" on YP master
> espresso and restarted ypbind on the two client. Seemed to work, ypwhich re-
> ported "espresso", ypcat and ypmatch reported correct information (it seemed).
>
> This morning they could not login on campari and tiramisu, on espresso they
> could. YP is still running correctly on the clients, i.e. ypwhich, ypcat and
> ypmatch work ok, but seem to get bad information, apparently from getpwuid(3)
> or some related function. I verified this by writing a small C program, that
> calls getpwuid(3) for a specified login name and reports the results from the
> returned struct passwd. On both clients, the pw_passwd field contains just "*"
> for all non-local users (users not in the local /etc/passwd), even when this
> program is running as root (like login does).
>
> As a temporary solution, they added their users to /etc/passwd on the clients.
>
> Suggestions, anyone? Beats me... (I'll summarize)
>
> P.S. None of the machines is configured C2 secure.
>
This description I sent contained a crucial error. The function returning the
"*"-passwords was/is not getpwuid(), but rather getpwnam()! Luckily, this did
not hinder people from finding the right fix...
SOLUTION:
The "+" entry in /etc/passwd on YP clients must *not* contain a password!
Several respondents pointed out that a "*" in the password field of the
"+" entry overrides the password for *all* users from YP and effectively
prevents them to login.
QUESTION:
The "+:*:0:0:::" passwd entries on the YP clients were supposed to prevent
the "creation" of a user named "+" (without a password!) in the case that
YP isn't running. Ok, that does not work, is there another way to do it?
Thanks to:
louis@andataco.com (Louis M. Brune)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
strombrg@hydra.acs.uci.edu (Dan Stromberg)
ups!upstage!glenn@fourx.Aus.Sun.COM (Glenn Satchell)
davidl@Newbridge.COM (David Law)
(Hal Stern again - is there a list/group he does *not* read ? ;-)
Here are the responses:
***** From: louis@andataco.com *************************************************
Did some "helpful" person put a yp-make into the crontab on one of your
slave servers? Or enable the crontab-related periodic yp-distributions?
Also, I believe the entries in /etc/passwd typically override the ones
in the yp map. The "*" would prevent them from logging in, even
though they're in the regular map.
***** From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer) ****
check the /etc/passwd files for a line linke
+:*:
at the end. this is supposed to work, ie, let you
pull in the YP maps but not create a valid user named "+" if
YP isn't running. instead, it overlays * as the password
of all YP-resident users.
[ and, in a second mail ]
it's probably a feature. i think the password should come
from NIS, not locally, but it is taken from the local file....
***** From: strombrg@hydra.acs.uci.edu *****************************************
It sure does sound like you have shadow passwords going...
Regardless, you might check the NIS Makefile, to verify exactly which
file is being used for the passwd maps.
Check out "passwd", "passwd.byname" and "passwd.byuid". Make sure
they all make sense, on the clients, and especially on the server.
If things stay weird, consider backing up all the NIS maps, and
reconfiguring YP as a master server, then sticking your data back in.
***** From: ups!upstage!glenn@fourx.Aus.Sun.COM ********************************
On the slave nis server(s) run ypwhich -m, this will tell you which
server it thinks is the master for a particular map. To fix either run
ypinit -s espresso or manually transfer over any incorrect maps using
/usr/etc/yp/ypxfr -f -h espresso <map-name>
***** From: davidl@Newbridge.COM (David Law) ***********************************
Sten: Check the ypmask in your master password file. Does it by chance begin
with "+:*:"? If so, get rid of the "*"'s in place of "0"'s. Someone here
tried this once as it was suggested in one of the Oreilly books (one of the
security related books). Needless to say, no one could logon to the servers
anymore.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:54 CDT