Proxy for Kerberos?

John Hascall john at
Sat Jul 29 11:34:39 EDT 2006

> Replication is not the desired semantic for this information.  You don't
> want to overwrite the previous values such as "last attempt" and "number
> of attempts".  Instead, periodically you want each server to broadcast
> its list of applicable attempts for those principals that were accessed
> since the most recent broadcast.  The receivers of the updates need to
> merge the data to construct its current view of the world for that
> principal.
> Right now there is nothing like this for MIT's code base.

> Note that even if there is an accurate means of synchronizing this
> information that there is not a one to one relationship between a user
> entering her principal and password and a request being sent to a KDC.
> Today's clients frequently make multiple requests to one or more KDCs
> so even when you have a multi-master configuration such as Active
> Directory setting a policy of "three login attempts before lockout"
> will not provide the behavior that administrators anticipate.

   It seems to me that to do this accurately there would need
   to be some way to indentify that request 'A' at KDC-1 is
   really the same user interaction as request 'B' at KDC-2.
   Is there some unique-id in the requests that would even allow this?
   (I can't think of one).


More information about the krbdev mailing list