Projects/Lockout
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?
Mapping to LDAP password policy draft
- lockout threshold - pwdMaxFailure
- lockout observation window - pwdFailureCountInterval
- lockout duration - pwdLockoutDuration
- time of last preauthentication failure - pwdFailureTime
- number of preauthentication failures (within observation window) - n(pwdFailureTime)
- time the principal was locked out - pwdAccountLockedTime
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
If last preauthentication failure was outside observation window, reset preauthentication failure count.
Then, set preauthentication failure time and count, and lock account out if necessary.
if ( preauthentication failure time + lockout observation window > now )
preauthentication failure count ::= 0
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.
