You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin Er <er...@gmail.com> on 2006/12/17 11:20:48 UTC
Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in the DIT
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
--
Ersin Er
Re: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in the DIT
Posted by Ersin Er <er...@gmail.com>.
On 12/17/06, Alex Karasulu <ak...@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
Re: Brainstorming: Subentry subordinates and assigning an Administrative
Area to each user in the DIT
Posted by Alex Karasulu <ak...@apache.org>.
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.
> 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.
> 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
Re: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Posted by Ersin Er <er...@gmail.com>.
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 <ji...@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" <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 <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
Re: Fwd: Fwd: Brainstorming: Subentry subordinates and assigning
an Administrative Area to each user in t
Posted by David Boreham <da...@bozemanpass.com>.
Ersin Er wrote:
> 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.
My suggestion before doing so would be to post to the ietf-ldapext
mailing list
with your concerns about the existing draft. From the perspective of an
application developer, it would be a shame if ApacheDS weren't compatible
with the existing implementations out there.
Re: Fwd: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Posted by Ersin Er <er...@gmail.com>.
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 <ak...@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 <ji...@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 <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" <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 <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
Re: Fwd: Fwd: Brainstorming: Subentry subordinates and assigning
an Administrative Area to each user in t
Posted by Alex Karasulu <ak...@apache.org>.
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 <ji...@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 <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" <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 <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
>
Fwd: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Posted by Ersin Er <er...@gmail.com>.
Forwarding response from Jim Sermersheim (Novell).
---------- Forwarded message ----------
From: Jim Sermersheim <ji...@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 <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" <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 <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
Fwd: Fwd: Brainstorming: Subentry subordinates and assigning an Administrative Area to each user in t
Posted by Ersin Er <er...@gmail.com>.
---------- Forwarded message ----------
From: Ludovic Poitou <Lu...@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 <ji...@novell.com>
Cc: Ersin Er <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" <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 <ma...@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
> <ma...@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