You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2015/03/10 09:22:33 UTC
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
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 ?
Re: PasswordPolicy handling
Posted by Emmanuel Lecharny <el...@apache.org>.
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.
Configuration
-------------
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.
WDYT ?
Le mardi 10 mars 2015, Howard Chu <hy...@symas.com> 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. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
Re: PasswordPolicy handling
Posted by Howard Chu <hy...@symas.com>.
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. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: PasswordPolicy handling
Posted by Emmanuel Lecharny <el...@apache.org>.
That's totally manageable. We just have to refer to the PP DN in the
subentry.
Still we jave to add the subentry DN in the PP cinfig entry to remember
where the PP subentry has to be injected at startup.
Le mardi 10 mars 2015, Kiran Ayyagari <ka...@apache.org> a écrit :
>
>
> On Tue, Mar 10, 2015 at 4:22 PM, Emmanuel Lécharny <elecharny@gmail.com
> <javascript:_e(%7B%7D,'cvml','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
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: PasswordPolicy handling
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Mar 10, 2015 at 4:22 PM, Emmanuel Lécharny <el...@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
Re: Fwd: Re: PasswordPolicy handling
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 12/03/15 10:27, Ludovic Poitou a écrit :
> Hi,
>
> more comments inline below…
>
>
> Le 11/03/15 11:43, Ludovic Poitou a écrit :
>>
>> --
>> Ludovic Poitou
>> http://ludopoitou.com
>>
>>
>> From: Emmanuel Lécharny <el...@gmail.com>
>> Reply: Apache Directory Developers List <de...@directory.apache.org>>
>> Date: 10 Mar 2015 at 09:23:04
>> To: Apache Directory Developers List <de...@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...
>
>
> I don’t think our use case is different.
> We have customers that have different sets of users and want to enforce different password policies for each set.
> Typically is regular users, vs administrators vs application specific accounts.
> I haven’t talked with any customer that wanted to push the limits to one user, one password policy.
Me neither. I don't think that makes sense at all.
> This would be insane to manage (and stupid since there will be duplicated policies anyway).
+1
> In OpenDJ, the pwdPolicySubEntry attribute is an operational attribute that is computed and points to the Policy that is enforced for the user.
So you handle it at runtime. That was one of the two options we are
considering in one of my previous mail.
>
>
>>
>>
>>
>> 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 ?
>
>
> Collective attributes are allowing us to assign the global password policies, because we do not translate them to a proper subentry with a global scope.
But this is overlapping, because in order to define the set of users,
you have to define a subtree specification in your CA subentry, and your
CA subentry has to be associated with the PP you want to apply for all
your users. What's the advantage of doing that, when you can directly
leverage the PP subentry ?
>
> It also allows to have different sub-scopes pointing to a same policy.
You can do that by defining the subtree specification.
> (think about an ISP that has 20 organizations, and in each, different sets of users that must have the same “Administrators” password policy. With just the subentry mechanism, adding a new organisation means that you must update the subEntry and impact all users.
I agree that you have to update the subentry, but how will that impacts
the existing users ? They are just pointing to the subentry they depend
on, or it's computed at runtime.
>
>
>
>>
>> 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).
> It does not contradict. It complements. We have 2 separate attributes. One to assign if needed (i.e. overwrite the global policy), which can be done with CollectiveAttributes, or directly in the user entry, and one that is read only and points to the enforced policy.
Still, not sure I get it. The pwdPolicySubentry is a Directory Operation
attribute, it's not meant to be managed by the user, and it should only
reflect the PP tht is in use for a user. But we can imagine that an
admin could update this value (like, using the ManageDSAIT control) to
enforce another PP. Do we need 2 AT for that ?
>
> This attribute is protected by ACI, and it doesn’t define the Password Policy, it refer to an existing policy. No security concern here.
Or the subtreeSpecification, which already defines the set of entries
that are affected by this PP, is all what we need for a set of user. Why
do we need something else ?
>
>
>
>
>>
>> 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.
>
>
> We do not replicate the config.
Ok. Then you *need* to have the subentry containing the full info, makes
sense.
Thanks !
Re: Fwd: Re: PasswordPolicy handling
Posted by Ludovic Poitou <lu...@gmail.com>.
Hi,
more comments inline below…
Ludo
--
Ludovic Poitou
http://ludopoitou.com
From: Emmanuel Lécharny <el...@gmail.com>
Reply: Apache Directory Developers List <de...@directory.apache.org>>
Date: 12 Mar 2015 at 09:18:16
To: Apache Directory Developers List <de...@directory.apache.org>>
Subject: Fwd: Re: PasswordPolicy handling
Sorry, I posted my answer on the wrong mailing list. Here it is.
-------- Message transféré --------
Return-Path: <el...@gmail.com>
Received: from [192.168.1.16]
(AMontsouris-651-1-133-240.w90-46.abo.wanadoo.fr. [90.46.56.240]) by
mx.google.com with ESMTPSA id gi9sm11809340wib.21.2015.03.12.00.33.22
for <de...@mina.apache.org> (version=TLSv1.2
cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015
00:33:22 -0700 (PDT)
Message-ID: <55...@gmail.com>
Date: Thu, 12 Mar 2015 08:33:20 +0100
From: Emmanuel Lécharny <el...@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dev <de...@mina.apache.org>
Subject: Re: PasswordPolicy handling
References: <54...@gmail.com>
<et...@lpm.local>
In-Reply-To: <et...@lpm.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Le 11/03/15 11:43, Ludovic Poitou a écrit :
>
> --
> Ludovic Poitou
> http://ludopoitou.com
>
>
> From: Emmanuel Lécharny <el...@gmail.com>
> Reply: Apache Directory Developers List <de...@directory.apache.org>>
> Date: 10 Mar 2015 at 09:23:04
> To: Apache Directory Developers List <de...@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...
I don’t think our use case is different.
We have customers that have different sets of users and want to enforce different password policies for each set.
Typically is regular users, vs administrators vs application specific accounts.
I haven’t talked with any customer that wanted to push the limits to one user, one password policy. This would be insane to manage (and stupid since there will be duplicated policies anyway).
In OpenDJ, the pwdPolicySubEntry attribute is an operational attribute that is computed and points to the Policy that is enforced for the user.
>
>
>
> 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 ?
Collective attributes are allowing us to assign the global password policies, because we do not translate them to a proper subentry with a global scope.
It also allows to have different sub-scopes pointing to a same policy. (think about an ISP that has 20 organizations, and in each, different sets of users that must have the same “Administrators” password policy. With just the subentry mechanism, adding a new organisation means that you must update the subEntry and impact all users.
With a collectiveAttribute, it can be defined in the new organisation and have no impact on the other ones.
>
> 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).
It does not contradict. It complements. We have 2 separate attributes. One to assign if needed (i.e. overwrite the global policy), which can be done with CollectiveAttributes, or directly in the user entry, and one that is read only and points to the enforced policy.
This attribute is protected by ACI, and it doesn’t define the Password Policy, it refer to an existing policy. No security concern here.
>
> 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.
We do not replicate the config.
>
> 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 !
Fwd: Re: PasswordPolicy handling
Posted by Emmanuel Lécharny <el...@gmail.com>.
Sorry, I posted my answer on the wrong mailing list. Here it is.
-------- Message transféré --------
Return-Path: <el...@gmail.com>
Received: from [192.168.1.16]
(AMontsouris-651-1-133-240.w90-46.abo.wanadoo.fr. [90.46.56.240]) by
mx.google.com with ESMTPSA id gi9sm11809340wib.21.2015.03.12.00.33.22
for <de...@mina.apache.org> (version=TLSv1.2
cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015
00:33:22 -0700 (PDT)
Message-ID: <55...@gmail.com>
Date: Thu, 12 Mar 2015 08:33:20 +0100
From: Emmanuel Lécharny <el...@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dev <de...@mina.apache.org>
Subject: Re: PasswordPolicy handling
References: <54...@gmail.com>
<et...@lpm.local>
In-Reply-To: <et...@lpm.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Le 11/03/15 11:43, Ludovic Poitou a écrit :
>
> --
> Ludovic Poitou
> http://ludopoitou.com
>
>
> From: Emmanuel Lécharny <el...@gmail.com>
> Reply: Apache Directory Developers List <de...@directory.apache.org>>
> Date: 10 Mar 2015 at 09:23:04
> To: Apache Directory Developers List <de...@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. Did I missed a step ?
>
> 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 !
Re: PasswordPolicy handling
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 12/03/15 09:11, Ashish a écrit :
> Wrong ML folks :)
Oops...
Re: PasswordPolicy handling
Posted by Ashish <pa...@gmail.com>.
Wrong ML folks :)
On Thu, Mar 12, 2015 at 1:24 PM, Kiran Ayyagari <ka...@apache.org> wrote:
> On Thu, Mar 12, 2015 at 3:33 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> Le 11/03/15 11:43, Ludovic Poitou a écrit :
>> >
>> > --
>> > Ludovic Poitou
>> > http://ludopoitou.com
>> >
>> >
>> > From: Emmanuel Lécharny <el...@gmail.com>
>> > Reply: Apache Directory Developers List <de...@directory.apache.org>>
>> > Date: 10 Mar 2015 at 09:23:04
>> > To: Apache Directory Developers List <de...@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. 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
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Fwd: PasswordPolicy handling
Posted by Kiran Ayyagari <ka...@apache.org>.
here is my reply (earlier was sent to the wrong ML)
---------- Forwarded message ----------
From: Kiran Ayyagari <ka...@apache.org>
Date: Thu, Mar 12, 2015 at 3:54 PM
Subject: Re: PasswordPolicy handling
To: dev@mina.apache.org
On Thu, Mar 12, 2015 at 3:33 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 11/03/15 11:43, Ludovic Poitou a écrit :
> >
> > --
> > Ludovic Poitou
> > http://ludopoitou.com
> >
> >
> > From: Emmanuel Lécharny <el...@gmail.com>
> > Reply: Apache Directory Developers List <de...@directory.apache.org>>
> > Date: 10 Mar 2015 at 09:23:04
> > To: Apache Directory Developers List <de...@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. 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
Re: PasswordPolicy handling
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Mar 12, 2015 at 3:33 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 11/03/15 11:43, Ludovic Poitou a écrit :
> >
> > --
> > Ludovic Poitou
> > http://ludopoitou.com
> >
> >
> > From: Emmanuel Lécharny <el...@gmail.com>
> > Reply: Apache Directory Developers List <de...@directory.apache.org>>
> > Date: 10 Mar 2015 at 09:23:04
> > To: Apache Directory Developers List <de...@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. 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
Re: PasswordPolicy handling
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/03/15 11:43, Ludovic Poitou a écrit :
>
> --
> Ludovic Poitou
> http://ludopoitou.com
>
>
> From: Emmanuel Lécharny <el...@gmail.com>
> Reply: Apache Directory Developers List <de...@directory.apache.org>>
> Date: 10 Mar 2015 at 09:23:04
> To: Apache Directory Developers List <de...@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. Did I missed a step ?
>
> 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 !
Re: PasswordPolicy handling
Posted by Ludovic Poitou <lu...@gmail.com>.
--
Ludovic Poitou
http://ludopoitou.com
From: Emmanuel Lécharny <el...@gmail.com>
Reply: Apache Directory Developers List <de...@directory.apache.org>>
Date: 10 Mar 2015 at 09:23:04
To: Apache Directory Developers List <de...@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.
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.
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.
We have a specific operational attribute that one can set to assign a password policy to a user (ds-pwp-password-policy-dn).
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.
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.
I hope this helps.
Ludo