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