directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Fwd: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Date Fri, 22 Dec 2006 17:19:49 GMT
---------- Forwarded message ----------
From: Ludovic Poitou <Ludovic.Poitou@sun.com>
Date: Dec 22, 2006 7:13 PM
Subject: Re: Fwd: Brainstorming: Subentry subordinates and assigning
an Administrative Area to each user in t
To: Jim Sermersheim <jimse@novell.com>
Cc: Ersin Er <ersin.er@gmail.com>


Yes definitely this document needs work, and volunteers are welcome.
The one thing to remember is that it is also being implemented in
servers that do not follow exactly the X.500 administrative models.
I will send further comments after the seasons' break.

Merry Christmas and Happy New Year,

Ludovic.



Jim Sermersheim 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 <mailto: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
> <mailto: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 <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
>
>
>        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
> <http://tools.ietf.org/html/draft-behera-ldap-password-policy>
>
> --
> Ersin Er
>
> --
> Ersin

--
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



-- 
Ersin

Mime
View raw message