[krbdev.mit.edu #6430] If we fail to generate preauth, don't loop

[Greg Hudson via RT]

Sam, can you please comment on the practical ramifications of not
continuing after a PREAUTH_FAILED error?  (That is, reverting that
particular change which you made as part of the FAST work.)

The looping problem we are seeing in 1.7 is not simply that we are
failing to generate padata and continuing anyway (although that may be
happening against Microsoft KDCs).  We also don't have any mechanism to
remember and avoid previously used preauth mechanisms.  So, for
instance, against an MIT KDC modified to return PREAUTH_FAILED on
encrypted timestamp failure, the 1.7 client loops generating encrypted
timestamp padata.

This is a fine point, but I cannot actually find anything in the preauth
framework saying we should continue after PREAUTH_FAILED.  The text in
the opening of section 3 only applies to PREAUTH_FAILED errors resulting
from optimistic preauth, which we do not do.

This looping bug was masked on the trunk by the merge of Luke's S4U work
(r22736).  In that work, he introduced a change which results in the
client invoking krb5_do_preauth_tryagain after a PREAUTH_FAILED error,
which (as Sam notes) is wrong and effectively reverts Sam's change.  I
am thinking that the correct thing to do for 1.7.1 is to more cleanly
revert Sam's change and simply stop after a PREAUTH_FAILED error like we
did in 1.6.

Finally, I'll note that this bug interacts badly with account lockout
mechanisms.  Users authenticating with the 1.7 kinit against Microsoft
KDCs are currently getting locked out with just one wrong password, if
the lockout policy kicks in at 8 or fewer attempts.