On Jul 8, 2010, at 12:45 AM, Michael Ströder wrote:
> Kurt Zeilenga wrote:
>> On Jul 5, 2010, at 1:31 PM, Howard Chu wrote:
>>> 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.
>>>> It would be good to add something like this to the spec.
>>> 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.
> Why do you think that the pointer to a separate policy cannot be a collective
> 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.