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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > > > > 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[email protected] > > > 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
