Thank you for the response.
The problems with login started after upgrades -this is Ubuntu Xenial .
In the meantime I debugged PAM.
I will look now in domain log
I attach sssd.conf and the sequence for 'longina' login from sssd-pam.log
Could it be that the problem is generated by lightdm / PAM?
It seems that there is something wrong in the very last step of the login sequence.
cat common-session |grep -v ^#
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_sss.so
session optional pam_mount.so
session optional pam_systemd.so
cat lightdm |grep -v ^#
auth requisite pam_nologin.so
auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
auth optional pam_gnome_keyring.so
auth optional pam_kwallet.so
auth optional pam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so
close
session required pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_gnome_keyring.so auto_start
session optional pam_kwallet.so auto_start
session optional pam_kwallet5.so auto_start
session required pam_env.so readenv=1
session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-password
Best,
Longina
-----Oprindelig meddelelse-----
Fra: Jakub Hrozek [mailto:jhrozek@redhat.com]
Sendt: 17. november 2016 09:25
Til: sssd-users(a)lists.fedorahosted.org
Emne: [SSSD-users] Re: sssd-13.4 can't login
On Wed, Nov 09, 2016 at 02:45:56PM +0000, Longina Przybyszewska wrote:
> Hi again,
> I still hang on that problem.
> Client and server are configured in AD trust realm environment.
> Client and server are joind to a.c.domain;
> User is from n.c.domain.
>
> During login sequence NFS-share (sec=krb5) homedir is mounted with
right nfsidmapping .
> User can't login because of access denied to the homedir.
>
> If I change mount parameter to sec=sys, user can successfully login.
>
> Machine's and user's credentials *are* valid ;
>
> ==
> Ticket cache: FILE:/tmp/krb5cc_332405654_B4r6Sy
> Default principal: longina(a)N.C.DOMAIN
>
> Valid starting Expires Service principal
> 11/09/2016 15:00:43 11/10/2016 01:00:43
krbtgt/N.C.DOMAIN(a)N.C.DOMAIN
> renew until 11/10/2016 01:00:43
> 11/09/2016 15:00:45 11/10/2016 01:00:43 krbtgt/C.SDU.DK(a)N.C.DOMAIN
> renew until 11/10/2016 01:00:43
> 11/09/2016 15:00:45 11/10/2016 01:00:43 nfs/adm-lptest.a.c.domain@
> renew until 11/10/2016 01:00:43
> 11/09/2016 15:00:45 11/10/2016 01:00:43 nfs/adm-
lptest.a.c.domain(a)A.C.DOMAIN
> renew until 11/10/2016 01:00:43
> ==
> Kerberos sequence for login ends with (krb5_child.log) :
>
> ==[sss_get_ccache_name_for_principal] (0x2000): krb5_cc_cache_match
failed: [-1765328243][Can't find client principal longina(a)N.C.DOMAIN in
cache collection]=
You can ignore this, since you are using the FILE: ccache which is
doesn't support collections, this error is harmless.
It looks like the krb5_child itself finished fine, according to:
> (Wed Nov 9 15:00:44 2016) [[sssd[krb5_child[1563]]]] [k5c_send_data]
(0x0200): Received error code 0
> (Wed Nov 9 15:00:44 2016) [[sssd[krb5_child[1563]]]]
[pack_response_packet] (0x2000): response packet size: [142]
> (Wed Nov 9 15:00:44 2016) [[sssd[krb5_child[1563]]]] [k5c_send_data]
(0x4000): Response sent.
> (Wed Nov 9 15:00:44 2016) [[sssd[krb5_child[1563]]]] [main] (0x0400):
krb5_child completed successfully
So I would suggest to look into the domain logs as well. Chances are
some other part (maybe the access control later?) is failing.
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org