[Openstack] Keystone: domain_specific_drivers_enabled not working with LDAP

Tristan Evans azurepancake at gmail.com
Tue Jul 25 21:26:41 UTC 2017


Hey Erik,

The funny thing is that LDAP authentication works fine as an identity
backend until I move the "[ldap]" configuration into "/etc/keystone/domains/
keystone.Default.conf" and enable the below in
"/etc/keystone/keystone.conf":

[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

#driver = ldap

Once that is setup and httpd is restarted, Keystone logs nothing, but 500
errors for all requests..

I did need to create all the service users in the LDAP domain originally to
get this to work, as well as assign them to the correct projects and roles.
This makes me think it's not a LDAP configuration per se, as it works with
the same configuration, as long as it's in "keystone.conf" and that the
"domain_specific_drivers_enabled" is set to "false".

Regardless, I'm very new to this stuff so I could totally be wrong, so here
is my LDAP config 😊
[ldap]
url = ldap://domain.net
user =
CN=adquery,OU=LinuxAccts,OU=UserAccounts,OU=USACAN,OU=NorthAmerica,OU=Global,DC=DOMAIN,DC=NET
password =password
suffix = DC=domain,DC=net
query_scope = sub
use_pool = true
use_auth_pool = true
user_tree_dn =
OU=UserAccounts,OU=USACAN,OU=NorthAmerica,OU=Global,DC=DOMAIN,DC=NET
user_objectclass = person
user_filter =
(memberOf=CN=OpenStackAdmins,OU=OpenStackGroups,OU=UserAccounts,OU=USACAN,OU=NorthAmerica,OU=Global,DC=DOMAIN,DC=NET)
user_id_attribute = sAMAccountName
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_pass_attribute = userPassword
user_enabled_attribute = userAccountControl
user_enabled_mask = 2
user_enabled_invert = false
user_enabled_default = 512
user_default_project_id_attribute =
user_additional_attribute_mapping =
group_tree_dn =
OU=OpenStackGroups,OU=UserAccounts,OU=USACAN,OU=NorthAmerica,OU=Global,DC=DOMAIN,DC=NET
group_objectclass = group
group_id_attribute = cn
group_name_attribute = name
group_member_attribute = member
user_allow_create = False
user_allow_update = False
user_allow_delete = False
group_allow_create = False
group_allow_update = False
group_allow_delete = False

I like your suggestion in regards to just using LDAP for my users. However,
this would be dependent on the above setting (enabling specific drivers per
domain) which seems to be giving me problems, right? In that example,
Keystone would need to use the SQL driver for the "Default" domain for
services and use the LDAP driver for the user domain?

I just realized I'm not even sure how Keystone figures out which domain to
try and authenticate against for a particular account. Sine kind of
prioritization? I think I need to do some more reading...

Thanks again.

On Tue, Jul 25, 2017 at 4:30 PM, Erik McCormick <emccormick at cirrusseven.com>
wrote:

> I can't tell you too much about why Heat and Magnum need their own
> domains (something to do with Trusts and necessary admin rights).
>
> In terms of the LDAP connection being broken, it would help to see
> your domain config file. Also did you create all of the users in the
> LDAP domain as they were in the mysql one?
>
> One other comments: It's really not a great idea to host the default
> domain in LDAP unless you've got a pretty robust HA LDAP setup. If
> anything goes haywire with your LDAP server, then none of your service
> accounts will be able to authenticate and everything will go boom. You
> would be better off leaving Default as your service domain and
> creating another one for your users in LDAP.
>
> Cheers,
> Erik
>
> On Tue, Jul 25, 2017 at 11:49 AM, Tristan Evans <azurepancake at gmail.com>
> wrote:
> > Hi,
> >
> > I am running OpenStack Ocata that as originally provisioned using RDO
> > Packstack.
> >
> > I currently have Keystone configured to use a single identity backend
> which
> > is LDAP. Everything works great with this configuration except Heat and
> > Magnum. Through some troubleshooting, it appears the problem may be that
> > these services operate within their own domains ("heat" and "magnum"
> > respectively). This results in errors like the below (in keystone.log)
> when
> > trying to build a cluster with Magnum:
> >
> > 2017-07-20 11:12:22.509 7494 ERROR
> > magnum.conductor.handlers.common.trust_manager Failed to create trustee
> and
> > trust for Cluster
> > 2017-07-20 11:12:22.509 7494 ERROR
> > magnum.conductor.handlers.common.trust_manager NotFound: Could not find
> > domain: f950f5d49d8f4acba4790113580a956f. (HTTP 404)
> >
> > I also caught the below as well:
> >
> > 2017-07-20 10:32:24.122 20553 WARNING keystone.identity.core Found
> multiple
> > domains being mapped to a driver that does not support that (e.g. LDAP)
> > 2017-07-20 10:32:24.122 20553 WARNING keystone.common.wsgi Could not find
> > domain: f950f5d49d8f4acba4790113580a956f.
> >
> > The domain does indeed exist:
> >
> > # openstack domain list
> > 90a99943256b4a22a5c51352d428a7e5 | heat    | True
> > default                          | Default | True    | The default domain
> > f950f5d49d8f4acba4790113580a956f | magnum  | True
> >
> > So through some research, I found that I can configure the below
> settings in
> > keystone.conf to choose specific drivers for specific domains:
> >
> > [identity]
> > domain_specific_drivers_enabled = True
> > domain_config_dir = /etc/keystone/domains
> >
> > And then migrate my entire "[ldap]" configuration as
> > /etc/keystone/domains/keystone.Default.conf.
> >
> > I then restart httpd and attempt to list domains:
> >
> > # openstack domain list
> > An unexpected error prevented the server from fulfilling your request.
> (HTTP
> > 500) (Request-ID: req-9d64587c-8bda-401b-83df-a0c166ea629b)
> >
> > If I look up that request ID in the log:
> >
> > 2017-07-20 14:36:46.828 2621 DEBUG keystone.middleware.auth
> > [req-9d64587c-8bda-401b-83df-a0c166ea629b - - - - -] There is either no
> auth
> > token in the request or the certificate issuer is not trusted. No auth
> > context will be set. fill_context
> > /usr/lib/python2.7/site-packages/keystone/middleware/auth.py:188
> > 2017-07-20 14:36:46.829 2621 INFO keystone.common.wsgi
> > [req-9d64587c-8bda-401b-83df-a0c166ea629b - - - - -] POST
> > http://10.11.184.50:5000/v3/auth/tokens
> > 2017-07-20 14:36:46.848 2621 WARNING keystone.common.wsgi
> > [req-9d64587c-8bda-401b-83df-a0c166ea629b - - - - -] An unexpected error
> > prevented the server from fulfilling your request.
> >
> > I can't seem to find any other interesting errors in keystone.log. The
> above
> > just repeats over and over for each service attempting to authenticate.
> >
> > If I remove the "domain_specific_drivers_enabled" and
> "domain_config_dir"
> > options from keystone.conf (with my "[ldap]" configurations removed as
> > well), I can then successfully authenticate using MySQL for identity.
> >
> > I'm at a total loss on what may be wrong, and confused as to why Heat and
> > Magnum need their own domains. Would anyone be able to help point me in
> the
> > right direction?
> >
> >
> > _______________________________________________
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170725/410efb38/attachment.html>


More information about the Openstack mailing list