directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: PasswordPolicy handling
Date Tue, 10 Mar 2015 14:51:33 GMT
Emmanuel L├ęcharny 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...).
> - 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 ?

We've had this same dilemma in OpenLDAP - the "right" way to manage all these things, according
to X.500, is by actual subentries scattered throughout the DIT. I believe this is inherently
unmanageable, and isolating into cn=config is the more secure approach.

Your option 1, keep in config but generate subentry at startup, sounds pretty good to me.
This is effectively the same approach we've already taken with e.g. the subschema subentry
- schema is controlled under cn=config, but advertised in the subentry. It's still a bit odd,
some LDAP clients think they should be able to modify runtime schema by LDAPmodifying the
subentry and they choke when this fails. But those cases are quite rare.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message