[SSSD-users] renewal of krb5 tickets created outside SSSD
jhrozek at redhat.com
Thu Sep 26 10:05:05 UTC 2013
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:
> > > > Hi all,
> > > >
> > > > 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?
> > > >
> > > > The use case I have is for sessions started e.g. via sudo -u +
> > > > manual kinit or SSH PKI or SSH GSS-API (i.e. passwordless logins).
> > > > Those are sometimes long- running, but the tickets won't be renewed
> > > > automatically currently.
> > > >
> > > > If not currently possible, I was thinking of creating some simple
> > > > program that would call SSSD functions to "register" a specified
> > > > ccache path (krb5_save_ccname + add_tgt_to_renew_table?). Do you
> > > > see any problems with this approach? Would those functions be
> > > > somehow accessible from Python API?
> > >
> > > The SSSD team has been considering handling this for some time. The
> > > tickets tracking it are:
> > >
> > > https://fedorahosted.org/sssd/ticket/1497 (targeted for 1.13)
> > > and
> > > https://fedorahosted.org/sssd/ticket/1723 (currently deferred)
> > I think the use case is a bit different.
> > If you are using automated logins then it is better to have special user
> > and give him a keytab. You can then use a cron job to kinit periodically
> > using this keytab.
> Actually, it seems similar enough.
> 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 ?
> #1497 talks about desktops and dbus, but the part about enlisting SSSD to
> monitor credentials it didn't acquire seems like it would work for me (dbus
> itself should still be OK on servers, no?)
Sure, it's a system message bus, not tied to desktop.
> Should I add my usecase to the ticket?
> > Starting Kerberos 1.11 (F19, RHEL7) every GSSAPI connection would
> > automatically force underlaying kerberos library to reacquire ticket for
> > the user if it is not available so cron job can be just removed. Also we
> > recommend using GSS proxy (F19, RHEL7) in this case for the better
> > access control and privilege separation. https://fedorahosted.org/gss-proxy/
> That sounds fantastic, I can't wait :)
> Sorry, I should have specified, this is on servers with RHEL6 and Ubuntu
> I suppose the upcoming Kerberos changes would make the above tickets less
> relevant as then SSSD wouldn't even be renewing anything itself right?
> If that's the case I may just keep telling ppl to remember to use something
> like k5start/krenew for long running jobs in the meantime and push for OS
> upgrades when the time comes.
Please note that due to a large number of dependencies, GSSProxy is
probably never coming to RHEL-6.
More information about the sssd-users