kcm, gssproxy and klist

[Winberg Adam]

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

[Justin Stephenson]

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(a)smhi.se&gt; 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(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/[e-mail]...
>

[Winberg Adam]

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(a)redhat.com&gt;
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
<[e-mail]<mailto:[e-mail]>> 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 --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
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/[e-mail]...

[Winberg Adam]

>  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(a)smhi.se <externaly-forwarded(a)smhi.se&gt; on behalf of Winberg
Adam <Adam.Winberg(a)smhi.se&gt;
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(a)redhat.com&gt;
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
<[e-mail]<mailto:[e-mail]>> 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 --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
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/[e-mail]...

[John Devitofranceschi]

 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(a)smhi.se&gt; 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(a)smhi.se <externaly-forwarded(a)smhi.se&gt; on behalf of Winberg
Adam <Adam.Winberg(a)smhi.se&gt;
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(a)redhat.com&gt;
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(a)smhi.se&gt; 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(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/[e-mail]...

_______________________________________________
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/[e-mail]...

[John Devitofranceschi]

    On Thursday, December 16, 2021, 07:49:05 AM EST, John Devitofranceschi
<jdvf(a)yahoo.com&gt; 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(a)smhi.se&gt; 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(a)smhi.se <externaly-forwarded(a)smhi.se&gt; on behalf of Winberg
Adam <Adam.Winberg(a)smhi.se&gt;
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(a)redhat.com&gt;
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(a)smhi.se&gt; 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(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/[e-mail]...

_______________________________________________
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/[e-mail]...