| Summary: | KCheckpass doesn't work correctly with samba accounts | ||
|---|---|---|---|
| Product: | [Plasma] kscreenlocker | Reporter: | Christian Nitschkowski <cn001> |
| Component: | kcheckpass | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | bhush94, katyaberezyaka, luigiwalser, mgraesslin, nate |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Christian Nitschkowski
2011-09-11 13:27:37 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. 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. 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 > /etc/pam.d/kcheckpass just includes system-auth for all 4 sections.
This file is not provided by us. Seems mageia adds it?
(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? > 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.
kcheckpass support has been removed for a couple releases now. |