directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Fwd: PasswordPolicy handling
Date Thu, 12 Mar 2015 08:21:20 GMT
here is my reply (earlier was sent to the wrong ML)
---------- Forwarded message ----------
From: Kiran Ayyagari <kayyagari@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 <elecharny@gmail.com>
wrote:

> 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...
>
> >
> >
> >
> > 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

Mime
View raw message