← Back to team overview

openstack team mailing list archive

Re: Help with keystone LDAP backend

 

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@xxxxxxx <mailto:spresse1@xxxxxxx>> 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@xxxxxxx
    <mailto:spresse1@xxxxxxx>> 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@xxxxxxx <mailto:spresse1@xxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
            <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
            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@xxxxxxxxxxxxxxxxxxx  <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxxxxxx
        <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxxxxxx
    <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~openstack
    <https://launchpad.net/%7Eopenstack>
    More help   : https://help.launchpad.net/ListHelp



Follow ups

References