[SSSD-users] renewal of krb5 tickets created outside SSSD

Stephen Gallagher sgallagh at redhat.com
Thu Sep 26 12:17:44 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2013 07:30 AM, Michael Gliwinski wrote:
> On Thursday 26 Sep 2013 12:05:05 Jakub Hrozek wrote:
>> On Thu, Sep 26, 2013 at 10:23:54AM +0100, Michael Gliwinski
>> wrote:
>>> On Wednesday 25 Sep 2013 13:59:31 Dmitri Pal wrote:
>>>> On 09/25/2013 09:41 AM, Stephen Gallagher wrote:
>>>>> On 09/25/2013 08:40 AM, Michael Gliwinski wrote:
>>>>>> Currently SSSD (when configured with
>>>>>> krb5_renew_interval, etc.) will only renew tickets it
>>>>>> itself created.  Is it possible to somehow tell it to
>>>>>> also look after some other ccaches?
> ...
>>> These aren't automated logins, for those I already use a keytab
>>> as you said and k5start to init/renew tickets automatically.
>>> 
>>> It's some of our users/admins/dbas, etc who log on to servers
>>> and run jobs that may take e.g. 2 days.
>> 
>> Would it help your use case to request renewable tickets and then
>> use SSSD's renewing as per krb5_renew_interval and
>> krb5_renewable_lifetime ?
> 
> That is already what I do.  However SSSD will not watch after
> tickets it hasn't initialised itself - e.g. ones obtained via
> manual kinit, or forwarded via ssh -K.  That's why I was looking
> for a way to "tell" SSSD "hey, here's a ccache /tmp/krb5cc_11111,
> look after it" :)
> 

Well, in terms of forwarded tickets, that would best be handled on the
originating machine. So if you got those creds initially using SSSD on
the client machine and it auto-renewed them there, that *should*
percolate down to the server you're connected to as well, IIRC[1].
Thus there should be no need to have the server managing them at all.

As for kinit, the obvious question is "Why?". What's the use case for
using kinit instead of logging in via SSSD or forwarding the tickets
with SSH? I'd like to understand the user experience before discussing
code changes.

[1] It's possible I'm getting confused with SSH key forwarding vs.
GSSAPI ticket delagation. I'd have to double-check that, but it should
be easy to test: acquire a TGT on the client machine, 'ssh -K' into a
server, run 'klist' on the server. Run 'kinit -R' on the client. Run
'klist' on the server again. If the server now has a different
expiration date, then the delegation propagates through.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJEJegACgkQeiVVYja6o6NpQgCdGbsfTFAJWfnpJ8Z0NQoKmlN3
UuoAn03FFHVYrCq6Q2p+BGYSqBczuNGV
=1YWc
-----END PGP SIGNATURE-----


More information about the sssd-users mailing list