KRBCONF_KDC_MODIFIES_KDB

[Prabhakaran vaidya]

I have a related question. We were trying to look at kdc.log files to 
find if there was an incorrect password attempt
and could not find any difference between successful and unsuccessful 
attempts. Any help how to get this
information will be appreciated.  By default the KDC is compiled as 
read only and we have another system of records
that feeds the KDCs. So we would like to lock at the source and flow it 
down to KDCs.
Thanks
-prab

On Jan 15, 2004, at 6:58 AM, Kevin Coffman wrote:

>> 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.
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev