From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description of problem: passwd fails to change NIS passwords, with the error "RPC: Can't encode arguments" every time. Version-Release number of selected component (if applicable): pam-0.75-46.7.3 How reproducible: Always Steps to Reproduce: 1. passwd [userid] 2. enter a new password, retype it 3. watch it fail Actual Results: [root@nodeb root]# strace -o s passwd dsmith2 Changing password for user dsmith2. New password: BAD PASSWORD: it is too short Retype new password: RPC: Can't encode arguments The password has not been changed on nodea.drytel.net. passwd: Failed preliminary check by password service [root@nodeb root]# (see attachment for strace output) Expected Results: NIS password should have been changed Additional info:
Created attachment 93832 [details] strace output
have you modified you /etc/pam.d/system-auth?
As far as I know, no, we hadn't. However, we had to give up on NIS altogether about 4 months ago (not just because of this). And I just finished upgrading to RHAS3 last week, so I can't test the functionality easily. We're not running NIS under RHAS3 either, so I don't know if it's fixed.
This is happening on RHEL3 (in RH253 class lab) on the nis client... root can use yppasswd to change a nis user's passwd root cannot use passwd to change a nis user's passwd (not a bad thing) root also cannot change a local user's passwd (this is a problem) root can su to user and user can change with passwd (as expected) what I see: [root@server1 root]# passwd student Changing password for user student. New password: BAD PASSWORD: it is based on a dictionary word Retype new password: RPC: Can't encode arguments The password has not been changed on station4.example.com. passwd: Failed preliminary check by password service pam.d/passwd has not changed from install. pam.d/system-auth was generated by authconfig (looks correct to me). -Susan (RHCE/RHCX)
Had this at a remote site. Turned out that somebody had manually attempted to create an operator account but had placed the password in cleartext. The various routines were either bailing out with that message or switching to default berkeley encryption when they hit that line. Deleting the malformed account corrected the situation. - John
This seems to be many bugs/misconfigurations mixed together, could you please open a new bugs on each of this items if they are still happening?
I am getting this error in Fedora Core 3 was there a diagnosis?