directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: PasswordPolicy handling
Date Tue, 10 Mar 2015 15:12:02 GMT
On Tue, Mar 10, 2015 at 4:22 PM, Emmanuel L├ęcharny <elecharny@gmail.com>
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

Mime
View raw message