Re: PasswordPolicy handling
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
Re: PasswordPolicy handling
Le 12/03/15 09:11, Ashish a écrit : Wrong ML folks :) Oops...
Re: PasswordPolicy handling
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.
