Open Stack

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