directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in the DIT
Date Sun, 17 Dec 2006 21:24:23 GMT
Ersin Er wrote:
> Hi,
> I was just reading the draft: Password Policy for LDAP Directories [1].
> It defines an auxiliary object class to define a set of password policy
> rules in an entry.
> What I was interested in is the administration of this policy object. A
> bulb appeared above my head telling me that this is a nice fit for the
> Administrative Model 

I agree 100% at using this tactic.  The administrative model is at the
heart of several aspects within the server why should this be any
different.  Using the same model to apply password policy makes great
sense and can help leverage the same tooling around subentries and

BTW I would also talk to Enrique about some things he's already
implement wrt password policy for the change password service.  The idea
we shared was to centralize password policy management in the core of
the server so all services can utilize it.  I know this is somewhat a
separate concern but just take it as an FYI for both you guys.

and I saw that the RFC also suggests the same
> thing. However, that is the weakest part of the RFC. Let me quote it:
>     10.  Administration of the Password Policy
>        {TODO: Need to define an administrativeRole (need OID).  Need to
>        describe whether pwdPolicy admin areas can overlap}
>        A password policy is defined for a particular subtree of the DIT by
>        adding to an LDAP subentry whose immediate superior is the root of
>        the subtree, the pwdPolicy auxiliary object class.  The scope of the
>        password policy is defined by the SubtreeSpecification attribute of
>        the LDAP subentry as specified in [RFC3672 <>].
>        It is possible to define password policies for different password
>        attributes within the same pwdPolicy entry, by specifying multiple
>        values of the pwdAttribute.  But password policies could also be in
>        separate sub entries as long as they are contained under the same
>        LDAP subentry.
>        Modifying the password policy MUST NOT result in any change in users'
>        entries to which the policy applies.
>        It SHOULD be possible to overwrite the password policy for one user
>        by defining a new policy in a subentry of the user entry.
>        Each object that is controlled by password policy advertises the
>        subentry that is being used to control its policy in its
>        pwdPolicySubentry attribute.  Clients wishing to examine or manage

Sounds to me like he's looking for the schemaSubentry or
accessControlSubentry attribute for the policy which stores the DN to
the subentry.

>        password policy for an object may interrogate the pwdPolicySubentry
>        for that object in order to arrive at the proper pwdPolicy subentry.
> The first thing I did not understand is the following sentence:
>     But password policies could also be in
>        separate sub entries as long as they are contained under the same
>        LDAP subentry.

Yeah this just sounded like he does not understand the admin model
fully.  This is a nonsensical statement perhaps it was a type.  After
all this is a draft and not an RFC.

> What is a "sub entry" and what does it mean being "under the same LDAP
> subentry. 

I think this guys is trying to say that you can have more than one
subentry to store different policy rules for a PAA.

Subentries cannot have any subordinates according to X.500.
> RFC 3672 does not say anything about this but having subentry
> subordinates may break the model. So do we need to allow something like
> this?

Yeah this breaks hard with X.500.  Also it's a bad idea in general to
have subentries with child entries.  Why?  Think about the subentry
control and continuity with respect to search results returned.  The
rules about how search is supposed to find stuff gets really complicated
and almost undefined.

It's bad juju to mess around this way IMO.

> Another point that is interesting is the following sentence:
>     It SHOULD be possible to overwrite the password policy for one user
>        by defining a new policy in a subentry of the user entry.

Yeah sounds to me like having entry policy rules that override
prescriptive policy rules.

> Does that mean making each user entry an Administrative Point? 

Nah I think he means sort of what is done with ACI in X.500.  We can
have wide reaching policies that effect an entire group based on
geometry or refinements however he wants to have exceptions to these
general rules.  Doing so means having the policy rules in entries
themselves to potentially override prescriptive ones.

This may
> make sense in certain situations: If your password policy object cannot
> be defined as a single attribute as the entryACI, then you need to store
> that information with separate attributes distributed in an entry. This
> is OK for subentries, but when you want to apply this policy to a single
> (user) entry, you will cause a clutter in the that entry. So if you
> define a user entry as a Password Policy Administrative Point and if you
> put a passwordPolicySubentry (with policy attributes) subordinate to it
> with subtreeSpecification: { maximum 1 }, then you will achieve the
> effective-on-one-entry-and-still-multi-attribute scheme. Does this make
> sense for you?

No you've lost me here.

> BTW, the sentence tells about "overwriting". For overwriting there is
> need for a precedence facility. Otherwise both the global pwdPolicy and
> the user-local pwdPolicy will apply to the entry. This is one of the
> problems I see about the specification.

I did not gather that from these excerpts.  However this all does not
matter.  Implementation details are not important.  The specification of
a strong admin model is like you already did for Triggers for example.

This draft needs some work wrt the admin model used.  Perhaps u can get
involved from the ASF side.


Good stuff I want it!  Will be nice to have.

> [1]
> -- 
> Ersin Er

View raw message