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
|