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@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 *********************************************************************************
-----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)
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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@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 *********************************************************************************
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.
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@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 *********************************************************************************
-----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.
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@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 *********************************************************************************
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Michael Gliwinski -
Stephen Gallagher