Subject: [ldapext] password policy: account idling

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 2 Jul 2010 16:01:03 -0700

Once an account has beed idled, how does the administrator clear the idle condition to allow the user to login?

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 2 Jul 2010 16:12:38 -0700

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).

-- Kurt

---

From: simo <[email-masked]>
Date: Fri, 02 Jul 2010 19:21:36 -0400

On Fri, 2010-07-02 at 16:12 -0700, Kurt Zeilenga wrote:
> 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.
> 
> 2) have all shadow/caching servers issue an operation to update the
> master DSA (or a master of a multi-master deployment), or
> 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-masked]>
Principal Software Engineer at Red Hat, Inc. <[email-masked]>

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 2 Jul 2010 16:45:51 -0700

On Jul 2, 2010, at 4:21 PM, simo wrote:
> 
> These options are usually not implemented in real deployments

Account idling is one of Isode's most requested features.  Of course, our market may well be unique.

> because
> they are way too expensive.

I believe trying to share user-specific information produced at any DSA across all DSAs (which might need that information) is not generally feasible.

> The bind operation is quite common and

Which is why I offered an approach to providing account idling which doesn't require replication of successful login information.

> final account lock if one of the servers detect too many attempts.

For failed attempt lockout, our customers seem to happy with per server lockout.

> In

For failed attempt lockout, yes.  For idling, I think our customers want any use of the account on any DSA to prevent lockout on other DSAs.   But as I noted, this can be implemented without replicating last login information.

-- Kurt

---

From: simo <[email-masked]>
Date: Fri, 02 Jul 2010 19:59:55 -0400

> Account idling is one of Isode's most requested features.  Of course, our market may well be unique.

Sorry, I was referring to the last login propagation.
Account idling is not very commonly done at the DSA level in the field I
care about. Usually it is done in the applications that access the DSA
here.
But it is perfectly fine as a feature if the DSA is directly exposed.

> Which is why I offered an approach to providing account idling which
> doesn't require replication of successful login information.

Yes I believe account idling is a good idea in some cases, although I
think you raised a valid concern when you posted the question of how an
admin can effectively control idling, when it is in force and there is a
need to "reset" it.

> For failed attempt lockout, our customers seem to happy with per

Does it mean that the same user is locked on a server but not on
another ? Interesting.

Simo.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 2 Jul 2010 18:02:05 -0700

> Sorry, I was referring to the last login propagation.

so was I.  'last login' recording is for account idling.

> care about.

Understandable.

> Usually it is done in the applications that access the DSA
> here.

I look at this specification as focused on password policy for directory applications (one where the user directly uses a directory client to talk to the directory service), though I am interested in how one might extend this specification to address issues in application services which use directory service as a database backend.

> Does it mean that the same user is locked on a server but not on

Yes.  Otherwise you'd have to replicate the per-user failed login state information, and do that in a manner which couldn't be abused by an attacker to get than N*M guesses (N DSAs, M guesses per DSA) due to the eventual convergent replication of the state information.  But, as I noted earlier in this thread, such replication can be used to mount a magnification attack.  If one has N shadow DSAs hanging directly off a single master, one guess leads directly to N operations to update each shadow DSA (plus a chain operation if the guess was issued at a shadow DSA).

In some of deployments, private pipes are used for replication traffic.  Often these pipes have less bandwidth than between any DSA and the clients which access it.  So an attacker can easily mount a successful attack upon directory replication if one were to replicate such state information.

But I also note that I tend to recommend against enabling account lockout due to excessive failed login attempts, this because doing so enables a DoS attack on user access.   I generally recommend brute force attacks by other means.

> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 3 Jul 2010 06:47:01 -0700

> But I also note that I tend to recommend against enabling account lockout due to excessive failed login attempts, this because doing so enables a DoS attack on user access.   I generally recommend…

insert "hindering" somewhere in the last sentence.... :-)

-- Kurt