Mini-review: account lockout KDB performance options

ghudson@MIT.EDU ghudson at MIT.EDU
Sat May 1 00:51:22 EDT 2010


We've been asked to add configuration variables to tune the
performance penalties associated with account lockout.  This request
is most relevant to high-load LDAP deployments.  I'm thinking of two
boolean configuration variables:

  1. Disable updating last_success.
  2. Disable updating last_failed and fail_auth_count (and
     consequently disable lockout support).

last_success is just informational and is not used by the lockout
logic, so can be disabled without disabling lockout support.  Without
the need to update last_success, write operations can be avoided for
successful preauthenticated AS requests unless fail_auth_count needs
to be reset (i.e. unless a failed request occurred since the last
successful request).

If lockout support can be disabled entirely, then we avoid the
overhead of looking up the password policy (for principals which have
one) as well as the write overhead of maintaining last_failed and
fail_auth_count.

The KDC treats account lockout as a detail of the KDB back end.  Each
plugin implements lockout via the CHECK_POLICY_AS and AUDIT_AS
db_invoke methods.  This fact argues for using module-specific
configuration variables like so (I haven't firmly decided on the
option names yet):

  [dbmodules]
    LDAP = {
      db_library = kldap
      update_last_success = false
      disable_lockout = true
      ldap_kerberos_container_dn = ...
    }

Each plugin would read the profile variables where they read other
module-specific variables (such as krb5_db2_open) and store the
results in the db context.

Another choice would be to treat the variables as realm configuration
options, to be read in alt_prof.c and stored in the kdc_realm_data
structure.  The argument for this would be that even though the
lockout implementation is backend-specific, the metadata fields are
generic.  Unfortunately, it is not obvious how the variable values
would be communicated to the database back ends, which do not have
direct access to kdc_realm_data.



More information about the krbdev mailing list