Difference between revisions of "Projects/Lockout"
(→Design) |
|||
| Line 27: | Line 27: | ||
These are non-replicated attributes. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry. |
These are non-replicated attributes. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry. |
||
| + | |||
| + | ===Replication=== |
||
| + | |||
| + | For DB2 backends, per-principal lockout state will be per KDC: replicated updates will not overwrite this information. Thus, the effective value of pw_max_fail is N * pw_max_fail, where N is the number of KDCs in the realm. |
||
| + | |||
| + | For LDAP backends, we will rely on the LDAP server to update the lockout count; we assume a password policy confirming LDAP server. |
||
====Mapping to LDAP password policy draft==== |
====Mapping to LDAP password policy draft==== |
||
Revision as of 15:46, 13 September 2009
Contents
Background
This project aims to provide principal lockout functionality similar to that of Active Directory. After a certain number of preauthentication failures (the theshold) with a given time limit (the observation window), a principal will be locked out from authenticating for a certain period of time (the lockout duration).
This project has nothing to do with password complexity or ageing.
Design
Lockout policy
There are three attributes which will be associated with a Kerberos policy:
- pw_max_fail (number of attempts)
- pw_failcnt_interval (period after which bad preauthentication count will be reset)
- pw_lockout_duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)
There are four attributes which will be associated with each principal:
- last_success (time of last preauthentication success)
- last_failed (time of last preauthentication failure)
- fail_auth_count (number of preauthentication failures)
- lockout time
These are non-replicated attributes. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry.
Replication
For DB2 backends, per-principal lockout state will be per KDC: replicated updates will not overwrite this information. Thus, the effective value of pw_max_fail is N * pw_max_fail, where N is the number of KDCs in the realm.
For LDAP backends, we will rely on the LDAP server to update the lockout count; we assume a password policy confirming LDAP server.
Mapping to LDAP password policy draft
- pw_max_fail - pwdMaxFailure
- pw_failcnt_interval - pwdFailureCountInterval
- pw_lockout_duration duration - pwdLockoutDuration
- last_failed - pwdFailureTime
- fail_auth_count - number of preauthentication failures (within observation window) - n(pwdFailureTime)
- KRB5_TL_LOCKED_TIME - pwdAccountLockedTime
Before authentication
Check whether account is already locked out:
if (locked_time != 0 &&
stamp < locked_time + lockout_duration)
return kdc_err_client_revoked
After authentication
Implementation details
Tools
kadmin will be enhanced to manually unlock a principal.
