|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
To: "Jeffrey I. Schiller" <jis@mit.edu> Cc: kerberos@Athena.MIT.EDU In-Reply-To: Your message of "Tue, 22 Sep 92 13:42:37 EDT." Date: Tue, 22 Sep 92 14:11:44 -0400 From: "Louis A. Mamakos" <louie@sayshell.umd.edu> > You are not being stupid. The problem doesn't happen in our > environment because it is almost universally the case that every > ticket expires at the same time as the TGT does. Hmm.. good. I think. Does it make sense for the ticket cache code to not return expired tickets? > Another question to ask is "Why does the zephyr.zephyr ticket > get issued with only an 8 hour life?" The short answer is that 8 hours seems to be the default lifetime as specified in mk_req.c, initialize by the manifest constant DEFAULT_TKT_LIFE. The 25 hour TGT is provided by AFS and its kerberos client library which apparently chooses a different default lifetime. I suppose that I can change the default lifetime in the kerberos libraries to match the AFS-generated TGT, but it seems to me that there is still a residual problem lurking out there. Or does kinit zap the entire ticket cache when a new TGT is acquired? If it doesn't, won't there still be expired service tickets lurking in the ticket cache? Looking at the V4 kinit.c code, it doesn't seem to zap the existing cache. Louis A. Mamakos University of Maryland, College Park
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |