Kerberos Ticket renewal within Samba AD Domain

[Michael Löffler]

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

[John Hodrien]

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

[Jakub Hrozek]

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

[Michael Löffler]

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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>

[Jakub Hrozek]

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.

[Michael Löffler]

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.

[Jakub Hrozek]

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.