This bug is created as a clone of upstream ticket:
Currently, entering an empty kerberos password at the XDM login prompt creates a "critical error" message.
It turns out that in the case of an empty password, Kerberos returns an LIBOS_CANTREADPWD to SSSD, which then returns PAM_CRED_UNAVAIL thru commit 383fa7e69136ce27031d7d0b9b9b8e5b0392bfee.
But actually it looks like Kerberos does not support empty passwords at all!
Hence, commit 383fa7e69136ce27031d7d0b9b9b8e5b0392bfee is correct in the sense that a Kerberos LIBOS_CANTREADPWD error should result in PAM_CRED_UNAVAIL.
**BUT** as Kerberos does even not support empty passwords, it returns LIBOS_CANTREADPWD somewhat wrongly here, interpreting the empty password as a failure to read a non-empty one (hence CANTREADPWD).
It should be SSSDs job to immediately return PAM_AUTH_ERR on an empty kerberos password, without actually forwarding the empty password to Kerberos (which would result in PAM_CRED_UNAVAIL).
I was not able to dig up Kerberos documentation that explicitly states that empty passwords are not allowed. Still, a google search reveals that this seems to be a commonly communicated fact".
Temporarily moving bugs to MODIFIED to work around errata tool bug
Verified the bug on SSSD Version: sssd-1.11.2-10.el7.x86_64
Steps followed during verification:
1. Login to GDM session with a kerberos user and "Empty password"
2. Monitor the /var/log/secure file for "System Error"
As expected, i couldn't find system error in the log file. The log file details during login is given below:
Dec 11 17:57:37 rhel-7 gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=tr_user
Dec 11 17:57:38 rhel-7 gdm-password]: pam_sss(gdm-password:auth): authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=tr_user
Dec 11 17:57:38 rhel-7 gdm-password]: pam_sss(gdm-password:auth): received for user tr_user: 7 (Authentication failure)
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.