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
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
