[OpenAFS] Bogus ticket lifetimes on Windows client
Wed, 16 Jun 2004 14:55:34 -0400
We also encountered this problem with the Windows client and the ticket
expiration dates (we have our lifetimes set to 30 days). Some clients showed
the 1601 expiration date and others showed a different, incorrect expiration
date (I forget exactly what it was).
The solution for us was to upgrade our Kerberos server binaries to 1.3.3
(compiled straight from the MIT source). The problem then went away. We were
previously using the kerberos rpms which came with Redhat 7.3
On Wed, Jun 16, 2004 at 11:40:57AM -0400, Evan Knop wrote:
> 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
> 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
David William Botsch
CCMR Computing Facility