Open Stack

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!