<div dir="ltr">Answers inline below...<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 5:26 PM, Tristan Evans <span dir="ltr"><<a href="mailto:azurepancake@gmail.com" target="_blank">azurepancake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>Hey Erik,</p>
<p>The funny thing is that LDAP authentication works fine as an identity backend until I move the "[ldap]" configuration into
<span>"/etc/keystone/domains</span>/<span>keyston<wbr>e.Default.conf</span>" and enable the below in "/etc/keystone/keystone.conf":</p><span class="gmail-">
<p>[identity]<br>
domain_specific_drivers_<wbr>enabled = True<br>
domain_config_dir = /etc/keystone/domains</p>
</span><p>#driver = ldap</p></div></blockquote><div><span style="font-size:13.3333px">^^^ driver = ldap needs to be set in your domain file, but is missing from your sample below. </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p><font size="2"><span style="font-size:10pt"><br></span></font></p><p><font size="2"><span style="font-size:10pt">Once that is setup and httpd is restarted, Keystone logs nothing, but 500 errors for all requests..<br></span></font></p><p><font size="2"><span style="font-size:10pt"></span></font>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_<wbr>enabled" is set to
"false".</p>
<p>Regardless, I'm very new to this stuff so I could totally be wrong, so here is my LDAP config
<span>😊</span></p>
<div>[ldap]<br>url = ldap://<a href="http://domain.net" target="_blank">domain.net</a><br>user = CN=adquery,OU=LinuxAccts,OU=<wbr>UserAccounts,OU=USACAN,OU=<wbr>NorthAmerica,OU=Global,DC=<wbr>DOMAIN,DC=NET<br>password =password<br>suffix = DC=domain,DC=net<br>query_scope = sub<br>use_pool = true<br>use_auth_pool = true<br>user_tree_dn = OU=UserAccounts,OU=USACAN,OU=<wbr>NorthAmerica,OU=Global,DC=<wbr>DOMAIN,DC=NET<br>user_objectclass = person<br>user_filter = (memberOf=CN=OpenStackAdmins,<wbr>OU=OpenStackGroups,OU=<wbr>UserAccounts,OU=USACAN,OU=<wbr>NorthAmerica,OU=Global,DC=<wbr>DOMAIN,DC=NET)<br>user_id_attribute = sAMAccountName<br>user_name_attribute = sAMAccountName<br>user_mail_attribute = mail<br>user_pass_attribute = userPassword<br>user_enabled_attribute = userAccountControl<br>user_enabled_mask = 2<br>user_enabled_invert = false<br>user_enabled_default = 512<br>user_default_project_id_<wbr>attribute =<br>user_additional_attribute_<wbr>mapping =<br>group_tree_dn = OU=OpenStackGroups,OU=<wbr>UserAccounts,OU=USACAN,OU=<wbr>NorthAmerica,OU=Global,DC=<wbr>DOMAIN,DC=NET<br>group_objectclass = group<br>group_id_attribute = cn<br>group_name_attribute = name<br>group_member_attribute = member<br>user_allow_create = False<br>user_allow_update = False<br>user_allow_delete = False<br>group_allow_create = False<br>group_allow_update = False<br>group_allow_delete = False<br></div>
<p>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?</p></div></blockquote><div>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. </div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>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...</p></div></blockquote><div>In the CLI you need to specify --domain for most things. For Horizon, see above :) <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>Thanks again.<br></p></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 4:30 PM, Erik McCormick <span dir="ltr"><<a href="mailto:emccormick@cirrusseven.com" target="_blank">emccormick@cirrusseven.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can't tell you too much about why Heat and Magnum need their own<br>
domains (something to do with Trusts and necessary admin rights).<br>
<br>
In terms of the LDAP connection being broken, it would help to see<br>
your domain config file. Also did you create all of the users in the<br>
LDAP domain as they were in the mysql one?<br>
<br>
One other comments: It's really not a great idea to host the default<br>
domain in LDAP unless you've got a pretty robust HA LDAP setup. If<br>
anything goes haywire with your LDAP server, then none of your service<br>
accounts will be able to authenticate and everything will go boom. You<br>
would be better off leaving Default as your service domain and<br>
creating another one for your users in LDAP.<br>
<br>
Cheers,<br>
Erik<br>
<div><div class="gmail-m_-4049288720949958768h5"><br>
On Tue, Jul 25, 2017 at 11:49 AM, Tristan Evans <<a href="mailto:azurepancake@gmail.com" target="_blank">azurepancake@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I am running OpenStack Ocata that as originally provisioned using RDO<br>
> Packstack.<br>
><br>
> I currently have Keystone configured to use a single identity backend which<br>
> is LDAP. Everything works great with this configuration except Heat and<br>
> Magnum. Through some troubleshooting, it appears the problem may be that<br>
> these services operate within their own domains ("heat" and "magnum"<br>
> respectively). This results in errors like the below (in keystone.log) when<br>
> trying to build a cluster with Magnum:<br>
><br>
> 2017-07-20 11:12:22.509 7494 ERROR<br>
> magnum.conductor.handlers.comm<wbr>on.trust_manager Failed to create trustee and<br>
> trust for Cluster<br>
> 2017-07-20 11:12:22.509 7494 ERROR<br>
> magnum.conductor.handlers.comm<wbr>on.trust_manager NotFound: Could not find<br>
> domain: f950f5d49d8f4acba4790113580a95<wbr>6f. (HTTP 404)<br>
><br>
> I also caught the below as well:<br>
><br>
> 2017-07-20 10:32:24.122 20553 WARNING keystone.identity.core Found multiple<br>
> domains being mapped to a driver that does not support that (e.g. LDAP)<br>
> 2017-07-20 10:32:24.122 20553 WARNING keystone.common.wsgi Could not find<br>
> domain: f950f5d49d8f4acba4790113580a95<wbr>6f.<br>
><br>
> The domain does indeed exist:<br>
><br>
> # openstack domain list<br>
> 90a99943256b4a22a5c51352d428a7<wbr>e5 | heat | True<br>
> default | Default | True | The default domain<br>
> f950f5d49d8f4acba4790113580a95<wbr>6f | magnum | True<br>
><br>
> So through some research, I found that I can configure the below settings in<br>
> keystone.conf to choose specific drivers for specific domains:<br>
><br>
> [identity]<br>
> domain_specific_drivers_enable<wbr>d = True<br>
> domain_config_dir = /etc/keystone/domains<br>
><br>
> And then migrate my entire "[ldap]" configuration as<br>
> /etc/keystone/domains/keystone<wbr>.Default.conf.<br>
><br>
> I then restart httpd and attempt to list domains:<br>
><br>
> # openstack domain list<br>
> An unexpected error prevented the server from fulfilling your request. (HTTP<br>
> 500) (Request-ID: req-9d64587c-8bda-401b-83df-a0<wbr>c166ea629b)<br>
><br>
> If I look up that request ID in the log:<br>
><br>
> 2017-07-20 14:36:46.828 2621 DEBUG keystone.middleware.auth<br>
> [req-9d64587c-8bda-401b-83df-a<wbr>0c166ea629b - - - - -] There is either no auth<br>
> token in the request or the certificate issuer is not trusted. No auth<br>
> context will be set. fill_context<br>
> /usr/lib/python2.7/site-packag<wbr>es/keystone/middleware/auth.<wbr>py:188<br>
> 2017-07-20 14:36:46.829 2621 INFO keystone.common.wsgi<br>
> [req-9d64587c-8bda-401b-83df-a<wbr>0c166ea629b - - - - -] POST<br>
> <a href="http://10.11.184.50:5000/v3/auth/tokens" rel="noreferrer" target="_blank">http://10.11.184.50:5000/v3/au<wbr>th/tokens</a><br>
> 2017-07-20 14:36:46.848 2621 WARNING keystone.common.wsgi<br>
> [req-9d64587c-8bda-401b-83df-a<wbr>0c166ea629b - - - - -] An unexpected error<br>
> prevented the server from fulfilling your request.<br>
><br>
> I can't seem to find any other interesting errors in keystone.log. The above<br>
> just repeats over and over for each service attempting to authenticate.<br>
><br>
> If I remove the "domain_specific_drivers_enabl<wbr>ed" and "domain_config_dir"<br>
> options from keystone.conf (with my "[ldap]" configurations removed as<br>
> well), I can then successfully authenticate using MySQL for identity.<br>
><br>
> I'm at a total loss on what may be wrong, and confused as to why Heat and<br>
> Magnum need their own domains. Would anyone be able to help point me in the<br>
> right direction?<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k</a><br>
> Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k</a><br>
><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>