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
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 Adam.Winberg@smhi.se 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
There are no error log messages in the kcm log file at all, only
[sssd[kcm]] [orderly_shutdown] (0x0010): SIGTERM: killing children
I have not set a '[kcm]' entry in my sssd.conf, whats the default loglevel? Should at least log errors I guess.
The bugzilla is for Fedora, I cloned it for RHEL8 and described my use case there:
https://bugzilla.redhat.com/show_bug.cgi?id=1900973
//Adam
________________________________ From: Justin Stephenson jstephen@redhat.com Sent: 23 November 2020 22:47 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist
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 <Adam.Winberg@smhi.semailto:Adam.Winberg@smhi.se> 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 -- sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.orgmailto:sssd-users-leave@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.fedorahosted.o...
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.
I set 'debug_level' to 8 and did a bunch of logins/logouts. Every login creates a new cred cache, and after a while I no longer get a new credential on login. Error message:
(2020-11-24 6:54:17): [kcm] [kcm_op_set_default_done] (0x0040): Cannot set default ccache 1432158287: The maximum number of stored secrets has been reached
So it is indeed 'max_uid_ccaches' thats the culprit, if I increase it the error goes away and I once again get new credentials on login. But since they are never removed this is not a solution, only delaying the inevitable error.
//Adam
________________________________ From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 24 November 2020 07:36 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist
There are no error log messages in the kcm log file at all, only
[sssd[kcm]] [orderly_shutdown] (0x0010): SIGTERM: killing children
I have not set a '[kcm]' entry in my sssd.conf, whats the default loglevel? Should at least log errors I guess.
The bugzilla is for Fedora, I cloned it for RHEL8 and described my use case there:
https://bugzilla.redhat.com/show_bug.cgi?id=1900973
//Adam
________________________________ From: Justin Stephenson jstephen@redhat.com Sent: 23 November 2020 22:47 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist
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 <Adam.Winberg@smhi.semailto:Adam.Winberg@smhi.se> 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 -- sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.orgmailto:sssd-users-leave@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.fedorahosted.o...
In a related question, why do some GSSAPI clients (e.g., curl) add lines like: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
(what are these "tickets" called, anyway? "GSSPROXY ticket refs"?) and others do not (like, ssh, ldapsearch, and secure NFS access)? In our environment, every invocation of "curl --negotiate -u : ..." adds a new GTR to the user's ccache. Is this common?
jd On Tuesday, November 24, 2020, 01:57:44 AM EST, Winberg Adam adam.winberg@smhi.se wrote:
<!--#yiv1602887118 P {margin-top:0;margin-bottom:0;}-->
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.
I set 'debug_level' to 8 and did a bunch of logins/logouts. Every login creates a new cred cache, and after a while I no longer get a new credential on login. Error message:
(2020-11-24 6:54:17): [kcm] [kcm_op_set_default_done] (0x0040): Cannot set default ccache 1432158287: The maximum number of stored secrets has been reached
So it is indeed 'max_uid_ccaches' thats the culprit, if I increase it the error goes away and I once again get new credentials on login. But since they are never removed this is not a solution, only delaying the inevitable error. //Adam
From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 24 November 2020 07:36 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist There are no error log messages in the kcm log file at all, only
[sssd[kcm]] [orderly_shutdown] (0x0010): SIGTERM: killing children
I have not set a '[kcm]' entry in my sssd.conf, whats the default loglevel? Should at least log errors I guess.
The bugzilla is for Fedora, I cloned it for RHEL8 and described my use case there:
https://bugzilla.redhat.com/show_bug.cgi?id=1900973
//Adam
From: Justin Stephenson jstephen@redhat.com Sent: 23 November 2020 22:47 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist 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 Adam.Winberg@smhi.se wrote:
With KCM and gssproxy we often see a long list of credentials when doing a 'klist':
[user.u@lxserv2114 ~]$ klistTicket cache: KCM:17098:66803Default principal: user.u@AD Valid starting Expires Service principal01/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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
On Thursday, December 16, 2021, 07:49:05 AM EST, John Devitofranceschi jdvf@yahoo.com wrote:
In a related question, why do some GSSAPI clients (e.g., curl) add lines like: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
(what are these "tickets" called, anyway? "GSSPROXY ticket refs"?) and others do not (like, ssh, ldapsearch, and secure NFS access)? In our environment, every invocation of "curl --negotiate -u : ..." adds a new GTR to the user's ccache. Is this common?
jd On Tuesday, November 24, 2020, 01:57:44 AM EST, Winberg Adam adam.winberg@smhi.se wrote:
<!--#yiv5452918463 P {margin-top:0;margin-bottom:0;}-->
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.
I set 'debug_level' to 8 and did a bunch of logins/logouts. Every login creates a new cred cache, and after a while I no longer get a new credential on login. Error message:
(2020-11-24 6:54:17): [kcm] [kcm_op_set_default_done] (0x0040): Cannot set default ccache 1432158287: The maximum number of stored secrets has been reached
So it is indeed 'max_uid_ccaches' thats the culprit, if I increase it the error goes away and I once again get new credentials on login. But since they are never removed this is not a solution, only delaying the inevitable error. //Adam
From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 24 November 2020 07:36 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist There are no error log messages in the kcm log file at all, only
[sssd[kcm]] [orderly_shutdown] (0x0010): SIGTERM: killing children
I have not set a '[kcm]' entry in my sssd.conf, whats the default loglevel? Should at least log errors I guess.
The bugzilla is for Fedora, I cloned it for RHEL8 and described my use case there:
https://bugzilla.redhat.com/show_bug.cgi?id=1900973
//Adam
From: Justin Stephenson jstephen@redhat.com Sent: 23 November 2020 22:47 To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: kcm, gssproxy and klist 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 Adam.Winberg@smhi.se wrote:
With KCM and gssproxy we often see a long list of credentials when doing a 'klist':
[user.u@lxserv2114 ~]$ klistTicket cache: KCM:17098:66803Default principal: user.u@AD Valid starting Expires Service principal01/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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
sssd-users@lists.fedorahosted.org