Subject: Re: [ldapext] Password Policy Administrative Model

From: "Andrew Sciberras" <[email-masked]>
Date: Thu, 3 Apr 2008 07:55:05 +1100

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 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. (Note: RFC4513 indicates
that there are no implied recommendations for how or where directories store
passwords for authentication)
 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. 
 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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kurt Zeilenga
> Sent: Tuesday, 1 April 2008 4:50 PM
> To: Andrew Sciberras
> Cc: [email-masked]; '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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 2 Apr 2008 17:41:40 -0700

On Apr 2, 2008, at 1:55 PM, Andrew Sciberras wrote:
> 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
> 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

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

> specific policies cannot be created for each.

Unfortunately, yes.