Dear SSSD Users,
I have a question regarding the renewal of Kerberos tickets within a Samba AD. All servers and clients are running Ubuntu 16.04. We have a lot of Windows clients too; therefore we're using Samba. First of all, I'll summarize our setup:
- One server acts as the Samba AD Host (and Kerberos (integrated in Samba) principal) - One server acts as a file server; all directories (the users' home directories as well) are exported via kerberized NFS - The clients mount the directories; login auth is realized using sssd (with id_provider = ad, auth_provider = ad and access_provider = ad)
When a user logs in at a client, he gets a Kerberos ticket and is therefore granted access to his home directory. If he locks the screen and logs in again, the ticket is renewed. However, if the user keeps the client locked for a time greater than the ticket lifetime, the ticket expires and the user is not able to write to his home directory any more. That's a problem if the user is, for example, running a process which takes a long time (in our case mostly simulations which are usually run overnight). The same things happens if a user connects to a client via ssh. Then, the ticket is never renewed automatically.
Is it somehow possible to configure that sssd renews the krb5 ticket if the user has active processes running?
Regards Michael
On Wed, 18 Oct 2017, Michael Löffler wrote:
Dear SSSD Users,
I have a question regarding the renewal of Kerberos tickets within a Samba AD. All servers and clients are running Ubuntu 16.04. We have a lot of Windows clients too; therefore we're using Samba. First of all, I'll summarize our setup:
- One server acts as the Samba AD Host (and Kerberos (integrated in Samba)
principal)
- One server acts as a file server; all directories (the users' home
directories as well) are exported via kerberized NFS
- The clients mount the directories; login auth is realized using sssd (with
id_provider = ad, auth_provider = ad and access_provider = ad)
When a user logs in at a client, he gets a Kerberos ticket and is therefore granted access to his home directory. If he locks the screen and logs in again, the ticket is renewed. However, if the user keeps the client locked for a time greater than the ticket lifetime, the ticket expires and the user is not able to write to his home directory any more. That's a problem if the user is, for example, running a process which takes a long time (in our case mostly simulations which are usually run overnight). The same things happens if a user connects to a client via ssh. Then, the ticket is never renewed automatically.
I'd like to thin renewal would work with the ssh case, but you'll not get a new key set. GSSAPIRenewalForcesRekey can help if you've got a local machine that is getting used regularly but with remote connections out to other hosts via ssh.
Is it somehow possible to configure that sssd renews the krb5 ticket if the user has active processes running?
I think you need to be clearer about renewing and getting a new ticket. Kerberos tickets have a renewal lifetime, and SSSD can renew up to that lifetime. If you unlock the screensaver, you get a new ticket, not a renewal, and so the clock starts again.
If SSSD was able to request new certificates for a user, presumably it'd have to squirrel away a plaintext copy of the user's password, or the machine would have to granted additional rights to impersonate other users. Neither of those sound like particularly healthy options.
jh
On Wed, Oct 18, 2017 at 10:00:35AM +0200, Michael Löffler wrote:
Dear SSSD Users,
I have a question regarding the renewal of Kerberos tickets within a Samba AD. All servers and clients are running Ubuntu 16.04. We have a lot of Windows clients too; therefore we're using Samba. First of all, I'll summarize our setup:
- One server acts as the Samba AD Host (and Kerberos (integrated in Samba)
principal)
- One server acts as a file server; all directories (the users' home
directories as well) are exported via kerberized NFS
- The clients mount the directories; login auth is realized using sssd (with
id_provider = ad, auth_provider = ad and access_provider = ad)
When a user logs in at a client, he gets a Kerberos ticket and is therefore granted access to his home directory. If he locks the screen and logs in again, the ticket is renewed. However, if the user keeps the client locked for a time greater than the ticket lifetime, the ticket expires and the user is not able to write to his home directory any more. That's a problem if the user is, for example, running a process which takes a long time (in our case mostly simulations which are usually run overnight). The same things happens if a user connects to a client via ssh. Then, the ticket is never renewed automatically.
Is it somehow possible to configure that sssd renews the krb5 ticket if the user has active processes running?
Regards Michael
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
But please note that only tickets acquired through SSSD will be renewed this way. Tickets acquired through kinit or in other way won't -- that's why we are working on KCM and in particular https://pagure.io/SSSD/sssd/issue/1723
Hi,
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
After reading the manpage, I thought that this only affects auths via krb5 - however, our auth_provider is ad. Am I wrong here?
But please note that only tickets acquired through SSSD will be renewed this way.
Actually, I don't even know which service acquires the ticket. Is it always SSSD? Or is it pam or ssh?
I would appreciate it if you could help me here.
Regards Michael
On 18.10.2017 10:12, Jakub Hrozek wrote:
On Wed, Oct 18, 2017 at 10:00:35AM +0200, Michael Löffler wrote:
Dear SSSD Users,
I have a question regarding the renewal of Kerberos tickets within a Samba AD. All servers and clients are running Ubuntu 16.04. We have a lot of Windows clients too; therefore we're using Samba. First of all, I'll summarize our setup:
- One server acts as the Samba AD Host (and Kerberos (integrated in Samba)
principal)
- One server acts as a file server; all directories (the users' home
directories as well) are exported via kerberized NFS
- The clients mount the directories; login auth is realized using sssd (with
id_provider = ad, auth_provider = ad and access_provider = ad)
When a user logs in at a client, he gets a Kerberos ticket and is therefore granted access to his home directory. If he locks the screen and logs in again, the ticket is renewed. However, if the user keeps the client locked for a time greater than the ticket lifetime, the ticket expires and the user is not able to write to his home directory any more. That's a problem if the user is, for example, running a process which takes a long time (in our case mostly simulations which are usually run overnight). The same things happens if a user connects to a client via ssh. Then, the ticket is never renewed automatically.
Is it somehow possible to configure that sssd renews the krb5 ticket if the user has active processes running?
Regards Michael
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
But please note that only tickets acquired through SSSD will be renewed this way. Tickets acquired through kinit or in other way won't -- that's why we are working on KCM and in particular https://pagure.io/SSSD/sssd/issue/1723 _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Thu, Oct 19, 2017 at 11:40:39AM +0200, Michael Löffler wrote:
Hi,
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
After reading the manpage, I thought that this only affects auths via krb5 - however, our auth_provider is ad. Am I wrong here?
The ad provider is a AD-specific wrapper around the krb5 provider, so it can be tuned with the krb5_* options.
But please note that only tickets acquired through SSSD will be renewed this way.
Actually, I don't even know which service acquires the ticket. Is it always SSSD? Or is it pam or ssh?
How do you log in to the machine? Via ssh with a password, ssh with GSSAPI, GDM..?
Typically, the login methods that include a PAM authentication (GDM, su, ssh with password, ...) would contact sssd through the pam_sss module.
Thanks for your answers!
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
After reading the manpage, I thought that this only affects auths via krb5 - however, our auth_provider is ad. Am I wrong here?
The ad provider is a AD-specific wrapper around the krb5 provider, so it can be tuned with the krb5_* options.
I'll test it now with the following options specified in sssd.conf (after restarting sssd service): id_provider = ad auth_provider = ad ldap_id_mapping = false access_provider = ad enumerate = false krb5_renewable_lifetime = 10h krb5_renew_interval = 1h
However, I have my doubts: in a testcase, I also specified "krb5_lifetime = 5m". However, when I log in and list my krb5 tickets using klist, the expiration time still is the time specified by the Samba server. Is this normal behavior or am I overlooking something?
But please note that only tickets acquired through SSSD will be renewed this way.
Actually, I don't even know which service acquires the ticket. Is it always SSSD? Or is it pam or ssh?
How do you log in to the machine? Via ssh with a password, ssh with GSSAPI, GDM..?
Typically, the login methods that include a PAM authentication (GDM, su, ssh with password, ...) would contact sssd through the pam_sss module.
I/we log in via ssh with password at or lightdm, respectively.
On Thu, Oct 19, 2017 at 01:01:18PM +0200, Michael Löffler wrote:
Thanks for your answers!
Yes, please check man sssd-krb5 and the option that include 'renew' in their name, e.g. "krb5_renewable_lifetime".
After reading the manpage, I thought that this only affects auths via krb5 - however, our auth_provider is ad. Am I wrong here?
The ad provider is a AD-specific wrapper around the krb5 provider, so it can be tuned with the krb5_* options.
I'll test it now with the following options specified in sssd.conf (after restarting sssd service): id_provider = ad auth_provider = ad ldap_id_mapping = false access_provider = ad enumerate = false krb5_renewable_lifetime = 10h krb5_renew_interval = 1h
However, I have my doubts: in a testcase, I also specified "krb5_lifetime = 5m". However, when I log in and list my krb5 tickets using klist, the expiration time still is the time specified by the Samba server. Is this normal behavior or am I overlooking something?
No, I don't think so, and I just tested this setup in my test environment and it works fine.
btw do you see a message such as this one: (Sat Oct 21 19:34:30 2017) [[sssd[krb5_child[13199]]]] [set_lifetime_options] (0x0100): Lifetime is set to [5m] in the krb5_child.log on your client system?
But please note that only tickets acquired through SSSD will be renewed this way.
Actually, I don't even know which service acquires the ticket. Is it always SSSD? Or is it pam or ssh?
How do you log in to the machine? Via ssh with a password, ssh with GSSAPI, GDM..?
Typically, the login methods that include a PAM authentication (GDM, su, ssh with password, ...) would contact sssd through the pam_sss module.
I/we log in via ssh with password at or lightdm, respectively.
Both should reach sssd through the PAM interface.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Michael Löffler