9:15 a.m.
Alexey,
Thanks for responding. I checked /etc/krb5.conf.d/*. Good idea, but I
checked. No settings of krb5_ccname_template there.
Yes, in sssd.conf there is a krb5_ccname_template. But we don't set it.
In the sssd-krb5 man page, it says for thie parameter:
krb5_ccname_template (string)
Location of the user's credential cache. Three credential cache
types are currently supported: “FILE”, “DIR” and “KEYRING:persistent”. The
cache can be
specified either as TYPE:RESIDUAL, or as an absolute path, which
implies the “FILE” type. In the template, the following sequences are
substituted:
...
Default: (from libkrb5)
The way I interpret that statement about default, is that if not set, it
does whatever Kerberos libs are doing. Which is set in /etc/krb5.conf file
or /etc/krb5.conf.d/*.
That's why I thought it was so strange that when I set default_ccache_name
= FILE:/tmp/krb5cc_%{uid}
in /etc/kr5.conf, sssd still continued to store Kerberos creds in KEYRING.
We've worked around the problem by increasing *kernel.keys.maxkeys * to
1000. So at this point, it's just a curiosity question.
Thanks,
Spike
On Tue, Oct 20, 2020 at 3:27 AM Alexey Tikhonov <atikhono(a)redhat.com> wrote:
On Thu, Oct 15, 2020 at 9:57 PM Spike White <spikewhitetx(a)gmail.com>
wrote:
> Sssd experts,
>
>
> We have a problem with two RHEL7 servers, where one particular account is
> logged into a great many times, fairly frequently. Can be as much as 2-3
> concurrent sessions, but generally it’s just a bunch of sequential logins.
> All from that one account.
>
> We have just converted this user authentication to sssd (AD back-end)
> from a non-Kerberos-based user authentication.
>
> After an hour or so, the account can no longer log in. It reports an
> error from pam_sss.so.
>
> It says this in /var/log/secure:
>
>
>
> Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.186.154.11 user=svc_npesrsnonprd
>
> Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_sss(sshd:auth): received for
> user svc_npesrsnonprd: 4 (System error)
>
> Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.186.154.11 user=svc_npesrsnonprd
>
> Oct 15 13:53:36 esrmfgstg01 sshd[19125]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.186.154.11 user=svc_npesrsnonprd
>
> Oct 15 13:53:36 esrmfgstg01 sshd[19125]: pam_sss(sshd:auth): received for
> user svc_npesrsnonprd: 4 (System error)
>
>
>
> In /var/log/sssd/sssd_pam.log file we see:
>
>
>
> (Thu Oct 15 13:53:36 2020) [sssd[pam]] [pam_dp_process_reply] (0x0200):
> received: [4 (System error)][amer.dell.com]
>
>
>
> In /var/log/sssd/sssd_amer.dell.com.log, we see:
>
> (Thu Oct 15 13:53:36 2020) [sssd[be[amer.dell.com]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
>
> (Thu Oct 15 13:53:36 2020) [sssd[be[amer.dell.com]]] [krb5_auth_done]
> (0x0040): The krb5_child process returned an error. Please inspect the
> krb5_child.log file or the journal for more information
>
>
>
> And finally, in /var/log/sssd/krb5_child.log, we see:
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache]
> (0x4000): Initializing ccache of type [KEYRING]
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache]
> (0x4000): CC supports switch
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache]
> (0x4000): Match not found
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache]
> (0x4000): krb5_cc_cache_match failed
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache]
> (0x0020): 1016: [122][Disk quota exceeded]
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [map_krb5_error]
> (0x0020): 1817: [122][Disk quota exceeded]
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [k5c_send_data]
> (0x0200): Received error code 1432158209
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]]
> [pack_response_packet] (0x2000): response packet size: [4]
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [k5c_send_data]
> (0x4000): Response sent.
>
> (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [main] (0x0400):
> krb5_child completed successfully
>
>
>
> So we think the problem is that all the keyrings are consumed, or this
> user has exceeded its quota of keyrings. Faster than Kerberos garbage
> collects them.
>
> In googling, we see a similar problem but it’s specific to GNOME.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1230750
>
> Our problem does not involve GNOME, just raw SSH connections.
>
> We bumped up */proc/sys/kernel/keys/maxkeys *(from default of 200 to 1000) and it
>
> seemed to help. Just wondering what is the correct fix? And if this is the
correct
>
> fix, some guidance as to best value for maxkeys.
>
>
>
> BTW, even when we specify :
>
> default_ccache_name = FILE:/tmp/krb5cc_%{uid}
>
> in /etc/kr5.conf, sssd’s krb5_child.log seems to want to use KEYRING.
> What’s up
>
> with that?
>
Don't you have this option redefined in /etc/krb5.conf.d/* by any chance?
Or via `krb5_ccname_template` in sssd.conf?
>
>
> Spike
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...