Kerberos User Stats never get updated
Simo Sorce
ssorce at redhat.com
Tue Jun 16 08:18:05 EDT 2009
On Tue, 2009-06-16 at 07:56 -0400, Ken Raeburn wrote:
> (two KDCs could try incrementing the failed-
> attempt counter simultaneously by both reading the old value at the
> same time, and then both writing the incremented value, causing one
> increment to be lost).
This could be detected and fixed easily, all you'd have to do is combine
a delete and add operation in a single modify where the exact value
retrieved is deleted and the incremented value added. If a race
condition occur, one of the KDCs would see the operation fail as it
would try to delete with a wrong value. The operation could then be
repeated, for a max of 3-5 times or so, and only then the KDC would give
up, maybe logging the issue in the log file.
In a multi-master case, this technique wouldn't work as both changes
against 2 masters would succeed, so in that case an increment would be
lost when later the replication conflict resolution will discard one of
the 2 changes (in theory special code in the replication code could be
written with understanding of how this specific attribute operate and
increments could be summed up, but it would probably be a lot of spcial
code for not much gain). This seem an issue only wrt failure counts,
however if they are low enough, this shouldn't be a big concern.
It seem very unlikely that under normal circumstances 2 KDCs will get a
preauth request for the same principal. Someone could time them
appropriately to multiply the number of chances to guess a password by
the number of KDCs, but the timing would be pretty hard to achieve I
guess, and not much would be gained.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Kerberos
mailing list