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