On 09/09/2015 01:22 PM, Tom Yu wrote: > Mark Pröhl <m...@mproehl.net> writes: > >> according to http://web.mit.edu/kerberos/krb5-1.13/doc/admin/lockout.html, >> the account lockout state is represented by the three account properties >> "The time of last successful authentication", "The time of last failed >> authentication" and "A counter of failed attempts". And that account lockout >> state should not be replicated. > > [...] > >> However, in my simple test environment (Debian Jessie, MIT Kerberos 1.12.1) >> after a kprop/kpropd based full replication, all three properties seem to be >> replicated. > > As implemented, "non-replicated" means not replicated by iprop.
So the documentation (admin guide, lokout.html) differs from the implementation: "The account lockout state of a principal is not replicated by either traditional kprop or incremental propagation." > I believe this was the intent. Full dumps include the non-replicated > lockout state attributes, probably to simplify promoting a slave to a > master. Currently, the only way to prevent kdb5_util dump from dumping > the lockout state attributes is by using a command line flag that is for > the internal use of iprop. > > This seems like it could be either a documentation bug, or a design > flaw, depending on your point of view. Is it helpful to have an option > to suppress the lockout state attributes from full dumps? If so, why? > I think not replicating the account lockout attributes is important for correct lockout policies: an attacker could perform a password guessing attack against the slave KDCs until each slave KDC has locked out the attacked account. After that, the attacker should not be able to continue attacking that account. But if replication from the master resets the lockout state the attacker can continue its attacks. - Mark ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos