The "Current password: " prompt comes from PAM (CC'ing tmraz). I am not sure if also the second prompt comes from PAM (`grep -r -E -e 'Current.*Password' .` inside PAM src directory has no match), but surely such a string is not emitted by passwd.

I am tentatively reassigning to authselect as this is the place where the investigation should happen. It depends on the PAM configuration and it is either caused directly by incorrect PAM configuration or by some PAM module in the configuration.

Karel, please attach contents of /etc/pam.d/system-auth.

$ cat /etc/pam.d/system-auth
# Generated by authselect on Fri Jun 21 08:20:27 2019
# Do not modify this file manually.

auth        required                                     pam_env.so
auth        required                                     pam_faildelay.so delay=2000000
auth        [default=1 ignore=ignore success=ok]         pam_succeed_if.so uid >= 1000 quiet
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok try_first_pass
auth        requisite                                    pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient                                   pam_sss.so forward_pass
auth        required                                     pam_deny.so

account     required                                     pam_unix.so
account     sufficient                                   pam_localuser.so
account     sufficient                                   pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required                                     pam_permit.so

password    requisite                                    pam_pwquality.so try_first_pass local_users_only
password    sufficient                                   pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient                                   pam_sss.so use_authtok
password    required                                     pam_deny.so

session     optional                                     pam_keyinit.so revoke
session     required                                     pam_limits.so
-session    optional                                     pam_systemd.so
session     [success=1 default=ignore]                   pam_succeed_if.so service in crond quiet use_uid
session     required                                     pam_unix.so
session     optional                                     pam_sss.so

Is 'karel' a local or LDAP user?

The message with uppercase 'P' comes probably from SSSD:
src/sss_client/pam_sss.c:                    ret = prompt_2fa(pamh, pi, _("First Factor (Current Password): "),
src/sss_client/pam_sss.c:                    ret = prompt_2fa(pamh, pi, _("First Factor (Current Password): "),
src/sss_client/pam_sss.c:                ret = prompt_password(pamh, pi, _("Current Password: "));

The pam_sss should not ask for the current password again. Either this is a bug in pam_sss or the configuration should add try_first_pass to the password sufficient pam%sss.so line.

(In reply to Pavel Březina from comment #6)
> Is 'karel' a local or LDAP user?

local user

I am very sorry, I can see that I didn't state it clearly but I have provided wrong password in the 1st prompt. Therefore the 2nd prompt appeared I guess. Originally, I was really just reporting the difference in the prompt.

OK, this makes the situation more clear. Does pam_sss support use_first_pass option in the password stack? If so, this option should be used with it.

The problem is that even if you entered the right password at the second prompt, the password change would fail anyway. The second prompt is basically useless.

Thanks, I can now reproduce it when providing incorrect password for the first time. 'use_first_pass' seems to help, but I'd like to confirm this with Sumit to be clear that it is the right choice and won't break possible 2FA.

2FA should not apply to changing passwords - i.e. pam_sss should fail if invoked in the PAM password stack for an user with 2FA set.

Hi,

SSSD currently lets the user change the first factor, the long term component (password), with the help of the passwd command if the user is allowed to change it on the server side. For this pam_sss has to ask for the second factor as well to get the needed authorization to change the first factor. But this is currently handle a bit inflexible by pam_sss, mainly it does not check if the old password was already requested by some other component. So I would suggest to move this ticket to the SSSD component and make sure pam_sss does not ask if the old password is already available.

bye,
Sumit

Thank you Sumit. I switched the component to SSSD.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

*** This bug has been marked as a duplicate of bug 2179607 ***