Univention Bugzilla – Bug 38082
Password change at UMC login not possible in AD member mode
Last modified: 2020-06-10 11:31:22 CEST
I've added an AD user and activated 'Password change on next login'. Afterwards, I was not able to login as this user in UMC. I got only: Authentication failure The authentication has failed, please login again. My expected behavior is that the password could be changed at the UMC login.
I've disabled the test case tests/01_base/90change_user_pwd_via_umcp in AD member mode.
Can confirm the following behavior with Windows 2012 and UCS 4.0-1 as AD member: 1. The domain (AD) user whose password is still valid can login to UMC, but cannot change the password. 2. The domain (AD) user with expired password cannot even login to UMC. 3. The domain (AD) administrator user can login and can change the password via UMC.
*** Bug 39505 has been marked as a duplicate of this bug. ***
pam_krb5 tells: PAM.error: ('User not known to the underlying authentication module', 10) Can be reproduced with the following script: from PAM import * pam = pam() pam.start('univention-management-console') pam.set_item(PAM_CONV, lambda auth, query_list, data: [(raw_input(p), 0) for p, i in query_list]) #pam.set_item(PAM_USER, 'expired') pam.chauthtok() So this seems a problem with our kerberos configuration. Could we add pam_winbind to the pam stack?
Created attachment 7284 [details] workaround (In reply to Florian Best from comment #4) > pam_krb5 tells: > PAM.error: ('User not known to the underlying authentication module', 10) Err, this was because I created the user via UDM (not via AD). The authenticate() call in pam_krb5 directly asks for the new password. The option "defer_pwchange" is not evaluated by pam_krb5. It raises PAM_AUTH_ERR (7) then instead of PAM_NEW_AUTHTOK_REQD (12). acct_mgmt() doesn't raise it either. The patch from Bug #36319 doesn't work. The attached patch is a workaround which checks for the hardcoded string 'New password' in the prompts if the authentication fails. IMHO pam_krb5 should be fixed.
It's not a pam_krb5 issue, it's a problem in heimdal. Heimdal doesn't implement the krb5_get_init_creds_opt_set_change_password_prompt API. This causes that it's not possible to use defer_pwchange/fail_pwchange in pam_krb5 when using heimdal as backend.
(In reply to Florian Best from comment #6) > It's not a pam_krb5 issue, it's a problem in heimdal. > Heimdal doesn't implement the > krb5_get_init_creds_opt_set_change_password_prompt API. This causes that > it's not possible to use defer_pwchange/fail_pwchange in pam_krb5 when using > heimdal as backend. In AD Member mode pam_krb5 connects to the MS Kerberos not to Heimdal.
> In AD Member mode pam_krb5 connects to the MS Kerberos not to Heimdal. Yes, I think he was referring to the kerberos client libraries.
(In reply to Arvid Requate from comment #8) > > In AD Member mode pam_krb5 connects to the MS Kerberos not to Heimdal. > > Yes, I think he was referring to the kerberos client libraries. Yes. I wrote a patch: https://github.com/heimdal/heimdal/commit/fce2671e46b2cbafaa8b6949473cf84789af3da6 When adding the patch to our debian package one needs to add the new function to debian/libkrb5-26-heimdal.symbols. Then pam-krb5 needs to be rebuild. "defer_pwchange" needs to be added as argument to the pam_krb5.so auth line in /etc/pam.d/univention-management-console.
Heimdal finally merged my patch in: https://github.com/heimdal/heimdal/commit/7422cd1f6b012c2edb4e04ec03c993b5c047611f There TM is heimdal 7.
As my patch is accepted upstream and released in debian stretch we could apply it also on ourself.
The patch for heimdal has been implemented in Bug #43859. *** This bug has been marked as a duplicate of bug 43859 ***