Question on renewable lifetime

[miguel.sanders@arcelormittal.com]

Hi Greg

Thanks for the feedback.
Much appreciated! 


Met vriendelijke groet
Best regards
Bien à vous

Miguel SANDERS
ArcelorMittal Gent

UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent

T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders at arcelormittal.com
www.arcelormittal.com/gent

-----Oorspronkelijk bericht-----
Van: Greg Hudson [mailto:ghudson at MIT.EDU] 
Verzonden: vrijdag 27 maart 2009 17:52
Aan: SANDERS Miguel
CC: kerberos at mit.edu
Onderwerp: Re: Question on renewable lifetime

I would personally stick with using a supplied keytab.

If you do switch to renewing tickets, be aware that renewal has to happen while the old tickets are still valid.  If your crontab ever misses a renewal, it will break until you kinit again by hand.

The theoretical advantage of renewal over a known password is that renewable tickets can be blacklisted if stolen.  But blacklisting is not implemented in the MIT KDC, so it's hard to realize this advantage.

On Thu, 2009-03-26 at 17:53 +0100, miguel.sanders at arcelormittal.com
wrote:
> I'm having a background process which requires a service principal to 
> work correctly.
> Currently, I'm having a cron job which does a kinit (with the keytab
> supplied) for that service principal.
> Wouldn't it be better to renew the ticket instead of doing the above?
> As a result, I would have to set the renewable lifetime for that 
> service principal to unlimited.



**** 
This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. 
If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. 
Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. 
This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.  
****