[32638] in Kerberos
Re: ticket renew lifetime limited by Windows KDC policy
daemon@ATHENA.MIT.EDU (Di Pe)
Mon Sep 6 15:04:03 2010
MIME-Version: 1.0
In-Reply-To: <87iq2puq1l.fsf@windlord.stanford.edu>
Date: Mon, 6 Sep 2010 12:03:55 -0700
Message-ID: <AANLkTi=fq-HUdgD2hYA4Wz5fmrKfB-tcyMGWB4H01b+m@mail.gmail.com>
From: Di Pe <dipeit@gmail.com>
To: Russ Allbery <rra@stanford.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Thanks Russ,
some more comments/questions below
On Wed, Sep 1, 2010 at 2:12 PM, Russ Allbery <rra@stanford.edu> wrote:
> Di Pe <dipeit@gmail.com> writes:
>
> Have you considered using some other mechanism to ensure that users
> reauthenticate periodically? For instance, if you're using bash, you
> could configure it to run kinit (or, possibly better, k5start -H) every
> once in a while by (ab)using the prompt setting.
>
This seems to be a good idea. I used
export PROMPT_COMMAND="k5start -H 500"
and it does what it's supposed to do.
One issue tough: k5start seems to look at ticket_lifetime instead of
renew_liefetime. ticket_lifetime is enforced to 10 hours by active
directory. If I don't use a cron job to renew the ticket users would
have to enter their credentials every few hours or so which is not
good if they run jobs over night.
If I use a cron job to renew the ticket I would not be prompted for
7days but if renew_lifetime ran out on a saturday I would only have
another few hours to refresh the ticket.
Another problem we notice on our terminal server is that user sessions
are completely locking up when a ticket expires on a nfs mounted home
directory. It would be good if we had a cron job that forces a logout
for users where the ticket is about to expire in 60 minutes or less.
Is there a way to check for a happy ticket in a shell script without
getting a prompt if the ticket is not happy?
dipe
>> What would be a better Kerberos setup? pam_winbind instead of pam_krb5?
>> Other tools that can refresh/replace the TGT instead of renewing it?
>> These tools would have to store the user's password in memory, wouldn't
>> they?
>
> Yes. You either need to allow tickets to be renewable for longer or you
> have to get the user to enter their password occasionally. There aren't
> any other alternatives, really.
>
> Note, however, that if you use the newest version of the GSSAPI patch for
> ssh, any users who are logged on via ssh with a new client will have their
> tickets automatically reforwarded to all the systems to which they're
> logged on and hence refreshed on those systems. If you have relatively
> sophisticated users, this is a very nice feature.
We have started using this feature and it will be a great replacement
for ssh keys because sys admins cannot enforce a password policy with
SSH keys.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
