[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Password Policy Administrative Model
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: 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