Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 058DE10147 for ; Wed, 11 Mar 2015 08:41:01 +0000 (UTC) Received: (qmail 90951 invoked by uid 500); 11 Mar 2015 08:41:00 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 90899 invoked by uid 500); 11 Mar 2015 08:41:00 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 90889 invoked by uid 99); 11 Mar 2015 08:41:00 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Mar 2015 08:41:00 +0000 Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 2B7D21A02C0 for ; Wed, 11 Mar 2015 08:41:00 +0000 (UTC) Received: by labgd6 with SMTP id gd6so7150884lab.6 for ; Wed, 11 Mar 2015 01:40:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.183.165 with SMTP id en5mr34664572lac.0.1426063257829; Wed, 11 Mar 2015 01:40:57 -0700 (PDT) Reply-To: elecharny@apache.org Received: by 10.25.89.200 with HTTP; Wed, 11 Mar 2015 01:40:57 -0700 (PDT) In-Reply-To: References: <54FEA9C9.1070509@gmail.com> Date: Wed, 11 Mar 2015 09:40:57 +0100 Message-ID: Subject: Re: PasswordPolicy handling From: Emmanuel Lecharny To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001a1134573ce908c00510ff39ed --001a1134573ce908c00510ff39ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 a =C3=A9crit : > > > On Tue, Mar 10, 2015 at 4:22 PM, Emmanuel L=C3=A9charny > 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=3Djsmith,ou=3Dusers,ou=3Dint,o=3Dcompany >> uid: jsmith >> cn: jsmith >> ... >> pwdPolicySubEntry: >> ads-pwdId=3DinternalUsers,ou=3DpasswordPolicies,ads-interceptorId=3Dauth= enticationInterceptor,ou=3Dinterceptors,adsdirectoryServiceId=3Ddefault,ou= =3Dconfig >> >> 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, a= nd >> 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=3Dconfig 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 on= ly >> 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 i= n > 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 > --=20 Regards, Cordialement, Emmanuel L=C3=A9charny www.iktek.com --001a1134573ce908c00510ff39ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's totally manageable. We just have to refer to the PP DN in the su= bentry.=C2=A0

Still we jave to add the subentry DN in th= e PP cinfig entry to remember where the PP subentry has to be injected at s= tartup.

Le=C2=A0mardi 10 mars 2015, Kiran Ayyagari <= kayyagari@apache.org> a =C3= =A9crit=C2=A0:


On Tue, Mar 10, 2015 a= t 4:22 PM, Emmanuel L=C3=A9charny <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=3Djsmith,ou=3Dusers,ou=3Dint,o=3Dcompany
uid: jsmith
cn: jsmith
...
pwdPolicySubEntry: ads-pwdId=3DinternalUsers,ou=3DpasswordPolicies,ads-inte= rceptorId=3DauthenticationInterceptor,ou=3Dinterceptors,adsdirectoryService= Id=3Ddefault,ou=3Dconfig

No need to say that it's extremelly heavy when you have thousands of us= ers.

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 a= dding to an LDAP subentry whose immediate superior is the root of the subtr= ee"

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 t= o 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=3Dconfig 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 administrat= e 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 f= ew 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 :
=C2=A0 - 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)
=C2=A0 - we remove the PP declaration in the config
=C2=A0 (I personally find the first approach more appealing, as it allows u= sers 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 s= ubentry update the config. Not exactly simple...).
let= us not even do that, just have the DN of password policy be present in thi= s subentry
and currently server has necessary mechanism to pi= ckup the effective policy.=C2=A0
- we most certainly have to define a new administrative role for PP, and ha= ndle 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= =C3=A9charny
www.iktek.com
--001a1134573ce908c00510ff39ed--