[OpenAFS] Odd syncing behaviour AFTER upgrade

[Norman P. B. Joseph]

On Thu, 2004-01-15 at 13:02, Derrick J Brashear wrote:

> > > Make your users get their passwords right, or just disable the account
> > > locking.
> >
> > The account locking is a policy issue here that's not going away any
> > time soon.  But thanks for the suggestion.
> 
> 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.

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?

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?

> > In poking around there seems to be another issue at play.  The account
> > was getting locked because the user's password was no longer being
> > recognized (and in fewer than the 5 attempts we have configured on the
> > account).  On a hunch I asked how long his password was.  It was 11
> > characters.  I asked him to reset it to the 1st 8 characters, and after
> > he did he was able to get tokens again through the Windows client.
> >
> > I vaguely recall an issue years ago with passwords greater than 8
> > characters, but thought that was no longer the case.  Are AFS passwords
> > restricted to 8 characters?
> 
> They are not. The algorithm for >8 characters is different, and before
> that it used to be truncated by the software to 8 characters.

I believe you, but I'm still at a loss to explain the password behavior
from the Windows client described above.

> Including, I assume, the kaserver.

Yep.  All four.

> 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?

Thanks,
-- 
 Norman Joseph, Systems Engineer           joseph@ctcgsc.org      IC|XC
 Concurrent Technologies Corporation         814/269.2633         --+--
 Global Systems Center                                            NI|KA

  ***  Be kind, for everyone you meet is fighting a great battle  ***