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
