[OpenAFS] Odd syncing behaviour AFTER upgrade

[Derrick J Brashear]

On Thu, 15 Jan 2004, Norman P. B. Joseph wrote:

> > Then (assuming no other issues) you get to suck it up.
>
> Lucky me.  :^)  Really, this hasn't been an issue before.  I'm just
> trying to understand why its showing up for an unusual number of Windows
> users yesterday and today.

Understood.

> And I've found out some more information.  It seems from sniffing
> traffic that a *nix client, when given a bad password, will query all 3
> kaservers before returning an error, but a Windows client apparently
> only asks one kaserver before returning an error.  Could this be, in
> part, why I'm having such issues with Windows users now, if they happen
> to ask the "wrong" kaserver?

Windows uses Kerberos 4; it could be client behavior that it just tries
the first thing in its list. It's not the same code.

> Also, on an account set with a large number (10) of authentication
> attempts, from a *nix client you have to enter at least that many bad
> passwords before the account locks, but from a Windows client you only
> have to enter 3 bad passwords before the account locks, regardless of
> what the -attempts flag is set to.  Is this really hard-coded into the
> Windows client, as it seems to be?

Do you see more than one request packet for each attempt, to the same
server?

> > I'm unsure why the truncation behavior
> > would have changed due to a db server change. However, did you notice how
> > old the user's password was before fixing it?
>
> Yes.  It had been changed just yesterday.  They were having the same
> problem then, and another admin had them go through the password
> resetting dance yesterday.  I do have another user in this situation
> whose password is two weeks old, but they are out until tomorrow.  If
> any more should surface today what should I be looking for in the age of
> the password?

Well, I was thinking "years old".