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?
Yes please.
> 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
12.04.
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.