directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: PasswordPolicy handling
Date Wed, 11 Mar 2015 09:11:48 GMT
Thanks for your insights Howard.

Loking backward, I think there are many things that I find over-complicated
in the X-500 administrative model approach. There are two aspects to
consider here :
- at runtime
- from a configuration point of view

At runtime

Sadly, we have to cope with the Adminsitrative Area concept. This is quite
complex, with the three diffenrent flavor of them :
- Autonomous Areas
- Specific Areas
- Inner Areas
which are covering various roles (Collective Attributes, Subschema, Access
Control, Triggers, Password Policy and Replication - probably some more
later -).

All in all, it's about determinating if an entry belongs to an
administrative area, and if the aspect being handled impacts the entry.

We have had long discussions years ago about how to 'link' entries with
their associated areas. There are two possibilities :
- update each entry, adding an attribute to point to the subentry's DN it
is managed by (the X500 way)
- add these attributes when the entry is  being handled.

The first approach is faster when we are making decisions on entries (ie,
is the Access Control allows to do that on the entry, does this entry has
some collectove attribute, etc), as the entry already have a pointer to the
subentry it depends on.

The second approach requires that every time a decision has to be made, we
have to retrieve the subentries this entry depends on, by checking the
position of the entry in the existing areas, and by checking that the
subtree specification matches.

I would favor the second appraoch in a big base, as adding a subentry would
potentially impact millions of entries, that would have to be updated. This
is so expensive that it might take hours to handle...

On the other hand, making the decision live would add a cost to every
operation, for ever...

A third possible way would be to have a mixture of those two approaches :
the attribute is added into the entry when we have evaluated the subentry
once. We will just have to check at runtime that the entry's CSN is younger
than the subentries it might depend on (and as we load all the subentries
in a cache at startup, this is a simple operation). The cost of updating
entries would be spreaded over the various operations. Of course, doing a
full search would fall into the first approach...

Not ann easy decision.


Right now, configuring CA, AC, or any other role, is about adding a
subentry in the server. Not something you can do when the server is not
running (well, not for ApacheDS at least, and it's not expected to be
possible in a near future). Regardless, as the subentries might be spread
over the btree, with no way to know where they are stored unless one do a
search for every entries having a subentry ObjectClass, from an
admnistration POV, this is a nightmare.

Another option would be to store all the subentries into cn=config, as we
currently do for PP. First, it make cn=config a central point of
configuration, which makes a lot of sense. Second, it makes it extremelly
easy to manage the configuration with a GUI like Studio : you don't even
need to start the server, and it's all well located in a well known branch
of cn=config.

At startup, the server will simply inject the subentries at the right
places in the tree. Well, it even does not have to do that at all : it's
enough to 'emulate' the existance of such entries when a search is done :
we will havethem in memory. Updates could still be done through pure LDAP
operation, like what we currently siupport for the Schema.

I do think that makes a lot of sense to switch to such a mechanism.


Le mardi 10 mars 2015, Howard Chu <> a écrit :

> 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