directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Fwd: Re: PasswordPolicy handling
Date Thu, 12 Mar 2015 11:32:27 GMT
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 <elecharny@gmail.com>  
>> Reply: Apache Directory Developers List <dev@directory.apache.org>>  
>> Date: 10 Mar 2015 at 09:23:04  
>> To: Apache Directory Developers List <dev@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 !


Mime
View raw message