In Plasma's default configuration, it automatically locks the screen after some inactivity. For a local user, I was able to unlock the screen. For a user in Active Directory, which I'm able to use via sssd, unlocking the screen fails.
Please report this bug upstream
Appears to be:
It doesn't sound like upstream is going to be of any help here. Our PAM configurations haven't changed, but they say their code hasn't changed.
I suppose upstream could be right, this might be a PAM issue and not with kcheckpass itself. Running kcheckpass with ltrace -f, I notice a start difference between Mageia 5 and Cauldron. I'll attach logs.
Created attachment 8337 [details]
ltrace -f /usr/libexec/kcheckpass on Cauldron
I edited the log to show my password as "password"
Created attachment 8338 [details]
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5
(In reply to David Walser from comment #4)
> I suppose upstream could be right, this might be a PAM issue and not with
> kcheckpass itself. Running kcheckpass with ltrace -f, I notice a start
> difference between Mageia 5 and Cauldron. I'll attach logs.
you should see the problem with journalctl SYSLOG_FACILITY=10
in fact we need pam 1.3.0-5 in core/release
Any new information David on that one ?
No. I believe this is a PAM issue.
Is it still happening now that pam-1.3.0-5 is in mga6 ?
PAM 1.3.0 was already in Cauldron when this was happening. We just didn't immediately realize that since Sophie was using an outdated mirror.
any news on this ?
Someone needs to set up a test environment for this. I don't have access to the resources anymore, but this is an important bug.
It has been said in today's meeting that Nicolas will try to reproduce with David's help.
a coworker did the test and it worked, not with mga tools to configure the authentification but by configuration by hand.
How should we debug this further and hopefully find a fix? Should it stay as blocker for Mageia 6, or will it have to do with an errata entry and high priority for Mageia 7?
Since it will make Plasma completely unusable in affected environments, it really needs to be fixed, but one challenge is that I found this bug two jobs ago and am no longer in an environment where I can easily set up a reproducer for this. The first step is for someone to do so, so it can at least be tested and maybe debugged. If it can't be reproduced, then I guess we'll just have to hope for the best...
QA testers, could any of you try to reproduce this bug which is currently set as release_blocker, so that we can decide about it?
i would need a procedure to reproduce, i have some windows here, i can install some windows server, etc if needed but i don't know how to reproduce
i still need infos to reproduce
I know, I'm hoping to get to my Mageia bugs this weekend.
some news ?
Actually, maybe I do have some news. Having built a pam_mount package for RHEL at work based on the Mageia package, I have run into similar problems, and have figured out that it is due to pam_mount.conf.xml not being world readable. Strangely, this did not cause a problem with KDE 4 on Mageia 5, but it does on RHEL 7. As I was using pam_mount at my old job, it may have been the real cause. Other than that, the configuration at the old job was sssd authenticating against Active Directory. I will try to give more details on both aspects of that configuration soon.
OK, if your domain is example.com, you need to have...
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
proxiable = true
workgroup = EXAMPLE
realm = EXAMPLE.COM
kerberos method = secrets and keytab
security = ads
passwd: files sss
shadow: files sss
group: files sss
domains = example.com
fallback_homedir = /home/%u
default_shell = /bin/bash
description = AD domain
enumerate = false
cache_credentials = true
case_sensitive = false
min_id = 1000
id_provider = ad
ldap_schema = ad
dyndns_update = false
With a CIFS file server called "backup" and a share called "stuff", in /etc/security/pam_mount.conf.xml:
<volume sgrp="domain users" fstype="cifs" options="sec=krb5,cruid=%(USERUID)"
server="backup" path="stuff" mountpoint="~/stuff" />
# following line above pam_tcb.so auth line
auth required pam_mount.so disable_interactive
# following line below pam_tcb.so auth line
auth sufficient pam_sss.so use_first_pass
# following line below pam_tcb.so account line
account [default=bad success=ok user_unknown=ignore] pam_sss.so
# *NOTE* change account pam_deny.so line to pam_permit.so instead
# following line below pam_tcb.so password line
password sufficient pam_sss.so use_authtok
# following line above all session lines
session required pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent
# following lines below all session lines
session optional pam_sss.so
session optional pam_mount.so disable_interactive
If you have a domain administrator account (or one with permissions to join machines to the domain) called admin, do:
# kinit admin
# net ads join -k