Darren Reed (OSE)
darrenr at optimation.com.au
Thu Jan 15 15:40:03 EST 2004
>From John Hascall
> > > Wachdorf,> I know that the define
> KRBCONF_KDC_MODIFIES_KDB can be
> > > Wachdorf,> used to blacklist users by writing to the kdb every
> > > Wachdorf,> time a user enters an incorrect password.
> The comments
> > > Wachdorf,> in the code indicate that this cannot be used with
> > > Wachdorf,> replication. Why is that the case?
> > > Well, our KDC will not replicate the information very
> effectively so
> > > you get more tries than you strictly should.
> > Is there a problem beyond that due to locking? If I were
> to replicate
> > a large amount of users, would the db be locked that whole time?
> > Would this lock out the kdc?
> 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?
More information about the krbdev