You can read more about this in the following BZ, but this should not
prevent a user from acquiring new credentials.

https://bugzilla.redhat.com/show_bug.cgi?id=1669607

If you are hitting a KCM quota, a failure message will be logged stating
the affected quota in the sssd_kcm.log file. I suspect it is not
'max_uid_ccaches' as this is the total number of unique credentials caches
per user, perhaps 'max_ccache_size' is the one being triggered.

Thanks,
-Justin


On Mon, Nov 23, 2020 at 6:46 AM Winberg Adam <[email protected]> wrote:

> With KCM and gssproxy we often see a long list of credentials when doing
> a 'klist':
>
>
>
> [user.u@lxserv2114 ~]$ klist
> Ticket cache: KCM:17098:66803
> Default principal: user.u@AD
>
> Valid starting       Expires              Service principal
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> 01/01/1970 00:00:00  01/01/1970 00:00:00
> Encrypted/Credentials/v1@X-GSSPROXY:
> and so on...
>
> The actual gssproxy credentials at /var/lib/gssproxy/clients/ does not
> correspond with this output, it only contains what could be expected - a
> TGT and maybe some service tickets.
>
>
> The ever growing 'klist' list of credentials is a problem, after a while
> the user can no longer get any new credentials and therefore has no access
> to its NFS homedir (sec=krb5). I'm guessing it's the 'max_uid_ccaches'
> option in sssd-kcm that prevents this.
>
>
> What is going on here - have we configured gssproxy/kcm wrong or is this a
> bug?
>
>
> Regards
>
> Adam
>
>
>
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
>
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]

Reply via email to