On Tue, Mar 10, 2015 at 4:22 PM, Emmanuel Lécharny <[email protected]> wrote:
> Hi guys, > > this morning, we have had a quick discussion with Kiran that I will > retranscript here. Let me give you a bit of feedback first. > > Yesterday, I was working on Studio, and more specifically on the > ApacheDS configuration PasswordPolicy page. I just wanted to add some > missing elements (a couple, pwdMinDelay and pwdMaxDelay). At some point, > I wondered how we could possibly associate a PP to an entry, assuming we > may define more than one PP, beside the default one. > Then I read the thread on the user list, where someone is having trouvle > defining a specific PP, and leverage it. The answer was to add a > pwdPolicySubEntry DN in each entry that has to use this added PP. Here > is an exemple : > > dn: uid=jsmith,ou=users,ou=int,o=company > uid: jsmith > cn: jsmith > ... > pwdPolicySubEntry: > ads-pwdId=internalUsers,ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,adsdirectoryServiceId=default,ou=config > > No need to say that it's extremelly heavy when you have thousands of users. > > Now, let me relate what we discussed with Kiran : > > The RFC draft states that PP must be define in subentry : > > "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" > > By all means, it's equivalent to what we have for Collective Attributes, > Subschema Subentries, Access Control, Triggers. The DIT area impacted by > such a subentry would be defined by the subentry SubtreeSpecification, and > each entry below the subentry's parent would be evaluated accordingly to > the SubtreeSpecification. The pwdPolicySubEntry attribute would be added on > the fly when the entry is requested, not added into the entry itself. > > This would be a huge chenge is the way we currently handle PP, as we do it > through the cn=config partition. > > My perception is that PP should not be stored in the configuration at all, > but Kiran perception is that would make it quite complicated to > administrate the server, especially when most of the users would have only > one PP. > > I agree with Kiran on this point. > > Now, what are the possible path for a better handling of PPs ? Here are a > few suggestions : > - the default PP should remain in the configuration. It will be associated > with the rootDSE, and apply to the whole DIT > - thid default PP could be disabled, if needed > - regarding new PP, we have two options : > - we keep declaring them in the confing, but they are translated to a > subentry at startup (we have to add a DN to the PP in config) > - we remove the PP declaration in the config > (I personally find the first approach more appealing, as it allows users > to administrate the config globally, although it makes it more complex from > the code pov, as we have to update teh config when we add a new PP as a > subentry. That means the config generates a subentry, and updating the > subentry update the config. Not exactly simple...). > let us not even do that, just have the DN of password policy be present in this subentry and currently server has necessary mechanism to pickup the effective policy. > - we most certainly have to define a new administrative role for PP, and > handle subentries and teh way they are applied. That means we most > certainly have to create a new interceptor > > > Lot of works, for sure. > > Thoughts ? > > > -- Kiran Ayyagari http://keydap.com
