Hide Forgot
After fixing various other breakage (gdm-session-worker aborting when pam_winbind uses PAM_RADIO_TYPE¹, authconfig misconfiguring the session stack²) I am finally prompted to change my Active Directory password during my GDM login. I understand why I am asked for the new password twice. That makes sense. However, why in $DEITY's name am I being asked for my *existing* password *three* times? At the GDM login screen I select my user, enter my password. I am warned that my password will expire in 4 days, and asked: "Do you want to change your password now? (yes/no/maybe)" I blink in confusion at the 'maybe' option, and type 'yes'. I am then prompted *again* for the password I just provided: (current) UNIX password: And then again for a third time, just in case: (current) NT password: Then finally I am prompted for: New password: I enter one, and despite it meeting my IT department's requirements, I am then told that it is a bad password because it is too similar to the old one. This is not appropriate behaviour for my local system. Policy is set and enforced by the *server*, and I shouldn't have to deal with a disjoint set of incompatible policies (and yes, 'change it every month' and 'must be entirely different' are incompatible ☺). Vacillating over whether to file this against authconfig, against samba, or just re-open bug 815405. Or maybe against PAM, since I think one of those prompts is pam_unix.so asking me for my old password despite the fact that I clearly don't *have* one in /etc/shadow ('dwoodhou:*:…') . Let's go for authconfig... ¹ https://bugzilla.gnome.org/show_bug.cgi?id=671106 ² https://bugzilla.redhat.com/show_bug.cgi?id=869273#c3
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.