On Wed, Dec 03, 2014 at 10:58:08AM -0500, Dmitri Pal wrote:
On 12/03/2014 07:37 AM, Joschi Brauchle wrote:
>On 12/03/2014 01:34 PM, Jakub Hrozek wrote:
>>On Wed, Dec 03, 2014 at 12:03:16PM +0100, Joschi Brauchle wrote:
>>>On 12/02/2014 04:45 PM, Jakub Hrozek wrote:
>>>>On Mon, Dec 01, 2014 at 05:43:49PM +0100, Joschi Brauchle wrote:
>>>>>Hello Everyone,
>>>>>
>>>>>there seems to be a problem with the KRB TGT auto-renewal feature
>>>>>of SSSD in
>>>>>version 1.12.2.
>>>>>
>>>>>I have this config in sssd.conf:
>>>>>-----------------------------
>>>>>krb5_renew_interval = 60
>>>>>-----------------------------
>>>>>We are using the AD plugin, the KRB plugin is not installed but
>>>>>krb-common
>>>>>(i.e. krb5_child, ldap_child, libsss_krb5_common.so).
>>>>>
>>>>>#Everything works fine, except auto-renewal!
>>>>>
>>>>>See the following example:
>>>>>-----------------------------
>>>>>$ kinit -l 10m
>>>>>Password for ne96soh(a)ADS.MWN.DE:
>>>>
>>>>Does the renewal work if you acquire the ticket via SSSD login instead
>>>>of kinit? Can you test logging in with some PAM service (gdm, su, ...)
>>>
>>>Hello Jakub,
>>>
>>>thanks for the hint. I can confirm that auto-renew works when
>>>1) using graphical login (i.e. SSSD acquired the ticket)
>>>2) reasonably long lifetime (tested w/ 2h) and renewal time (tested w/
>>>10m).
>>>
>>>I did have problems when getting the ticket with kinit and short
>>>life-/renewal times, as reported originally.
>>
>>I think this is kindof expectd unless you use a ticket name that is
>>predictable (ie no XXXXX components in a FILE:/ ccache) because then
>>SSSD has no idea which ccache to renew..
>
>
>Hm, but in my case I was using keyring or dir based caches/collections,
>e.g. for the keyring I am sure that the initial cache name (created by
>sssd) was not changed with the invocation of 'kinit -l lifetime'. Still,
>sssd did not renew the ticket with the modified lifetime (but same cache
>name)...
AFAIK SSSD does not monitor tickets. It takes a note when it saves a ticket.
So if the ticket was changed out of band it does not know.
What you are looking for a is a ticket monitor functionality that is
currently not there. I think we designed it but never got to implementing it
due to complexity.
Yes, pretty much. So sssd internally keeps a table where it stores the
ccaches and their expiration time. When the expiration time is getting
close, sssd starts the authentication subprocess (krb5_child) and renews
the ticket.
Entries to the table are either added on authentication via SSSD but
also when SSSD starts up and checks all the saved ccaches in the
user entries in the database. If predictable ccache names are used inthe
database (you can check with ldbsearch) then I guess SSSD could add the
ticket to the to-be-renewed-table but to be honest I have never tested
that.
Plain kinit has no means of telling sssd to keep an eye on ticket it
generates.