Bug 1007323

That pam_unix asks for the password is not a real problem. The problem is that the password should be set into PAM_OLDAUTHTOK item and pam_winbind should use it. If you put the password pam_unix line twice into the config are you prompted 3 or 4 times for the password? If 3 times the problem is in pam_winbind either in the way the options are set or in the code. If 4 times, the problem is that pam_unix does not correctly set PAM_OLDAUTHTOK item.

In the case where a password change is triggered *during* login, surely PAM_OLDAUTHTOK should come from the *actual* password that I successfully logged in with? I didn't authenticate with pam_unix; I authenticated with pam_winbind. Should *that* have set PAM_OLDAUTHTOK, when it returned PAM_NEW_AUTHTOK_REQD in the session stack?

I changed /etc/pam.d/password-auth to read as follows:

password    requisite     pam_pwquality.so try_first_pass retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required	  pam_deny.so

I'm still only asked for '(current) UNIX password' once. So that's three times as before — the password I use for the *auth*, then both pam_unix and pam_winbind asking me for an 'old' password during the *password* stack run.

If I remove 'use_authtok' and 'try_first_pass' from the second pam_unix line, then I *do* get that '(current) UNIX password' question twice.

We can perhaps eliminate pam_unix from the equation and treat it as a separate issue. If I remove *both* pam_unix lines from the above, my login experience with GDM now goes:

 username: dwoodhou
 password: letmein!
 change password [yes/no/maybe]: yes
 (current) NT password: ...GR YOU ALREADY GOT TOLD THIS!

FWIW the experience with pam_unix is similar with passwd(8) although obviously I don't expect the PAM password stack to *know* my old password in advance in that case. I do expect to have to tell it once this time, but not *twice*:

$ passwd
Changing password for user dwoodhou.
Changing password for dwoodhou.
(current) UNIX password: 
Changing password for dwoodhou
(current) NT password:

There are two problems:

1. transferring the PAM_AUTHTOK from the auth step to PAM_OLDAUTHTOK in the password step is not easily possible. The PAM library actually actively clears the PAM_AUTHTOK value when the auth stack finishes. Of course there could be for example a module in the stack, that would save the password to PAM data and pull it out of there in tha password stack. But that would require configuration changes as well. Or we could change pam library to do that on its own but that would require consensual decision on PAM upstream whether this is desirable at all.

2. much more easily solvable problem is the third prompt from pam_winbind - it should pull the password from PAM_OLDAUTHTOK and it is apparently not doing it.

Reassigning to samba for investigation of the problem 2.

Note that although problem 1 is hard to solve "properly" for the reasons you describe, there's potentially scope for a winbind-specific solution.

Firstly, pam_winbind does "squirrel away" the user's password to winbindd, so it isn't lost. There may be some way for us to handle it that way (although offering a generic way to prod winbindd to "change my password to <XXX>" which works forever after login is not a good idea, of course).

Alternatively, pam_winbind does already store the fact that the password *needs* to be changed, in since it's discovered at auth time and needs to be reported in the account stack (cf. https://bugzilla.samba.org/show_bug.cgi?id=1524). So *maybe* it could also store the old authtok when it sets PAM_WINBIND_NEW_AUTHTOK_REQD_DURING_AUTH?

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.