Re: [ldapext] Password Policy Administrative Model

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Apr 2, 2008, at 1:55 PM, Andrew Sciberras wrote:
> Thanks for the response. First two points sound good to me.
>
> I can appreciate the fact there is a desire to only allow one policy  
> to be
> associated with each entry. From your text, it appears that the  
> strategy to
> achieve this allows for implementation simplicity

and model simplicity.

I'm open to suggestions on how to select a single policy from a set of  
inner and specific policies.

I'm not keen on allow multiple policies, especially if that were to  
allow multiple passwords (in a single attribute, or via multiple  
attributes), as that would complicates password expiration handling.

> and imposes the following
> constraints (please correct me if I'm wrong):
> 1. An administrative point will contain at most 1 policy
> 2. The subtreeSpecification for the password policy subentry will  
> govern
> all entries within the administrative area
>
>
>
> If this is the case, then the limitations and bounds in which the  
> password
> policy can be operated should be clarified:
> 1. Policy enforcement within a DIT Domain is not achievable if all  
> DSA's
> are not using the same password attribute type.

Even if different DSAs are authenticating off of different attributes,  
they would
share the same pwdChangedTime (as set by the master).  Likewise for  
other state
attributes.

But there is an assumption (not written down in the I-D, yet) that all  
DSA use the
attribute named in pwdAttribute for simple authentication.

> (Note: RFC4513 indicates
> that there are no implied recommendations for how or where  
> directories store
> passwords for authentication)

Which is why pwdAttribute can be unset, to allow for use of other  
password stores.

> 2. Separate policies that govern different types of entries  
> (objectClasses)
> are not supported. E.g. When multiple types of entries are used for
> authentication (i.e. employeePerson, contractorPerson,  
> softwareApplication),
> specific policies cannot be created for each.

Unfortunately, yes.

> 3. As above, however, if multiple types of entries are used for
> authentication, they will all be subjected to the same password policy
> unless specific exclusions are made on an entry by entry basis.
>
>
>
>
> Regards,
> Andrew
>
>
>> -----Original Message-----
>> From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On  
>> Behalf
>> Of Kurt Zeilenga
>> Sent: Tuesday, 1 April 2008 4:50 PM
>> To: Andrew Sciberras
>> Cc: x500standard@freelists.org; 'LDAP Extensions list'
>> Subject: Re: [ldapext] Password Policy Administrative Model
>>
>>
>> On Mar 31, 2008, at 10:16 PM, Andrew Sciberras wrote:
>>> Hi Kurt,
>>>
>>> Just some comments that are specific to the administrative model.
>>>
>>>
>>>> 3.  Password Policy Administrative Model
>>>
>>> Administrative Area Scope
>>> In [BEHERA] it was stated that a password policy could be defined
>>> for a
>>> specific user by creating a password policy subentry directly under
>>> that
>>> entry. To me, this suggests that password policy administrative
>>> points act
>>> like specific administrative areas.
>>> Is this behavior intended to remain?
>>
>> Yes.
>>
>>> Administrative Role
>>> In accordance with X.501 and RFC3672, do you intend to define an
>>> Administrative Role attribute value to identify that a particular
>>> administrative area is concerned with password policy  
>>> administration?
>>
>> Yes.
>>
>>> Multiple Policies
>>> I assume that the draft allows multiple passwdPolicy subentries to
>>> exist
>>> below a given administrative point... This should be explicitly
>>> clarified in
>>> the I-D.
>>> Multiple subentries could be used to allow policies to apply to
>>> different
>>> attributes, or to allow different policies to apply to a given
>>> password
>>> attribute conditionally, based on the objectClass of an entry (~  
>>> using
>>> subtreeSpecification's).
>>> However, policies may also be created that inadvertently (or
>>> otherwise)
>>> conflict with each other.
>>> Clarifications on this should probably be made to avoid confusion.
>>
>> My intent is for each entry to be governed by at most one password
>> policy,
>> the policy governing entries within a specific administrative area.
>>
>> -- Kurt
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www.ietf.org/mailman/listinfo/ldapext
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext