Open Stack

RIght now I think the LDAP queries are limited to one level of the 
Subtree,  but actually it might be possible to loosen this up, and thus 
get subtree queries.


For example, if you look at the implementation of keystone/common/ 
ldap/core.py,  you can see that most of the queries are like this:

  return conn.search_s(self.tree_dn, ldap.SCOPE_ONELEVEL, query)

But I know of no reason that they should be limited to 
ldap.SCOPE_ONELEVEL.  At a minimum,  we might be able to make this a 
configuration value,  but I suspect that expanding this to 
SCOPE_SUBTREE.  Would you be interested in testing that change out?



On 05/22/2012 08:32 PM, Kuo Hugo wrote:
> Thanks for your quick reply .
>
> I'll review the necessary of subtree query .
>
> It's really depends on user's demand. I did some more research of AD 
> or LDAP structure design.
>
> I found that if an enterprise has an existing AD server and the 
> structure as follow
>
> dc=foo,dc=com
>    |__OU-HR
>    |         |_cn:hr-user1
>    |         |_cn:hr-user2
>    |         |_cn:hr-user3
>    |
>    |__OU-IT
>              |_cn:it-user1
>              |_cn:it-user2
>              |_cn:it-user3
>
> For such LDAP structure , only HR or IT users cound be validated .
>
> Is there any exist approach within LDAP to  import users from an OU to 
> another OU like below's diagram
>
>
> dc=foo,dc=com
>    |__OU-HR
>    |         |_cn:hr-user1
>    |         |_cn:hr-user2
>    |         |_cn:hr-user3
>    |
>    |__OU-IT
>    |         |_cn:it-user1
>    |         |_cn:it-user2
>    |         |_cn:it-user3
>    |
>    |
>    |__OU-Keystone-Users
>                     |_cn:it-user1
>                     |_cn:hr-user1
>
> If so , I can specify user_tree_dn to ou=OU-Keystone-Users .
> any suggestions ?
>
> Cheers
>
>
> 2012/5/22 Adam Young <ayoung at redhat.com <mailto:ayoung at redhat.com>>
>
>     On 05/22/2012 07:07 AM, Kuo Hugo wrote:
>>     Hi Folks ,
>>
>>     I have try with keystone backend by LDAP and Windows AD.
>>
>>     It looks fine . Just want to clarify one point.
>>
>>     For my test result , LDAP driver could only validate users in the
>>     particular container (OU,CN etc.)  and does not include the
>>     subtree users.
>>
>>     [ldap]
>>     tree_dn = dc=taiwan,dc=com
>>     user_tree_dn = ou=foo,dc=taiwan,dc=com
>>
>>
>>     For example ....
>>                     User1 :  cn=jeremy,ou=foo,dc=taiwan,dc=com
>>
>>                     User2 :  cn=jordan,ou=bar,ou=foo,dc=taiwan,dc=com
>>     User1 could be validated , and get the token generated by keystone.
>>     User2 could not be validated
>>
>>
>>     Is there any way to validate both User1 and User2  in current
>>     design ?
>
>     No, there is not.  Queries are not done against subtrees.
>
>     If this is important to you,  please file a ticket:
>     https://bugs.launchpad.net/keystone/+filebug
>
>
>
>>
>>
>>     -- 
>>     +Hugo Kuo+
>>     tonytkdk at gmail.com
>>     <mailto:tonytkdk at gmail.com>
>>     + <mailto:tonytkdk at gmail.com>886 935004793
>>
>>
>>
>>     _______________________________________________
>>     Mailing list:https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     Post to     :openstack at lists.launchpad.net  <mailto:openstack at lists.launchpad.net>
>>     Unsubscribe :https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     More help   :https://help.launchpad.net/ListHelp
>
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack at lists.launchpad.net
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> -- 
> +Hugo Kuo+
> tonytkdk at gmail.com
> <mailto:tonytkdk at gmail.com>
> + <mailto:tonytkdk at gmail.com>886 935004793
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120523/5205460b/attachment.html>