7:40 a.m.
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?
Thanks,
Michael
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is
intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject
to the terms and conditions expressed in the governing client engagement leter or
contract.
If you have received this email in error please notify support(a)henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
8:41 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJC6BkACgkQeiVVYja6o6PmkgCfZOmpQxu5nJCyBDCA9byKQ9AJ
WuMAnjvbsERLps3zJyzg7UGL8kiG675a
=AtmX
-----END PGP SIGNATURE-----
12:59 p.m.
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.
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/
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
4:23 a.m.
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.
#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?)
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
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.
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is
intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject
to the terms and conditions expressed in the governing client engagement leter or
contract.
If you have received this email in error please notify support(a)henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
5:05 a.m.
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.
6:30 a.m.
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" :)
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is
intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject
to the terms and conditions expressed in the governing client engagement leter or
contract.
If you have received this email in error please notify support(a)henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
7:17 a.m.
-----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-----
8:12 a.m.
On Thursday 26 Sep 2013 08:17:44 Stephen Gallagher wrote:
[...]
>>> 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.
Yes, that would be ideal but I'm afraid it doesn't work like that. I just
verified this twice to be sure :)
It looks like it will someday work like that when using gss-proxy (if/when it
implements credentials access forwarding).
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.
Yeah, I was asking that question too, and narrowed it down to two cases.
The major one is ppl logging in via SSH PKI (with keys). Switching to
password auth not so good as then you get a password prompt for each session.
Switching to GSSAPI not always feasible, e.g. a bunch of users are
Windows+cygwin, where, I'm not sure if this can even be done, etc.
The other case is `sudo -u` , but this is minor and could just use su for that
case.
In general though, it would just be a more seamless experience, if SSSD could
manage your credentials however they were acquired.
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is
intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject
to the terms and conditions expressed in the governing client engagement leter or
contract.
If you have received this email in error please notify support(a)henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
3863
days inactive
3864
days old
sssd-users@lists.fedorahosted.org
7 comments
4 participants
participants (4)
-
Dmitri Pal -
Jakub Hrozek -
Michael Gliwinski -
Stephen Gallagher