Kerberos User Stats never get updated

[Simo Sorce]

On Tue, 2009-06-16 at 08:40 -0400, Ken Raeburn wrote:
> 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".

Yeah, I know, and that's a problem for other things as well :-/
For example "unrolling" krbExtraData into individual attributes would be
a *huge* win for people that want to manage principals via normal ldap
operations.

What would be needed is to move the DAL a layer above, and not have it
be a simple DB style interface. The backends would get requests that
explicitly tell what information need to be changed, not just a new
"blob" to store. Then each backend can decide on its own what is the
best strategy to update data. The DB backend would probably just inherit
the current code above the DAL layer and perform dumb updates, the LDAP
driver could use a better schema for attributes the DB backend store in
ExtraData and also perform operations against specific attributes more
effciently. (No need to fetch the entry and perform compares to find out
what really changed).

> > 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".)

Yes the second might be a good idea, as it would also serve a bit as
auditing data. But then you may need a thread that periodically cleans
up the multi-value attribute. Although you can also decide to remove old
values only when you are going to add new values and the number of
values is past a certain threshold.
This will require a new attribute though, because the current
krbLastFAiledAuth is a generalizedTime and krbLoginFailedCount is an
Integer, and both are single-value, so neither can hold this
information.

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

Yes a "brain split" installation where the LDAP servers currently do not
communicate (and therefore can't replicate) could allow you to
double/triple/etc.. the number of attacks, but at least with the process
you described above you'd get an "audit trail" of what happened.
For people that decide to use a multi-master approach that's probably
going to be enough. If someone is more paranoid then they probably can
point all KDCs at one server only so that replication issues cannot
affect the count. Just a matter of choice and balance of
performance/availability vs a minor policy issue.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York