Wrong ML folks :) On Thu, Mar 12, 2015 at 1:24 PM, Kiran Ayyagari <kayyag...@apache.org> wrote: > On Thu, Mar 12, 2015 at 3:33 PM, Emmanuel Lécharny <elecha...@gmail.com> > wrote: > >> Le 11/03/15 11:43, Ludovic Poitou a écrit : >> > >> > -- >> > Ludovic Poitou >> > http://ludopoitou.com >> > >> > >> > From: Emmanuel Lécharny <elecha...@gmail.com> >> > Reply: Apache Directory Developers List <d...@directory.apache.org>> >> > Date: 10 Mar 2015 at 09:23:04 >> > To: Apache Directory Developers List <d...@directory.apache.org>> >> > Subject: PasswordPolicy handling >> > >> > 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 >> > >> > >> > The pwdPolicySubEntry attribute should be read-only, and thus should not >> be set by administrators. >> > >> > It should be set by the server to indicate which PP is enforced for a >> specific user. >> >> This is my thought too. Sadly, this is not what we enforce atm. >> > >> > >> > >> > >> > >> > >> > >> > No need to say that it's extremelly heavy when you have thousands of >> users. >> > I’ve yet to see a customer who wants to define a different password >> policy for each user. >> >> That's not the use case. Our use case is different : sets of users using >> a different PP. As we only suport the automatic enforcement of the >> default PP, if one define a different PP, then each user's entry has to >> be updated to have the new PP's DN. Insane... >> >> > >> > >> > >> > 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. >> > Exactly. >> > >> > >> > >> > 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...). >> > - 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 ? >> > >> > >> > OpenDJ supports both global PP that are defined as part of the >> configuration, and custom password policies that are defined in the DIT as >> SubEntries, and assigned to specific users directly, or through >> CollectiveAttributes. >> The option of mixing both model (ie, config + subentries) is available. >> I tend to think that a pure model (either every PP as subentries, or all >> of them in config) is probably easier to manage. >> >> Regarding CollectivAttributes, what the point using them to manage PPs ? >> The subentry mechanism applies to both class of roles, I'm not sure >> using CA to implement PP makes a lot of sense... In fact, that would >> introduce an indirection, where you will need to fetch the CA, and then >> fetch the associated PP to enforce the PP for each entry, instead of >> directly fetching the PP. Did I missed a step ? >> > just a note, all PPs are always kept in memory and all changes(CRUD) on a > PP are dynamic (no need of server restart) > >> >> > >> > We have a specific operational attribute that one can set to assign a >> password policy to a user (ds-pwp-password-policy-dn). >> >> This somehow contradict what you wrote upper (the attribute is read >> only, administrators should not be able to change the attribute) ? Or is >> it for each user to define its own PP (which I find to be a security >> breah, somehow). >> > >> > The advantage of the custom password policies part of the DIT is that >> they are replicated and thus are guaranteed to be identical on all servers. >> The config is very likely to be replicated too. Having the PP definition >> in the config does not impede the replication to be done, even if the >> config is not replicated : it's just a matter to be careful in the way >> we replicate subentries. >> >> > >> > In general, most customers define 1 or 2 policies. >> > >> > For your proposal, I think it makes sense to translate the PP defined in >> the config into a subEntry, that is read-only. >> >> Which will probably what we are going to do, except that the subentry >> will not hold the full config, but just a copy of it. >> >> >> Thanks Ludo ! >> >> > > > -- > Kiran Ayyagari > http://keydap.com
-- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
