Bug 1007323 - Asked for password three times when changing it via pam_winbind
Asked for password three times when changing it via pam_winbind
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Guenther Deschner
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-12 05:29 EDT by David Woodhouse
Modified: 2015-12-02 11:06 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 21:57:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2013-09-12 05:29:12 EDT
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
Comment 1 Tomas Mraz 2013-09-12 06:43:42 EDT
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.
Comment 2 David Woodhouse 2013-09-12 07:49:45 EDT
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!
Comment 3 David Woodhouse 2013-09-12 07:54:40 EDT
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:
Comment 4 Tomas Mraz 2013-09-12 09:54:21 EDT
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.
Comment 5 David Woodhouse 2013-09-12 10:22:39 EDT
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?
Comment 6 Fedora End Of Life 2015-01-09 14:48:57 EST
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.
Comment 7 Fedora End Of Life 2015-02-17 12:09:37 EST
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.
Comment 8 Fedora End Of Life 2015-11-04 08:33:54 EST
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.
Comment 9 Fedora End Of Life 2015-12-01 21:57:35 EST
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.

Note You need to log in before you can comment on or make changes to this bug.