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:jamesze...@gmail.com] > Sent: Wednesday, January 22, 2014 7:23 AM > To: Miller, Mark M (EB SW Cloud - R&D - Corvallis) > Cc: openstack@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.mil...@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:jamesze...@gmail.com] > >> Sent: Tuesday, January 21, 2014 2:37 PM > >> To: openstack@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@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 | > >> l...@blah.com | > >> | LDAP User 2 | lu2 | True | > >> l...@blah.com | > >> | LDAP User 3 | lu3 | True | > >> l...@blah.com | > >> | ... | ... | ... | > >> ... | > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+---- > >> +-----------------------------------+-----------------+---------+-- > >> --+ > >> root@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@lists.openstack.org > >> Unsubscribe : > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
