Sumit - Thanks for the info. Some of our users do work directly at the
workstation, so I'm glad to hear that they would get a fresh Kerberos
ticket, when they would have to login via the screen saver, on a daily
basis.. However, some of these same users, ssh to other workstations,
to run jobs on multiple workstations, and may stayed logged in, past the
SSSD lifetime limit. I'm curious if there is a way to warn such
people, when their Kerberos tickets are about to expire. I.e., to
automatically create job when they login, that checks the age of their
kerberos ticket on a daily basis. We will have to look at this issue
more closely. Thanks! - Mark
On 9/4/2017 3:58 AM, Sumit Bose wrote:
On Fri, Sep 01, 2017 at 04:53:03PM -0400, Mark London wrote:
Lukos - Thanks for responding. You stated that the krb5 ticket is
"renewed" after each authentication. What are all the methods
"authentication"? I.e. when a user logs in using SSSD, that authenticates
against Kerberos, (in our case, that is a Windows server), the person gets a
Kerberos ticket. But if the person stays logged in for many weeks, without
logging out, it sounds like that the automatic renewal will eventually
stop, after the number of days specified by the SSSD krb5_lifetime setting.
Please note that when unlocking the screen saver/lock SSSD will
authenticate the user again against the DC and request a fresh Kerberos
ticket. So as long as the users work on a regular basis on the
workstations and use a screen saver they should get a fresh Kerberos
ticket early enough.
HTH
bye,
Sumit
After which point, the user will need to either using kinit, or log out and
log back in, in order to get a new ticket. Is that correct?
If so, this will create a problem for our users. We presently are running
Linux (fedora and redhat) on many workstations, and using SSSD to
authenticate logins via LDAP from our Windows Active Directory server. We
have a linux NFS file server, that is serving a /home disk, which contains
everybody's home directory. Itis presently mounted without any
authentication via an entry in /etc/fstab, on each workstation. For
security reasons, weare interested in trying to configure the /home disk to
be mounted using Kerberos authentication. I have read that his will
require users to have a Kerberos ticket, in order to access their directory
that is on the /home NFS mounted disk.
SSSD can be configured to authenticate using Kerberos, thus automatically
creating a ticket, when the person logs in. But if the person stays
logged in for longer than krb5_lifetime, it would seem to me, that this
means that access to the /home disk will fail. Is that so? What if a
user is running a job that is accessing /home, and the ticket expires and
can no longer be renewed by SSSD, because it has reached the life limit?
That job will fail, won't it? I'm trying to verify if this is the case.
Thanks! - Mark
On 9/1/2017 3:52 PM, Lukas Slebodnik wrote:
On (01/09/17 12:01), Mark London wrote:
On 9/1/2017 10:30 AM, John Hodrien wrot
On Fri, 1 Sep 2017, Michal Židek wrote:
See man sssd-krb5 and option:
krb5_renew_interval
Is this what you are looking for? Look for other options
in that man page too, maybe you will need some of them.
If this is against a typical AD installation, that'll get you automatic
certificate renewals for up to 7 days.
But we have people logged into linux workstations for months at a time.
What happens to their connection to their home directory, when their 7 day
period ends? - Mark
krb5 ticket is "renewed" after each authentication. If user does not
authenticate very often then krb5_renew_interval will help.
But usually, krb5 ticket cannot be renewed to infinity.
(equivalent to "kinit -R") due to krb5 server side limits/setting.
I do not know details about your deployment so it is difficult to answer.
LS
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
