Ken, I'm not sure that your interpretation of this code snippet is correct:
> until = (request->till == 0) ? kdc_infinity : request->till; > enc_tkt_reply.times.endtime = > min(until, min(enc_tkt_reply.times.starttime + server.max_life, > min(enc_tkt_reply.times.starttime + max_life_for_realm, > header_ticket->enc_part2->times.endtime))); The line immediately above what you've quoted is: enc_tkt_reply.times.starttime = kdc_time; (in other words, "now"; kdc_time is gotten from krb5_timeofday earlier in the function). > So the service ticket end time is technically the minimum of: > > - Requested lifetime > - TGT start time plus service principal maximum lifetime (server.max_life) > - TGT start time plus maximum realm lifetime > - TGT end time I think it's the minimum of: - Requested lifetime - "now" plus service principal maximum lifetime (server.max_life) - "now" plus maximum realm lifetime - TGT end time which, I think, is the correct value. If you're actually seeing the behavior you describe, then it's not the above code snippet that's causing it. I also know for a 100% certainty that getting new service tickets while a TGT was still valid used to work in the DCE code, which was based on an early MIT krb5 drop. (The default DCE service ticket lifetime was 2 hours, and default TGT lifetime was much longer.) So if it doesn't work in recent MIT versions, either it was fixed in DCE and didn't get propagated back to MIT (which, unfortunately, happened on occasion) or it got broken in the MIT code since the early 1.1 beta days. I admit that I haven't done a test to verify this with a recent MIT drop, since I've set up 24-hour lifetimes for both TGTs and service tickets in my local testing config. -- Ben ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
