here is my reply (earlier was sent to the wrong ML) ---------- Forwarded message ---------- From: Kiran Ayyagari <[email protected]> Date: Thu, Mar 12, 2015 at 3:54 PM Subject: Re: PasswordPolicy handling To: [email protected]
On Thu, Mar 12, 2015 at 3:33 PM, Emmanuel Lécharny <[email protected]> wrote: > Le 11/03/15 11:43, Ludovic Poitou a écrit : > > > > -- > > Ludovic Poitou > > http://ludopoitou.com > > > > > > From: Emmanuel Lécharny <[email protected]> > > Reply: Apache Directory Developers List <[email protected]>> > > Date: 10 Mar 2015 at 09:23:04 > > To: Apache Directory Developers List <[email protected]>> > > 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 -- Kiran Ayyagari http://keydap.com
