[OpenAFS] Bogus ticket lifetimes on Windows client

[Evan Knop]

I'm having problems with the OpenAFS windows client and krb524d.  (I 
believe - I'm presuming this based on symptoms and the klog documentation).

If the max. lifetime for AFS tokens is less than 10:40, the results on 
linux and windows are the same.

If the max. lifetime is greater than 10:40 but less than about 15 hours, 
the Windows client gets progressively longer tickets (up to about 2-4 
weeks!), following the schedule described for the intervals in the AFS 
klog manpage.  The linux client, for the same token lifetimes, gets 
tokens of the correct length.

If the max. lifetime is greater than a certain amount (not sure exactly 
what - 24 hours is too much), then the Windows client will decide that 
its' tokens expire January 1, 1601.  The linux clients (through fakeka) 
continue to work fine.

My hypothesis is that the Windows client is speaking to the krb524d 
(750/udp) on running on the AFS hosts, and interpreting the kerberos-4 
response to this request as if it were a kaserver response (with the odd 
"scaling").  Linux is speaking to the fakeka (7004/udp), which is doing 
the scaling for the client, so the result comes back with the correct 
(or almost-correct) time on the other side.

Is there any way to indicate to the Windows client either:

1) it is speaking to a Kerberos-4 server, rather than a kaserver

or

2) to request a ticket no longer than a certain time (e.g. 10 hours)?

This occurs with both the 1.2.10 client and the 1.3.6400 client when 
using the "Integrated Login" option. (it is fixed by installing both the 
MIT Kerberos package and 1.3.6400, but "Integrated login" to our Samba-2 
(NT 4.0) realm still fails).  We're looking forward to rolling out 
Kerberos-5 to all these clients, but we're not quite ready to do that 
yet, and in the meantime, we'd like for our (extremely non-technical) 
users to still be able to access the AFS space we've been selling them 
on for the past three years.