Kerberos User Stats never get updated

[Ken Raeburn]

On Jun 16, 2009, at 08:18, Simo Sorce wrote:
> 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.

That would require the KDC/database interface to be a bit smarter than  
it is now. :-)
Currently, it's pretty much, "here's the new record".

> 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 could also be designed differently so the data don't conflict --  
say, assigning each KDC a UUID and maintaining {KDC-UUID, fail-count}  
pairs in the database for each principal, or sets of {KDC-UUID, fail- 
date} pairs and counting the records.  (The latter more easily allows  
for a policy like, "lock out an account with X failures in the past N  
hours".)

Depending on the strictness of local security policies, it may be  
important to get accurate counts and not permit an attacker more than  
the designated number of chances, though the latter is trickier to do  
with only loose synchronization.

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium