Bug 281802 - KCheckpass doesn't work correctly with samba accounts
Summary: KCheckpass doesn't work correctly with samba accounts
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: kcheckpass (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-11 13:27 UTC by Christian Nitschkowski
Modified: 2022-11-03 16:07 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Nitschkowski 2011-09-11 13:27:37 UTC
Version:           4.6
OS:                Linux

I can log into a session with a samba user account using kdm, but when I lock the screen, I can't unlock it anymore.
I tried to execute kcheckpass in a terminal and monitor the syslog files.
When I enter an incorrect password, kcheckpass will tell me

Error: Wrong Password
Authentication failure

The log tells me that the password is wrong, too:

Sep 11 15:15:12 pccn01 kcheckpass[8059]: pam_winbind(xdm:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_AUTH_ERR (7), NTSTATUS: NT_STATUS_WRONG_PASSWORD, Error message was: Wrong Password

So far this works as expected, but now here comes the problem:
When I try to enter the correct password, kcheckpass tells me "Authentication failure" and returns a value of 1 which means "incorrect password".
But the log now tells me
Sep 11 15:21:50 pccn01 kcheckpass[8269]: pam_winbind(xdm:auth): user 'NITSCHKOWSKI\christian' granted access
Sep 11 15:21:50 pccn01 kcheckpass[8269]: Authentication failure for christian@NITSCHKOWSKI (invoked by uid 0)

I can log on using kdm and the plain shell login, just kcheckpass doesn't work.

The permissions on kcheckpass are 4755 root shadow.

Reproducible: Always

Steps to Reproduce:
1. Call kcheckpass -U user@domain
2. Enter correct Password of the provided user.

Actual Results:  
The syslog contains a line stating the login was successfull and another line stating the authentication failed.
The kcheckpass utility returns a value of 1, stating the password was incorrect.

Expected Results:  
The syslog should contain a line stating the login was successfull and the kcheckpass utility should return the value 0.
Comment 1 Christian Nitschkowski 2015-02-22 10:22:54 UTC
The problem still exists on Plasma 5.2.
I don't know how it is implemented now, as kcheckpass seems to be no more.
Anyway, after the screen was locked in a session started by a user that is authenticated using a Samba PDC, the screen won't unlock as the password isn't recognized as valid.
I'll try to provide logs with the new version of Plasma.
Comment 2 Martin Flöser 2015-12-15 16:46:37 UTC
kcheckpass is still used in Plasma 5. Can you please try running kcheckpass from a console? It's in /usr/lib/<arch>/libexec/kf5/kcheckpass

we probably need quite some help here as we devs don't have a setup with authentication shrough samba.
Comment 3 David Walser 2016-08-09 19:37:16 UTC
This appears to be a problem with using non-local users in general.  However, KDE4 (Mageia 5) worked fine.  It's not until Plasma 5 (5.7.2 being the first version I tested) where the issue shows up (Mageia Cauldron).

I confirmed that running kcheckpass in the Konsole also gives Authentication failure when entering the correct password.  For a local user, it works just fine.  I have reported this also here:
https://bugs.mageia.org/show_bug.cgi?id=19103

/etc/pam.d/kcheckpass just includes system-auth for all 4 sections.  My non-local users are using sssd (the accounts are in Active Directory).

/etc/pam.d/system-auth has this:
auth        required      pam_env.so
auth        required      pam_mount.so
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8 use_first_pass
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     required      pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
-session    optional      pam_systemd.so
session     required      pam_tcb.so
session     optional      pam_sss.so
session     optional      pam_mount.so disable_interactive
Comment 4 Martin Flöser 2016-08-10 05:16:05 UTC
> /etc/pam.d/kcheckpass just includes system-auth for all 4 sections. 

This file is not provided by us. Seems mageia adds it?
Comment 5 David Walser 2016-08-10 11:15:34 UTC
(In reply to Martin Gräßlin from comment #4)
> > /etc/pam.d/kcheckpass just includes system-auth for all 4 sections. 
> 
> This file is not provided by us. Seems mageia adds it?

Yes, as has always been the case.  It wasn't until Plasma 5 that this issue appeared.  Is there some modification to the PAM configuration that you would suggest?
Comment 6 Martin Flöser 2016-08-10 12:36:56 UTC
> Is there some modification to the PAM configuration that you would suggest?

Sorry, I'm not familiar enough with PAM and especially AD authentication to suggest something. All I know is that kcheckpass auth code did not see any changes in years.
Comment 7 Nate Graham 2022-11-03 16:07:03 UTC
kcheckpass support has been removed for a couple releases now.