doc/admin/lockout.rst

   1 Account lockout
   2 ===============
   3
   4 As of release 1.8, the KDC can be configured to lock out principals
   5 after a number of failed authentication attempts within a period of
   6 time.  Account lockout can make it more difficult to attack a
   7 principal's password by brute force, but also makes it easy for an
   8 attacker to deny access to a principal.
   9
  10
  11 Configuring account lockout
  12 ---------------------------
  13
  14 Account lockout only works for principals with the
  15 **+requires_preauth** flag set.  Without this flag, the KDC cannot
  16 know whether or not a client successfully decrypted the ticket it
  17 issued.  It is also important to set the **-allow_svr** flag on a
  18 principal to protect its password from an off-line dictionary attack
  19 through a TGS request.  You can set these flags on a principal with
  20 :ref:`kadmin(1)` as follows::
  21
  22     kadmin: modprinc +requires_preauth -allow_svr PRINCNAME
  23
  24 Account lockout parameters are configured via :ref:`policy objects
  25 <policies>`.  There may be an existing policy associated with user
  26 principals (such as the "default" policy), or you may need to create a
  27 new one and associate it with each user principal.
  28
  29 The policy parameters related to account lockout are:
  30
  31 * :ref:`maxfailure <policy_maxfailure>`: the number of failed attempts
  32   before the principal is locked out
  33 * :ref:`failurecountinterval <policy_failurecountinterval>`: the
  34   allowable interval between failed attempts
  35 * :ref:`lockoutduration <policy_lockoutduration>`: the amount of time
  36   a principal is locked out for
  37
  38 Here is an example of setting these parameters on a new policy and
  39 associating it with a principal::
  40
  41     kadmin: addpol -maxfailure 10 -failurecountinterval 180
  42         -lockoutduration 60 lockout_policy
  43     kadmin: modprinc -policy lockout_policy PRINCNAME
  44
  45
  46 Testing account lockout
  47 -----------------------
  48
  49 To test that account lockout is working, try authenticating as the
  50 principal (hopefully not one that might be in use) multiple times with
  51 the wrong password.  For instance, if **maxfailure** is set to 2, you
  52 might see::
  53
  54     $ kinit user
  55     Password for user@KRBTEST.COM:
  56     kinit: Password incorrect while getting initial credentials
  57     $ kinit user
  58     Password for user@KRBTEST.COM:
  59     kinit: Password incorrect while getting initial credentials
  60     $ kinit user
  61     kinit: Client's credentials have been revoked while getting initial credentials
  62
  63
  64 Account lockout principal state
  65 -------------------------------
  66
  67 A principal entry keeps three pieces of state related to account
  68 lockout:
  69
  70 * The time of last successful authentication
  71 * The time of last failed authentication
  72 * A counter of failed attempts
  73
  74 The time of last successful authentication is not actually needed for
  75 the account lockout system to function, but may be of administrative
  76 interest.  These fields can be observed with the **getprinc** kadmin
  77 command.  For example::
  78
  79     kadmin: getprinc user
  80     Principal: user@KRBTEST.COM
  81     ...
  82     Last successful authentication: [never]
  83     Last failed authentication: Mon Dec 03 12:30:33 EST 2012
  84     Failed password attempts: 2
  85     ...
  86
  87 A principal which has been locked out can be administratively unlocked
  88 with the **-unlock** option to the **modprinc** kadmin command::
  89
  90     kadmin: modprinc -unlock PRINCNAME
  91
  92 This command will reset the number of failed attempts to 0.
  93
  94
  95 KDC replication and account lockout
  96 -----------------------------------
  97
  98 The account lockout state of a principal is not replicated by either
  99 traditional :ref:`kprop(8)` or incremental propagation.  Because of
 100 this, the number of attempts an attacker can make within a time period
 101 is multiplied by the number of KDCs.  For instance, if the
 102 **maxfailure** parameter on a policy is 10 and there are four KDCs in
 103 the environment (a master and three slaves), an attacker could make as
 104 many as 40 attempts before the principal is locked out on all four
 105 KDCs.
 106
 107 An administrative unlock is propagated from the master to the slave
 108 KDCs during the next propagation.  Propagation of an administrative
 109 unlock will cause the counter of failed attempts on each slave to
 110 reset to 1 on the next failure.
 111
 112 If a KDC environment uses a replication strategy other than kprop or
 113 incremental propagation, such as the LDAP KDB module with multi-master
 114 LDAP replication, then account lockout state may be replicated between
 115 KDCs and the concerns of this section may not apply.
 116
 117
 118 KDC performance and account lockout
 119 -----------------------------------
 120
 121 In order to fully track account lockout state, the KDC must write to
 122 the the database on each successful and failed authentication.
 123 Writing to the database is generally more expensive than reading from
 124 it, so these writes may have a significant impact on KDC performance.
 125 As of release 1.9, it is possible to turn off account lockout state
 126 tracking in order to improve performance, by setting the
 127 **disable_last_success** and **disable_lockout** variables in the
 128 database module subsection of :ref:`kdc.conf(5)`.  For example::
 129
 130     [dbmodules]
 131         DB = {
 132             disable_last_success = true
 133             disable_lockout = true
 134         }
 135
 136 Of the two variables, setting **disable_last_success** will usually
 137 have the largest positive impact on performance, and will still allow
 138 account lockout policies to operate.  However, it will make it
 139 impossible to observe the last successful authentication time with
 140 kadmin.
 141
 142
 143 KDC setup and account lockout
 144 -----------------------------
 145
 146 To update the account lockout state on principals, the KDC must be
 147 able to write to the principal database.  For the DB2 module, no
 148 special setup is required.  For the LDAP module, the KDC DN must be
 149 granted write access to the principal objects.  If the KDC DN has only
 150 read access, account lockout will not function.