From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050923 Galeon/2.0.0 Description of problem: passwd always seems to indicate that kerberosv5 password is updated, even when it has failed, e.g. due to password reuse. The native kerberos 'kpasswd' correctly reports to user whether password was updated successfully or not. $ passwd Changing password for user foo. Kerberos 5 Password: New password: Retype new password: passwd: all authentication tokens updated successfully. $ But in the kadmin logs: kadmind[3102](Notice): chpw request from 192. 168.0.3 for foo@DOMAIN: Cannot reuse password kpasswd correctly reports "password change rejected". Version-Release number of selected component (if applicable): passwd-0.68-10 How reproducible: Always Steps to Reproduce: 1. passwd 2. enter correct current password 3. try enter a password which is within the history/dont-reuse list for the principal concerned. Actual Results: passwd reported a succesful password change, even though the change never ocurred. Expected Results: It should have reported a failure, just as kpasswd does. Additional info: It's a bit of a security issue. Common practice on password resets can be to assign the user a new password, sometimes communicated via less-than-secure channels (telephone, email, or such). To minimise risk, the user must change the password ASAP. This window of risk is lengthened if the user believes they successfully changed their password.
Are there any messages in /var/log/secure and /var/log/messages on the client machine? Please post them if yes. Also attach /etc/pam.d/system-auth contents here. Passwd uses pam_krb5 when changing Kerberos passwords -> reassigning.
This is the messages entry for passwd: passwd[26324]: pam_krb5[26324]: password changed for foo@DOMAIN There isn't anything of note in secure. This is system-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so
Then it is a clearly pam_krb5 problem - it shouldn't report password changed when it actually wasn't changed.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Fedora Core 3 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.