Answers inline below... On Tue, Jul 25, 2017 at 5:26 PM, Tristan Evans <azurepanc...@gmail.com> wrote:
> 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 > ^^^ driver = ldap needs to be set in your domain file, but is missing from your sample below. > > 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? > That's right, but once you set it up with default in mysql and your domain in LDAP you can troubleshoot the second domain unencumbered. I will say there is some tradeoff in that you must now specify a domain for everything you do, including logging in to Horizon. You'll need to enable "OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True", in /etc/openstack_dashboard/local_settings, replace /etc/keystone/policy.json with the v3cloudsample one, entering in the domain of your global admin user, and also replace /etc/openstack_dashboard/keystone-policy.json with the same file. > 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... > In the CLI you need to specify --domain for most things. For Horizon, see above :) > Thanks again. > > On Tue, Jul 25, 2017 at 4:30 PM, Erik McCormick < > emccorm...@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 <azurepanc...@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@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