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 <[email protected]> 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 <[email protected]> > 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 : [email protected] > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
