KRBCONF_KDC_MODIFIES_KDB

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?

Darren




More information about the krbdev mailing list