[37222] in Kerberos
Re: Account lockout / replication issue
daemon@ATHENA.MIT.EDU (Tom Yu)
Wed Sep 9 07:23:03 2015
From: Tom Yu <tlyu@mit.edu>
To: Mark =?utf-8?Q?Pr=C3=B6hl?= <mark@mproehl.net>
Date: Wed, 09 Sep 2015 07:22:42 -0400
In-Reply-To: <E46EA82B-52C4-4437-89CA-972D22C6CF92@mproehl.net> ("Mark
=?utf-8?Q?Pr=C3=B6hl=22's?= message of "Tue, 8 Sep 2015 15:21:06 +0200")
Message-ID: <ldvh9n3u9a5.fsf@sarnath.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Mark Pröhl <mark@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. 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?
Thanks.
-Tom
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
