Description of problem: Changing a domain password with pam_winbind.so is broken in current Fedora 17 (and likely rawhide): [root@stef-desktop security]# sudo passwd AD\\Fry Changing password for user AD\Fry. Changing password for AD\Fry (current) NT password: passwd: Authentication token manipulation error This is because of the use of use_authtok with the pam_winbind.so module. Attached is a patch which fixes the problem.
Created attachment 579573 [details] Use try_first_pass instead of use_authtok Patch to authinfo.py which changes use_authtok to try_first_pass for pam_winbind.so
Why does pam_winbind.so use try_first_pass instead of use_authtok as every other module does in password section. Also looking at the pam_winbind manual page it seems to me that use_authtok is the right option to be used.
Or perhaps both try_first_pass and use_authtok should be used?
There is code in pam_winbind.c which forces use_first_pass if use_authtok is set. This is really old code from 2002, and not a recent change. This is probably a bug. But I agree, that this simple flag change isn't the right fix. We actually need to do the following: * Move pam_winbind.so so it shows up at the top of the password stack in system-auth. We shouldn't be running pam_pwquality.so for AD users. AD has its own password policy enforced on the server. * Don't pass any use_authtok or try_first_pass flags. This is what's shown in the pam_winbind man page, and it makes sense.
I am afraid that would break changing passwords for local user accounts. What happens with pam_winbind if for example the domain controller cannot be reached?
It's not a problem because pam_winbind acts as if the user doesn't exist in both of these cases: * winbindd is not running * The domain controller is not running We get an immediate response that the user doesn't exist: [root@stef-rawhide projects]# passwd 'AD\\Fry' passwd: Unknown user name 'AD\\Fry'. [root@stef-rawhide projects]# passwd stef Changing password for user stef. New password: BTW, we should never be changing passwords when 'offline' so we also shouldn't include the 'cached_login' option for pam_winbind in the 'password' stack. I can file another bug for that if desired.
(In reply to comment #6) > BTW, we should never be changing passwords when 'offline' so we also > shouldn't include the 'cached_login' option for pam_winbind in the > 'password' stack. I can file another bug for that if desired. No need for that, I'll fix it with this bug. I am still unsure whether running pam_pwquality is that bad thing. It can make the passwords only better not worse so I'd still prefer leaving the order of the modules as is.
(In reply to comment #7) > I am still unsure whether running pam_pwquality is that bad thing. It can > make the passwords only better not worse so I'd still prefer leaving the > order of the modules as is. Because it overrides the specific domain password requirements and becomes a support issue for the domain administrator. For example, the IT department may favor frequently changed passwords over hard to remember ones. But as it currently is RHEL and Fedora would refuse to honor the policy of the active directory domain.
There is one more problem with changing the order of modules - it will probably break changing password for local users. Can you test what happens if you change password of a local user account when the pam_winbind is at the top of the stack? Also what happens if the machine is disconnected from network? If you use the configuration as written by authconfig, what do you see in the log if you add debugging to the pam_winbind? I still think that using use_authtok is OK.
As far as the use_authtok problem, this was caused by me commenting out pam_pwquality.