The answer would appear to be that this flag doesn't do anything in the
Folsom release. Apprently this was fixed by:
https://bugs.launchpad.net/keystone/+bug/1122181
Unless I'm misreading something. Could we perhaps update the docs to
reflect the fact that this isn't available in releases yet?
On 03/04/2013 04:08 PM, Steven Presser wrote:
This is what came out of my logs. I've bolded what looks relevant to me:
LDAP init: url=ldap://typhon.acm.jhu.edu
2013-03-04 16:06:01 DEBUG [keystone.common.ldap.core] LDAP bind:
dn=cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
2013-03-04 16:06:01 DEBUG [keystone.common.ldap.core] LDAP search:
dn=ou=Users,ou=OpenStack,dc=acm,dc=jhu,dc=edu, *scope=1*,
query=(objectClass=inetOrgPerson)
Unless I'm reading that very wrong, my scope search request is being
ignored. Time to dive into the code, I suppose.
Steve
On 03/04/2013 10:15 AM, Dolph Mathews wrote:
I'd suggest enabling debug=True in keystone.conf and comparing the
LDAP queries being issued (shown in logs) against what you're expecting.
I believe that [ldap] query_scope=sub does in fact expand queries to
apply to subtrees, beyond just a single level (as the default value
is query_scope=one).
-Dolph
On Sun, Mar 3, 2013 at 12:05 PM, Steven Presser <spres...@jhu.edu
<mailto:spres...@jhu.edu>> wrote:
Hey all,
I have some questions about using the LDAP backend for
keystone. I'm in what seems to be an odd situation. I have an
organization-wide DLAP directory that already exists. All of our
users will have access to OpenStack, so we want to tie directly
into this directory. However, we can't have service accounts
mixed in with the regular users, at least not in any way that
might result in you being able to log in to a service account.
For neatness, the directory admin would prefer that all the
OpenStack stuff be off in its own OU (and has allocated us one so
we can do that).
In that OU, I've set up the recommended schema from
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html
(changing it to my domain, obviously). I then aliased all our
users in to ou=Users. The relevant part of my keystone.conf
currently looks like:
[ldap]
url = ldap://[host]
user = cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
password = [password]
suffix = dc=acm,dc=jhu,dc=edu
use_dumb_member = False
allow_subtree_delete = False
query_scope = sub
As near as I can tell, this should correspond to this query:
$ ldapsearch -x -D cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu -w
[password] -b dc=acm,dc=jhu,dc=edu '(objectclass=inetOrgPerson)'
-s sub
Which returns my aliased users correctly. (that is, it returns
"dn: uid=[uid],ou=People,dc=acm,dc=jhu,dc=edu" for each user).
I really can't figure out whats going on here. Logically, this
should work, but (obviously) doesn't. Anyone have some advice
for me? My suspicion is that query_scope=sub isn't doing what I
expect. (Returning search results from within a subtree)
Oh, finally, I have DEREF always enabled in ldap.conf.
Thanks,
Steve
_______________________________________________
Mailing list: https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
Post to : openstack@lists.launchpad.net
<mailto:openstack@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
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp