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.
_______________________________________________
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info
