Subject: [ldapext] password policy: exclude (or exempt) user from policy

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 13:14:55 -0700

It is desirable to have a mechanism to exclude (or exempt) a user from the policy.  For instance, it's nasty for various accounts associated with application entities (as opposed to humans) to be locked out.

In the Isode implementation, we have an operational single-valued attribute, pwdExclude, which if present in the user's entry and has the boolean value TRUE exempts the user from all password policy enforcement.

It would be good to add something like this to the spec.

-- Kurt

---

From: Ludovic Poitou <[email-masked]>
Date: Mon, 05 Jul 2010 22:27:06 +0200

Kurt, 

I don't really like using exception mechanism like this which are difficult to track for an administrator and may be abused by users if not protected appropriately.
In OpenDS we have some extended subtree specifications that allow to filter in or out users from the password policy definition itself. 
I'm gonna be out for the next 3 weeks but will comment your emails related to the password policy when I'm back. I didn't get the time to do it before today. 

Regards

Ludovic Poitou
Sent from a mobile. 

On 5 juil. 2010, at 22:14, Kurt Zeilenga <[email-masked]> wrote:

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

---

From: Howard Chu <[email-masked]>
Date: Mon, 05 Jul 2010 13:31:26 -0700

Kurt Zeilenga wrote:
> It is desirable to have a mechanism to exclude (or exempt) a user from the
> policy.  For instance, it's nasty for various accounts associated with
> application entities (as opposed to humans) to be locked out.
>
> In the Isode implementation, we have an operational single-valued
> attribute, pwdExclude, which if present in the user's entry and has the
> boolean value TRUE exempts the user from all password policy enforcement.
>

That sounds backward to me. You should just define a specific policy for those 
accounts, and turn off everything you don't want enforced in that policy.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Howard Chu <[email-masked]>
Date: Mon, 05 Jul 2010 13:32:51 -0700

Ludovic Poitou wrote:
> Kurt,
>
> I don't really like using exception mechanism like this which are
> difficult
to track for an administrator and may be abused by users if not protected
appropriately.

Agreed.

> In OpenDS we have some extended subtree specifications that allow to
> filter
in or out users from the password policy definition itself.
> I'm gonna be out for the next 3 weeks but will comment your emails related
to the password policy when I'm back. I didn't get the time to do it before today.

> Regards
>
> Ludovic Poitou
> Sent from a mobile.
>
> On 5 juil. 2010, at 22:14, Kurt Zeilenga<[email-masked]>  wrote:
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 13:42:24 -0700

On Jul 5, 2010, at 1:31 PM, Howard Chu wrote:

> That sounds backward to me.

It's modeled after collective attribute exclusions.

> You should just define a specific policy for those accounts, and turn off everything you don't want enforced in that policy.

That can be pain depending on how one organizes their account objects.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 13:55:51 -0700

> I don't really like using exception mechanism like this which are difficult to track for an administrator and may be abused by users if not protected appropriately.

The specification already has numerous operational attributes which an administrator might need to track, I don't see one more being all that problematic...  nor a significant security risk.   Like most DSA vendors, and presumedly you, we just ship with reasonable default access controls for pwdExclude as well as other security oriented attributes.  I assume most DSA vendors ship with defaults that prevent average users from establishing a password policy for their object.

One thing we don't (yet) do is check for inappropriate access rights before using an attribute.  That is, ignore pwdExclude if its writable by the user.  We could do this, but I tend to avoid making the access control system any more complicated than it needs to be.

> I'm gonna be out for the next 3 weeks but will comment your emails related to the password policy when I'm back. I didn't get the time to do it before today. 

No worries.  It's not like these are burning issues.

-- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Thu, 08 Jul 2010 09:45:14 +0200

Kurt Zeilenga wrote:
>> You should just define a specific policy for those accounts, and turn off
>> everything you don't want enforced in that policy.
> 

Why do you think that the pointer to a separate policy cannot be a collective
attribute? Maybe I got you wrong though.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 8 Jul 2010 06:43:31 -0700

> attribute? Maybe I got you wrong though.

The pointer to policy comes from the policy's subtree specification.  X.500 subtree specification has its limit.  See Ludo's comments that  this was addressed in OpenDS via subtree specification extensions.

I also think the tracking argument is kind of bogus.  From our experience, administrators find it natural to go to the user's entry to see determine its configuration...  and to determine all such excluded entries, it's a simple search operation.

And we already have pwdAccountLockedTime which admins can use to lock an user from the user's entry.  It seems all the arguments against pwdExclude would apply to pwdAccountLockedTime and it's funky 000001010000Z value.

Now, if others don't find pwdExclude generally useful, fine.  We'll keep it as a vendor-specific extension.

-- Kurt