directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in the DIT
Date Tue, 19 Dec 2006 08:58:49 GMT
On 12/17/06, Alex Karasulu <akarasulu@apache.org> wrote:
> 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
> subtreeSpecifications.
>
> 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 <http://tools.ietf.org/html/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.

What about subentries as subordinates of subentries?

> > 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.

The scheme I proposed is perfectly applicable but causes clutter.

Well, I'll go on here:

http://cwiki.apache.org/DIRxSRVx11/account-and-password-policy-management.html

> > 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.
>
> > WDYT?
>
> Good stuff I want it!  Will be nice to have.
>
> > [1] http://tools.ietf.org/html/draft-behera-ldap-password-policy
> >
> > --
> > Ersin Er
>
>
>
>


-- 
Ersin

Mime
View raw message