KRBCONF_KDC_MODIFIES_KDB

[Kevin Coffman]

> Darren Reed
>
> >From John Hascall
> > It's not really a locking issue.  If all the appropriate 
> > options are turned on, the code enforces a 
> > five-strikes-and-you-are-out policy.
> > If you have 3 KDCs, you can get 15 tries at each principal 
> > because each will give you 5.  Or with N slaves I think you 
> > can get (N * 5) attempts per replication period (attack the 
> > slaves and then the master will overwrite them and you can do 
> > it again).
> > 
> > This is a minor concern.
> > 
> > In any event, I think it is fairly common for big sites to do 
> > some sort of 'near realtime' incremental replication rather 
> > than the bulk kprop thingy.
> 
> And I suppose a more pertinent question is if you're using the
> U. of Michigan patches for replication, should you expect 5 tries,
> 15 or somewhere inbetween or perhaps a corrupt/inconsistant db?

I think the correct answer is that with careful attempts you could
get 35 attempts with three replicas before being completely locked
out.  I came up with this by assuming you get 5 attempts against
each of the two slaves before being locked out.  Then one attempt
against the master.  The entry on the master now gets replicated
to the slaves and they all are at one failed attempted.  Now you
get 4 shots at each slave and one against the master.  Then, 3 on
the slaves, etc.

Eventually, the master marks the entry as locked and that is replicated
to all the slaves and the game is over.

I don't think the DB should be corrupt or inconsistent, but if the
client is choosing a KDC at random it may appear that things are
inconsistent (one slave KDC has the user locked out, another does not).

M$ doesn't have this same behavour because they have multi-master
replication.

K.C.