Open Stack

I ran into problems when I tested it and filed a bug against it.
 
https://bugs.launchpad.net/keystone/+bug/1218094

Mark


> -----Original Message-----
> From: James [mailto:jameszee13 at gmail.com]
> Sent: Wednesday, January 22, 2014 7:23 AM
> To: Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> Cc: openstack at lists.openstack.org
> Subject: Re: [Openstack] ldap + sql in keystone (multi-domain)
> 
> Mark,
> 
> I was afraid someone would say that.
> 
> I did read that this was only "half-baked" in Havana with potential bugs, but
> unless I've configured something incorrectly it seems that the domain
> functionality doesn't work at all. Are we certain that LDAP / SQL multi-domain
> environment is _not_ ready for Havana?
> 
> Thanks!
> 
> On Tue, Jan 21, 2014 at 6:19 PM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis) <mark.m.miller at hp.com> wrote:
> > This feature didn't quite make it into the Havana code base in that it still
> had a few bugs. I will be interested to see if it was fixed for Icehouse.
> >
> > Mark
> >
> >> -----Original Message-----
> >> From: James [mailto:jameszee13 at gmail.com]
> >> Sent: Tuesday, January 21, 2014 2:37 PM
> >> To: openstack at lists.openstack.org
> >> Subject: [Openstack] ldap + sql in keystone (multi-domain)
> >>
> >> All,
> >>
> >> I'm trying to get multiple domains configured in keystone so that
> >> users can authenticate against LDAP, but service accounts can use
> >> locally-created, SQL- based accounts.
> >>
> >> I've set up keystone.conf as follows:
> >>
> >>
> >> -->8--
> >>
> >> [DEFAULT]
> >> admin_token = ADMIN
> >> debug = True
> >> verbose = True
> >> log_file = keystone.log
> >> log_dir = /var/log/keystone
> >> use_syslog = True
> >> [sql]
> >> connection = sqlite:////var/lib/keystone/keystone.db
> >> [identity]
> >> driver = keystone.identity.backends.sql.Identity
> >> default_domain_id = default
> >> domain_specific_drivers_enabled = True domain_config_dir =
> >> /etc/keystone/domains [credential] driver =
> >> keystone.credential.backends.sql.Credential
> >> [trust]
> >> driver = keystone.trust.backends.sql.Trust [os_inherit] [catalog]
> >> driver = keystone.catalog.backends.sql.Catalog
> >> [endpoint_filter]
> >> [token]
> >> driver = keystone.token.backends.sql.Token [cache] [policy] driver =
> >> keystone.policy.backends.sql.Policy
> >> [ec2]
> >> driver = keystone.contrib.ec2.backends.kvs.Ec2
> >> [assignment]
> >> [oauth1]
> >> [ssl]
> >> [signing]
> >> [ldap]
> >> [auth]
> >> methods = external,password,token,oauth1 password =
> >> keystone.auth.plugins.password.Password
> >> token = keystone.auth.plugins.token.Token
> >> oauth1 = keystone.auth.plugins.oauth1.OAuth
> >> [paste_deploy]
> >> config_file = keystone-paste.ini
> >>
> >> --8<--
> >>
> >>
> >> /etc/keystone/domains/keystone.ldap.conf is configured as follows:
> >>
> >>
> >> -->8--
> >>
> >> [identity]
> >> driver = keystone.identity.backends.ldap.Identity
> >> [assignment]
> >> driver = keystone.assignment.backends.sql.Assignment
> >> [ldap]
> >> url = ldap://ldap_server:389
> >> user_tree_dn = dc=blah,dc=com
> >> user_objectclass = person
> >> user_pass_attribute =
> >> user_id_attribute = cn
> >> user_enabled_attribute = userAccountControl user_enabled_mask = 2
> >> user_enabled_default = 512 user_mail_attribute = mail
> >> user_name_attribute = sAMAccountName user_filter =
> >> (memberof=CN=blah,DC=blah,DC=com) user = username password =
> password
> >> use_dumb_member = True dumb_member = keystone_ldap page_size =
> 0
> >> alias_dereferencing = always query_scope = sub user_allow_create =
> >> False user_allow_update = False user_allow_delete = False
> >>
> >> --8<--
> >>
> >>
> >> Super simple configuration. The issue I'm running into is with using
> >> the v3 APIs. Take a look at the example below:
> >>
> >>
> >> -->8--
> >>
> >> ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"
> >> --os-username admin --os-password 'admin' --os-identity-api-version 3
> >> --os- domain-id=default domain list
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+---------
> >> -----------------------------------+
> >> | ID                               | Name    | Enabled | Description
> >>                                                        |
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+---------
> >> -----------------------------------+
> >> | default                          | Default | True    | Owns users
> >> and tenants (i.e. projects) available on Identity API v2. |
> >> | 89a6bbbdd13543739d602d2e6e9bebda | ldap    | True    | Active
> >> Directory Authentication (via LDAP)                           |
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+-------------
> >> +----------------------------------+---------+---------+---------
> >> -----------------------------------+
> >>
> >> ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"
> >> --os-username admin --os-password 'admin' --os-identity-api-version 3
> >> --os- domain-id=default user list
> >> +----------------------------------+--------+
> >> | ID                               | Name   |
> >> +----------------------------------+--------+
> >> | d8a47a119650484ca7eebe7a379bdaab | admin  |
> >> | 7f3da3ec686dbdda837d91485fc28e7e | test   |
> >> +----------------------------------+--------+
> >>
> >> ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"
> >> --os-username admin --os-password 'admin' --os-identity-api-version 3
> >> --os- domain-id=89a6bbbdd13543739d602d2e6e9bebda user list
> >> +----------------------------------+--------+
> >> | ID                               | Name   |
> >> +----------------------------------+--------+
> >> | d8a47a119650484ca7eebe7a379bdaab | admin  |
> >> | 7f3da3ec686dbdda837d91485fc28e7e | test   |
> >> +----------------------------------+--------+
> >>
> >> --8<--
> >>
> >>
> >> Note the 'user list' output returned in the last API call. Because
> >> we're explicitly setting the LDAP domain, the user list should come
> >> from LDAP (not our local sqlite database). Debug output shows that
> >> keystone sees the LDAP domain configuration in
> >> /etc/keystone/domains/keystone.ldap.conf, but it never actually makes
> an LDAP bind request.
> >>
> >> Debug logs can be found at: http://pastebin.com/eG2XxVEd
> >>
> >> Interestingly enough, however, if the default_domain_id in
> >> /etc/keystone/keystone.conf points to our LDAP domain
> >> (default_domain_id = 89a6bbbdd13543739d602d2e6e9bebda), then a
> >> *version 2.0* API call to keystone will return our LDAP user list
> >> (see below), which indicates that the LDAP and multi-domain
> >> configuration is likely correct.
> >>
> >>
> >> -->8--
> >>
> >> root at keystone:/etc/keystone# keystone user-list
> >> WARNING: Bypassing authentication using a token & endpoint
> >> (authentication credentials are being ignored).
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+--
> >> --+
> >> |                 id                |       name      | enabled |
> >>      email            |
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+--
> >> --+
> >> |            LDAP User 1            |     lu1         |   True  |
> >> lu1 at blah.com            |
> >> |            LDAP User 2            |     lu2         |   True  |
> >> lu2 at blah.com            |
> >> |            LDAP User 3            |     lu3         |   True  |
> >> lu3 at blah.com            |
> >> |               ...                 |       ...       |   ...   |
> >>      ...              |
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+----
> >> +-----------------------------------+-----------------+---------+--
> >> --+
> >> root at keystone:/etc/keystone#
> >>
> >> -8<-
> >>
> >>
> >> Again, the end-goal here is to have service accounts defined locally
> >> (via SQL) since our corporate LDAP environment doesn't have a
> >> mechanism by which we can add OpenStack service accounts.
> >>
> >> Any help or thoughts would be greatly appreciated.
> >>
> >> Thanks!
> >>
> >> _______________________________________________
> >> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >> Post to     : openstack at lists.openstack.org
> >> Unsubscribe :
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack