[Openstack] Help with keystone LDAP backend
Steven Presser
spresse1 at jhu.edu
Mon Mar 4 21:35:57 UTC 2013
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 <spresse1 at jhu.edu
>> <mailto:spresse1 at 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 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
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130304/f3022080/attachment.html>
More information about the Openstack
mailing list