[OpenAFS] Odd syncing behaviour AFTER upgrade

[R.Ries@tu-bs.de]

Hello

We observed this same behaviour a couple of months ago. I don't think we
could blame it on the new server modules from last weekend.

There are some decscription on how the passward verification stuff is used
in the Transarc Admin and Command Refer. Guides. They state that the max.
number of attempts divided by the number of kaservers is the local
maximum of each of the kaservers.

So as you observed, we too found that the windows client as opposed to the
unix client seems to ask only 1 kaserver. The result is as you described.

Though we can not prove it we think it was introduced with a newer Windows
Client. We observed this behaviour with W2K and WXP.

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

> 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  ***
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>


Mit freundl. Gruessen
Reinhard Ries

=========================================================================
Reinhard Ries                          email:      R.Ries@tu-bs.de
Rechenzentrum TU Braunschweig          Tel.:       0531/391 5531
Systembetreuung                        Fax:        0531/391 5549
Hans-Sommer-Str. 65
D - 38106 Braunschweig
=========================================================================