krb5 commit [krb5-1.12]: Clarify lockout replication issues in docs

[Tom Yu]

https://github.com/krb5/krb5/commit/59a811e02aee254e147557db74c8f748625172e4
commit 59a811e02aee254e147557db74c8f748625172e4
Author: Greg Hudson <ghudson at mit.edu>
Date:   Mon Nov 18 18:59:17 2013 -0500

    Clarify lockout replication issues in docs
    
    In the "KDC replication and account lockout" section of lockout.rst,
    specifically call out kprop and incremental propagation as the
    mechanisms which do not replicate account lockout state, and add a
    note that KDCs using LDAP may not be affected by that section's
    concerns.
    
    (cherry picked from commit 8eb9e6fe1b01faa875dcf91b618ad4cd7793438a)
    
    ticket: 7773
    version_fixed: 1.12
    status: resolved

 doc/admin/lockout.rst |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/doc/admin/lockout.rst b/doc/admin/lockout.rst
index e520921..7e62841 100644
--- a/doc/admin/lockout.rst
+++ b/doc/admin/lockout.rst
@@ -95,19 +95,25 @@ This command will reset the number of failed attempts to 0.
 KDC replication and account lockout
 -----------------------------------
 
-The account lockout state of a principal is not replicated between
-KDCs.  Because of this, the number of attempts an attacker can make
-within a time period is multiplied by the number of KDCs.  For
-instance, if the **maxfailure** parameter on a policy is 10 and there
-are four KDCs in the environment (a master and three slaves), an
-attacker could make as many as 40 attempts before the principal is
-locked out on all four KDCs.
+The account lockout state of a principal is not replicated by either
+traditional :ref:`kprop(8)` or incremental propagation.  Because of
+this, the number of attempts an attacker can make within a time period
+is multiplied by the number of KDCs.  For instance, if the
+**maxfailure** parameter on a policy is 10 and there are four KDCs in
+the environment (a master and three slaves), an attacker could make as
+many as 40 attempts before the principal is locked out on all four
+KDCs.
 
 An administrative unlock is propagated from the master to the slave
 KDCs during the next propagation.  Propagation of an administrative
 unlock will cause the counter of failed attempts on each slave to
 reset to 1 on the next failure.
 
+If a KDC environment uses a replication strategy other than kprop or
+incremental propagation, such as the LDAP KDB module with multi-master
+LDAP replication, then account lockout state may be replicated between
+KDCs and the concerns of this section may not apply.
+
 
 KDC performance and account lockout
 -----------------------------------