directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Date Wed, 20 Dec 2006 20:58:20 GMT
Hi Jim,

I am glad that to reach some clearification but it should also be
reflected on the draft. On the other side, in my (current) opinion, we
at apache, will go on with a more X.500 friendly way where all the
policy information are stored in a single attribute. So we can use
this syntax in both entryPasswordPolicy and prescriptivePasswordPolicy
attributes (like ACIItems in entryACI and prescriptiveACI attributes).

I had started a very preliminary page on our wiki here:
http://cwiki.apache.org/DIRxSRVx11/account-and-password-policy-management.html
In the following days we'll improve the scheme we propose and also we
can contribute to the RFC.

Best,

-- 
Ersin Er

On 12/20/06, Jim Sermersheim <jimse@novell.com> wrote:
>
>
> Ersin,
>
> Thanks for the feedback.
>
> On the first point, I imagine (though can't remember exactly) that it's a
> typo and we meant to say something like: "But password policies could also
> be in separate sub entries as long as they are contained under the same LDAP
> entry."  Meaning, one could have two or more subentries at the same
> adnimistrative point in the tree.
>
> On the second point, your interpretation and clarifications are exactly what
> we had intended.  I can't speak for Ludo, but I'm happy to let you make
> edits to the document at re-publish.  Last time I edited it was 17 months
> ago :(
> http://forgecvs1.novell.com/viewcvs/standards-docs/password-policy/draft-behera-ldap-password-policy-xx.xml?view=log
>
> Let me know if you're interested. If you are, make yourself a user account
> on forge.novell.com and I'll let you play with it (unless Ludo has some
> concern).
>
> Jim
>
> >>> "Ersin Er" <ersin.er@gmail.com> 12/17/06 3:33 AM >>>
> Hi,
>
> I was reading your LDAP pwdPolicy draft and I shared some of my thoughts on
> it with ApacheDS developers list. Now I am also forwarding that e-mail to
> you. Although it the e-mail contain a little ApacheDS related stuff, can you
> please respond to my questions about the model you propose?
>
> Thanks in advance.
>
> ---------- Forwarded message ----------
> From: Ersin Er <ersin.er@gmail.com>
> Date: Dec 17, 2006 12:20 PM
> Subject: Brainstorming: Subentry subordinates and assigning an
> Administrative Area to each user in the DIT
> To: Apache Directory Developers List <dev@directory.apache.org >
>
> 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 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
> >
> >
> > 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.
> >
>
> What is a "sub entry" and what does it mean being "under the same LDAP
> subentry. 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?
>
> 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.
> >
>
> Does that mean making each user entry an Administrative Point? 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?
>
> 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.
>
> WDYT?
>
> [1]
> http://tools.ietf.org/html/draft-behera-ldap-password-policy
>
> --
> Ersin Er
>
> --
> Ersin


-- 
Ersin

Mime
View raw message