[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Password Policy OIDs



Something I said below is wrong:
 
Ludo and I worked on that solution and it's still part of the draft (Section 5.3.1 Password Policy State Attribute Option).
 
So there is a provision to place multiple pwd policy subentries under a single AP, we just need to specify that they can't govern the same pwd attribute.
 
I think I'll take a break...
 
Jim
 
>>> Jim Sermersheim >>>
Thanks for the clarification.
 
So I think we want to specify these things for the pwd policy (is there such a thing pwdPolicy inner administrative area? Can a pwdPolicy administrative point have multiple subentries?)
 
I think I'm hearing Yes, and Maybe Not (respectively).
 
To allow multiple subentries, some requirement must be given such that no two subentries govern the same pwd attribute. Also, the state information doen't currently allow for multiple policies (Ludo and I worked on that solution once, and gave up).
 
Jim

>>> Steven Legg <steven.legg@eb2bcom.com> 10/28/04 6:17:14 PM >>>

Jim,

Jim Sermersheim wrote:
> Right, I know the mechanism used for this, but...
>
> I was under the impression that a specification of an administrative
> policy is responsible to make statements as to whether or not such
> things are allowed. And if allowed, what restrictions exist (in pwd
> policy's case, one restriction is to not allow a single object to be
> governed by two pwd policy subentries each specifying the same pwd
> attribute).
>
> For example, the specification for the subschema administrative area
> makes some statement (though I can't find it now) which restricts an
> object to only being governed by a single subschema subentry.

FYI, it comes about as a consequence of there being no such thing as a subschema
inner administrative area, and the requirement that a subschema administrative
point have no more than one subschema subentry.

Regards,
Steven

>
> Jim
>
> >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/27/04 6:07:53 PM >>>
> Jim Sermersheim wrote:
>
> > Right, but someone may want to define one policy for person objects,
> > and another policy for widget objects, where persons and widgets fall
> > under the same hierarchy.
> >
>
> I'm not sure to what extent the SubtreeSpecification attribute is
> supported within LDAP directories, but you can certainly achieve your
> above statement by using the substreeSpecification att. This is due to
> the 'Refinement' choice within the SubtreeSpecification structure that
> allows you to filter which entries the policy applies to based on their
> object class.
>
> Andrew
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext