Difference between revisions of "Projects/Lockout"
(→After preauthentication success) |
(→After authentication) |
||
| Line 45: | Line 45: | ||
===After authentication=== |
===After authentication=== |
||
| − | |||
| − | Check whether lockout observation window has closed; if so, reset preauthentication failure count. |
||
| − | |||
| − | <pre> |
||
| − | if ( lockout observation window != 0 && bad preauthentication time + lockout observation window > now ) |
||
| − | { |
||
| ⚫ | |||
| − | } |
||
| − | </pre> |
||
====After preauthentication failure==== |
====After preauthentication failure==== |
||
| Line 73: | Line 64: | ||
<pre> |
<pre> |
||
| ⚫ | |||
| + | /* note that AD does not reset preauthentication failure time here */ |
||
| + | |||
if ( lockout duration != 0 && lockout time + lockout duration > now ) |
if ( lockout duration != 0 && lockout time + lockout duration > now ) |
||
lockout time ::= 0 |
lockout time ::= 0 |
||
Revision as of 15:50, 20 August 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.
It is important that deploying this in a mixed environment of 1.8 and pre-1.8 KDCs does not create any security exposures.
Design
Lockout policy
There are three attributes which will be associated with a Kerberos policy:
- lockout threshold (number of attempts)
- lockout observation window (period after which bad preauthentication count will be reset)
- lockout duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)
TBD: is it possible to extend osa_policy_ent_rec with these variables (given the structure is versioned).
There are three attributes which will be associated with each principal:
- time of last preauthentication failure
- number of preauthentication failures (within observation window)
- time the principal was locked out
These will be encoded in TL data for backwards compatibility with existing KDCs.
TBD: We might also set DISALLOW_ALL_TIX for backwards compatibility, although we will need to note whether this was already set so we can restore it (which has a race condition). Ultimately this will be difficult to do properly unless all KDCs are 1.8, so we will have to find the best compromise. I would prefer to distinguish between a principal with DISALLOW_ALL_TIX set and a locked out principal, because they are different things (and the latter can be computed purely from reading the time the principal was locked out).
TBD: in Active Directory, the preauthentication failure time and count are non-replicated attributes (for performance; only the fact an principal is locked out is replicated). Can we do this with the existing KDB replication architecture? How can we replication account lockout status without a multi-master replication architecture? Will we need replication protocol extensions?
Before authentication
Check whether account is already locked out:
if ( lockout time + lockout duration < now )
principal is locked, return KDC_ERR_CLIENT_REVOKED or similar
After authentication
After preauthentication failure
Record authentication failure and possibly lock account out:
preauthentication failure time ::= now
preauthentication failure count ::= preauthentication failure count + 1
if ( lockout threshold != 0 && preauthentication failure count >= lockout threshold )
{
lockout time ::= now /* account is now locked */
attributes ::= attributes | DISALLOW_ALL_TIX
}
After preauthentication success
preauthentication failure count ::= 0
/* note that AD does not reset preauthentication failure time here */
if ( lockout duration != 0 && lockout time + lockout duration > now )
lockout time ::= 0
Implementation details
Plan to implement with the DB backend first, then LDAP. Code will be shared where possible, but the bulk of code will be within the backend, as I don't wish to enforce this lockout model on other backend implementers (such as Novell).
Tools
kadmin will be enhanced to manually unlock a principal.
Status
No code written yet.
