Open Stack

Answers inline below...

On Tue, Jul 25, 2017 at 5:26 PM, Tristan Evans <azurepancake at 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 <
> 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/3c46898e/attachment.html>