logo_kerberos.gif

Difference between revisions of "Projects/Lockout"

From K5Wiki
Jump to: navigation, search
(After preauthentication failure)
(Lockout policy)
Line 34: Line 34:
   
 
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?
 
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===
 
===Before authentication===

Revision as of 04:00, 30 August 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.



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.