Re: password policy: account idling in distributed systems

On Fri, 2010-07-02 at 16:12 -0700, Kurt Zeilenga wrote:
> Some additional thoughts here...
> 
> The primary problem with this feature is assumes that there either a
> single DSA used by the user, or that all of the DSAs used by the user
> share last-login information.  While it might be oddly useful in some
> distributed environments to idle accounts on a per DSA basis, in
> general this would be un-usefully odd.
> 
> There are a number of approaches one could use to share state.
> 
> 1) have all DSAs be masters in a multi-master DSA system,
> 2) have all shadow/caching servers issue an operation to update the
> master DSA (or a master of a multi-master deployment), or
> 3) have all shadow/caching servers chain the Bind request.
> 
> Option 1 is problematic as multi-master systems (with no
> shadow/caching DSAs) tend not to scale as broadly as
> single-master/shadowing/caching systems.
> 
> For Simple password Bind and SASL/PLAIN, there isn't much difference
> between option 2 and 3.  But 3 is problematic when SCRAM and like
> mechanisms are used.  And 3 is also problematic when the master(s) are
> unreachable.  With 2, the master update can be deferred until the
> master(s) become reachable.
> 
> Another approach, which I think is more generally applicable, would be
> last successful login to recorded in a dsaOperation attribute and then
> have a separate directory application that could be ran at a suitable
> interval, that would for each user, check each DSA for the last login
> time, determine the latest login time across all DSAs, and if not
> recent enough, lock the account via an accountLock attribute.
> 
> To unlock, the management client likely should, in addition to
> clearing the accountLock attribute, set some attribute to exclude
> subsequent idling locking for some period of time (see my how question
> about how to unlock an idle account).

These options are usually not implemented in real deployments because
they are way too expensive. The bind operation is quite common and
changing an object in the DIT every time it succeeds and then
replicating it to all servers is costly.
The only information that is usually propagated to all servers is the
final account lock if one of the servers detect too many attempts. In
general it is considered a good compromise to limit counting login
attempts to determine if the account should be locked on a per server
basis.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <[email protected]>
Principal Software Engineer at Red Hat, Inc. <[email protected]>