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: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Date Thu, 21 Dec 2006 16:37:04 GMT
Well,

Now I have an account at Novell and rights to edit Internet Drafts
they maintain. We would like to contribute to the pdwPolicy I-D but
our approach is quite different. I may try to add some pwdPolicyScheme
stuff to support more than one scheme in the draft but the community
may not be very happy about it.

-- 
Ersin

On 12/21/06, Alex Karasulu <akarasulu@apache.org> wrote:
> Great and exciting news Ersin!  Let's push forward on this.  I'm excited
> because it's the first directory related RFC the ASF will be involved with.
>
> Regards,
> Alex
>
>
> Ersin Er wrote:
> > Forwarding response from Jim Sermersheim (Novell).
> >
> > ---------- Forwarded message ----------
> > From: Jim Sermersheim <jimse@novell.com>
> > Date: Dec 20, 2006 10:28 PM
> > Subject: Re: Fwd: Brainstorming: Subentry subordinates and assigning
> > an Administrative Area to each user in t
> > To: Ersin Er <ersin.er@gmail.com>, ludovic.poitou@sun.com
> >
> >
> >
> >
> > 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

Mime
View raw message