From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) This works in Guinness. passwd fails when system is configured with authconfig for LDAP. With or without TLS. I've tried OpenLDAP & iPlanet, so the server doesn't seem to be the problem. passwd hangs forever after new password is successfully entered. Reproducible: Always Steps to Reproduce: 1. Setup LDAP server & client for LDAP authentication 2. Login to LDAP client with posixAccount on LDAP Server 3. Type passwd, enter curernt password, pick a new one twice 4. Cry Actual Results: Nothing happens (this is bad). Expected Results: LDAP server should get an updated password, passwd should return instead of hang.
Server & client are separate machines, both i386 Fisher.
This most likely has to do with the fact that /usr/share/openldap/migration/migrate_passwd.pl produces userPassword LDAP attributes that start with {CRYPT} but these somehow get mangled by the time the hash goes into the LDAP server.
My previous additional comment is lame, please ignore it. When I comment password /lib/security/pam_unix.so ... out of /etc/pam.d/system-auth, I can once again update passwords with LDAP. I guess the bug is related to pam & pam_unix more than a problem in pam_ldap. This is still an annoying bug, but maybe not one for nalin.
When I replace /lib/security/pam_unix.so in Fisher with pam_unix.so from Guinness, the bug disappears. You can probably safely consider this a pam bug. I guess nalin gets those too? Busy guy. :)
We (Red Hat) should really try hard to fix this before next release.
Thinko in pam_unix's password-changing code. Should be fixed in pam-0.74-5, coming soon to a Raw Hide snapshot (ftp://ftp.redhat.com/pub/rawhide/) near you. Please reopen this bug if you find this continues to be a problem after applying the update. Thanks!
Will definitely do, thanks!