[Openstack] Help with keystone LDAP backend

Steven Presser spresse1 at jhu.edu
Mon Mar 4 22:40:10 UTC 2013


Anne,
     Yes that would.  What I think might be a better revision is putting 
the version somewhere prominently on the page (say, the upper right hand 
corner, above "<prev|up|next>").

Steve

On 03/04/2013 05:26 PM, Anne Gentle wrote:
> I've been wondering whether we should have docs.openstack.org/master/ 
> <http://docs.openstack.org/master/> to match expectations, would that 
> have helped in your case? Thanks for clarifying.
>
> Anne
>
>
> On Mon, Mar 4, 2013 at 4:22 PM, Steven Presser <spresse1 at jhu.edu 
> <mailto:spresse1 at jhu.edu>> wrote:
>
>     Apparently the trunk docs.  I could have sworn that wasn't what I
>     bookmarked.  In any case, maybe explicitly marking trunk docs as
>     newer-than-latest would help?
>
>     (
>     http://docs.openstack.org/trunk/openstack-compute/admin/content/reference-for-ldap-config-options.html)
>
>
>
>     On 03/04/2013 05:09 PM, Dolph Mathews wrote:
>>     Yes, this feature just landed during grizzly-m3.
>>
>>     Which docs are you referring to? The variable wasn't included in
>>     folsom's etc/keystone.conf.sample, for example.
>>
>>
>>     -Dolph
>>
>>
>>     On Mon, Mar 4, 2013 at 3:35 PM, Steven Presser <spresse1 at jhu.edu
>>     <mailto:spresse1 at jhu.edu>> wrote:
>>
>>         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  <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
>>
>>
>
>     _______________________________________________
>     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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130304/2c964734/attachment.html>


More information about the Openstack mailing list