From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: Red Hat 9 NIS server, MD5 + Shadow passwords. Password cannot be changed for users, either by the user, or by root. This is true both on the NIS server itself, as well as NIS clients. I tried 2 different fresh installs. reproduceable on both installations. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. set up a NIS server 2. create a user 3. start up the necessary NIS services (ypbind, ypserv, yppasswdd) 4. try to change the password for a user. Actual Results: [root@tomboy root]# passwd greg Changing password for user greg. New password: Retype new password: RPC: Can't encode arguments The password has not been changed on tomboy.nanocube.localdomain. passwd: Failed preliminary check by password service Expected Results: password should be allowed to change Additional info: The only way to change a password, is as follows: 1) log onto the NIS server 2) stop ypbind 3) change the password 4) restart ypbind
I've seen this also, under RH 7.3 and 8.0. I even posted newsgroup article bE97a.3715$o7.39690.uiuc.edu about it (groups.google for "redhat yppasswd menscher" to find). Still trying to figure out a reasonable fix.
This problem is present since 7.x and there are several bug reports. The following workaround works on 7.x and 8.0: Turn off ypbind and disable nis in pam on the server. Then passwords can be changed on both clients and server. However, changing the password on the server will not automatically update the nis database. You should also disabel yppasswd, since it will create crypt passwords even if md5 is set.
Ok, given that the proposed workaround is to not be an NIS server, and given that NIS service is considered basic functionality of a UNIX machine, I'd like to recommend that the priority/severity levels be raised to "high". Unfortunately only the original bug submitter can do that, so I'm asking that he do that. Feel free to LART me if you think I'm being picky here, but I'm going to have to switch to a different distribution (or OS) if a fix (or reasonable workaround) can't be found.
This is also happening in Fedora Core 3. I spent quite a bit of time researching and implimenting NIS (new to linux administration) to come to the final point and have to consider a different resolution. I think this should also be raised to the hightest level.
I've made a couple of tests with FC3 and RHEL4 machines both as server or client. To recap the problems I see and things which work for me: Changing password on the machine with NIS server: - pam<0.77-66.2: 1. root cannot change user's password using passwd only by yppasswd passwd works fine for users - pam>=0.77-66.2: 2. passwd (by either user or root) changes only the /etc/shadow not the NIS one - root must update the NIS db afterwards Changing password on the client machine: - pam<0.77-66.2: - user only in the local /etc/passwd,shadow - everything OK - user both in the local /etc/passwd,shadow and on the remote server 3. passwd tries to change the password in the remote server however it's authenticated against the local - if the passwords differ the user cannot change it's password 4. root cannot change such user's password using passwd only yppasswd - this changes only the NIS password, not the local one - user only on the remote server 5. root cannot change such user's password using passwd only yppasswd - pam>=0.77-66.2: - user only in the local /etc/passwd,shadow - everything OK - user both in the local /etc/passwd,shadow and on the remote server 6. passwd changes only the local password not on the remote server - this will make them differ if they were the same before 7. root will change such user's local password - again it can make it out of sync with NIS password - user only on the remote server 8. root cannot change such user's password using passwd only yppasswd So we see that the update I've done in the pam-0.77-66.2 solved only some problems. The remaining problems: 2. - can be solved only for user, if root changes the user's password he must update the NIS db afterwards or he must use yppaswd (with it's deficiency of not using the MD5 hash), the solution is to update both local and NIS passwords but don't error if the NIS password update fails 6. - can be solved by the same solution 7.,8. - this cannot be easily solved - the workaround is the root must first use passwd to change the local password and then yppasswd to change the remote one
So the final solution is: 1. First try to update the NIS password 2. Regardless of its success or failure update the local password if the user is in the local files. 3. Return success or failure based only on the latest change done.