[Openstack] Keystone: domain_specific_drivers_enabled not working with LDAP

Erik McCormick emccormick at cirrusseven.com
Thu Jul 27 03:25:35 UTC 2017


Sorry for the radio silence. Too many projects at once. I'm glad you got it
worked out. In case you need it, the line in the policy.json I was
referring to was this:

"cloud_admin": "role:admin and (is_admin_project:True or
domain_id:default)",

It's the second line down. It gives you happy cross-domain god powers.
"default" in this case is the actual ID not the name, so you'd need the
UUID if the user is in your newly created domain.

Cheers,
Erik

On Wed, Jul 26, 2017 at 9:13 PM, Tristan Evans <azurepancake at gmail.com>
wrote:

> Alright, I got my domain users working!
>
> What it came down to was I had to add my "admin" account to the domain
> responsible for LDAP authentication (I had to create this domain before by
> hand with "openstack domain create":
>
> openstack role add --domain 30d0cc8521be4074bb8289f6be12f3fe --user
> dde9fdcb268a4d44a29894f37981c448 admin
>
> I can then list my LDAP accounts:
>
> openstack user list --domain odretail
> a32c0f55cb6a7562a0bf7a5aede6841636ab45b7a571dd3d5fd477dfefc26330 | temgr
>
> I then add my domain account to the admin role in the admin project:
>
> openstack role add --project admin --user a32c0f55cb6a7562a0bf7a5aede684
> 1636ab45b7a571dd3d5fd477dfefc26330 admin
>
> And that did the trick!
>
> Thanks again Erik for putting me on the right track. It was just what I
> needed.
>
> On Wed, Jul 26, 2017 at 8:25 PM, Tristan Evans <azurepancake at gmail.com>
> wrote:
>
>> Ok, just a quick update..
>>
>> I resolved my duplicate user issue by simply deleting the duplicates..
>>
>> example:
>>
>> openstack user delete neutron
>>
>> Now that I've done it, it seems incredibly obvious.. I think my brains
>> were a bit sizzled earlier ;)
>>
>> The only problem that remains now is getting the LDAP accounts access. I
>> will keep playing with that, but I'm all ears to any additional advice you
>> may have to give :)
>>
>> On Wed, Jul 26, 2017 at 1:03 PM, Tristan Evans <azurepancake at gmail.com>
>> wrote:
>>
>>> Thanks so much for helping me out here Erik. I'm making progress, but
>>> still running into a couple hang-ups. We're almost there! Also, I apologize
>>> for the some what erratic dump of info below. I'm feeling a tad
>>> overwhelmed, but trying to fight through it ;)
>>>
>>> Here are the updates I've made thus far thanks to your assistance:
>>>
>>>    1. Changed "/etc/keystone/domains/keystone.Default.conf" to
>>>    "/etc/keystone/domains/keystone.mydomain.conf".
>>>    2. Added "driver = ldap" under "[identity]" in
>>>    "/etc/keystone/domains/keystone.mydomain.conf".
>>>    3. Set "OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True" in
>>>    /etc/openstack_dashboard/local_settings.
>>>    4. Replaced "/etc/keystone/policy.json" and
>>>    "/etc/openstack_dashboard/keystone-policy.json" with the
>>>    v3cloudsample version (got it from OpenStack GitHub). Though I'm not
>>>    exactly sure where I put that domain in this file?
>>>    5. Restarted httpd.
>>>
>>> OK, so now let's first test the local "admin" account. I navigate to the
>>> Horizon dashboard, enter in the domain "Default", the username "admin", and
>>> the password. This actually lets me log in! However, I can't get
>>> information from any other services. For example, selecting "Instances"
>>> results in a "Unable to retrieve instances". To troubleshoot this, I
>>> focused on a relatively "simpler" service like Glance.
>>>
>>> When attempting to list images, it logs the below:
>>>
>>> 2017-07-26 09:14:23.009 4296 WARNING keystonemiddleware.auth_token [-]
>>> Identity response: {"error": {"message": "The request you have made
>>> requires authentication.", "code": 401, "title": "Unauthorized"}}
>>> 2017-07-26 09:14:23.010 4296 CRITICAL keystonemiddleware.auth_token [-]
>>> Unable to validate token: Identity server rejected authorization necessary
>>> to fetch token data
>>>
>>> I also tried the below cURL:
>>>
>>> curl -i \
>>>   -H "Content-Type: application/json" \
>>>   -d '
>>> { "auth": {
>>>     "identity": {
>>>       "methods": ["password"],
>>>       "password": {
>>>         "user": {
>>>           "name": "glance",
>>>           "domain": { "id": "default" },
>>>           "password": "MyPassword"
>>>         }
>>>       }
>>>     }
>>>   }
>>> }' \
>>>   "http://localhost:5000/v3/auth/tokens" ; echo
>>>
>>> {"error": {"message": "The request you have made requires
>>> authentication.", "code": 401, "title": "Unauthorized"}}
>>>
>>> However I do recall that when I originally set this up, the passwords
>>> were configured incorrectly for a bunch of service accounts (didn't set the
>>> passwords in the Packstack answer file). So I had to update the
>>> configuration file of said services to match what I setup in LDAP. I looked
>>> at the "CONFIG_GLANCE_KS_PW" in my original answer file and attempted to
>>> authenticate with that and bingo!
>>>
>>> curl -i \
>>>   -H "Content-Type: application/json" \
>>>   -d '
>>> { "auth": {
>>>     "identity": {
>>>       "methods": ["password"],
>>>       "password": {
>>>         "user": {
>>>           "name": "glance",
>>>           "domain": { "id": "default" },
>>>           "password": "CONFIG_GLANCE_KS_PW"
>>>         }
>>>       }
>>>     }
>>>   }
>>> }' \
>>>   "http://localhost:5000/v3/auth/tokens" ; echo
>>>
>>> {"token": {"issued_at": "2017-07-26T14:51:07.000000Z", "audit_ids":
>>> ["rxLIb_6ARbeKlKV6X7S7mA"], "methods": ["password"], "expires_at":
>>> "2017-07-26T15:51:07.000000Z", "user": {"password_expires_at": null,
>>> "domain": {"id": "default", "name": "Default"}, "id":
>>> "9500dc78f7e24fe698e108537b6c9c71", "name": "glance"}}}
>>>
>>> So I can either go through all of those configs and set the passwords
>>> back, or change the passwords for the accounts:
>>>
>>> I try to update the password for the 'glance' user, however I get a
>>> "Duplicate entry" error:
>>>
>>> # openstack user set --domain default --password-prompt glance
>>> User Password:
>>> Repeat User Password:
>>> Conflict occurred attempting to store user - Duplicate entry. (HTTP 409)
>>> (Request-ID: req-fe3965b4-0962-4d9b-9a85-8966b3508650)
>>>
>>> As you see below, it appears I do have 2 of several users. Is it finding
>>> users in both LDAP and the local DB? I moved my
>>> domains/keystone_mydomain.conf file out and restarted httpd, however both
>>> users still show up. as you can see, it thinks they are all in the same
>>> "default" domain.
>>>
>>> # openstack user list --long
>>> +----------------------------------+--------------+---------
>>> -------------------------+---------+--------------------+---
>>> ---------------------------------+---------+
>>> | ID                               | Name         |
>>> Project                          | Domain  | Description        |
>>> Email                              | Enabled |
>>> +----------------------------------+--------------+---------
>>> -------------------------+---------+--------------------+---
>>> ---------------------------------+---------+
>>> | 026a2c3fab15419f90c6a95ddb803ed8 | aodh
>>> |                                  | default |                    |
>>> aodh at localhost                     | True    |
>>> | 0c19f40cb1364ebb876bfd90918dead2 | ceilometer
>>> |                                  | default |                    |
>>> ceilometer at localhost               | True    |
>>> | 11599c71ad114654b003b654e03a4e6b | neutron
>>> |                                  | default |                    |
>>> neutron at localhost                  | True    |
>>> | 170716mgr                        | 170716mgr
>>> |                                  | default |  |       | True    |
>>> | 39cc615e69824f108bc9366224f25a66 | nova
>>> |                                  | default |                    |
>>> nova at localhost                     | True    |
>>> | 44c1b20c016d41ec9ea69f667540c227 | gnocchi
>>> |                                  | default |                    |
>>> gnocchi at localhost                  | True    |
>>> | 498777mgr                        | 498777mgr
>>> |                                  | default |  |         | True    |
>>> | 646b17dc9b7c4a4d8c96fe7fde9a2a7a | swift
>>> |                                  | default |                    |
>>> swift at localhost                    | True    |
>>> | 7729a23a63824862825b2e7ed707b907 | heat-cfn
>>> |                                  | default |                    |
>>> heat-cfn at localhost                 | True    |
>>> | 783720mgrod                      | 783720mgrod
>>> |                                  | default |                |  |
>>> True    |
>>> | 7d8d021ac276468bb474a19b8fc1dfd2 | cinder
>>> |                                  | default |                    |
>>> cinder at localhost                   | True    |
>>> | 86874cd1808a4c83ac998365a0ee4c4b | placement
>>> |                                  | default |                    |
>>> placement at localhost                | True    |
>>> | 9500dc78f7e24fe698e108537b6c9c71 | glance
>>> |                                  | default |                    |
>>> glance at localhost                   | True    |
>>> | a24de5a8ef444a779a0fb460b663a9b1 | heat
>>> |                                  | default |                    |
>>> heat at localhost                     | True    |
>>> | admin                            | admin
>>> |                                  | default |
>>> |                                    | None    |
>>> | c3c6aa2b0fc24e30a4615cbdd19bbbb0 | ironic
>>> |                                  | default |                    |
>>> ironic at localhost                   | True    |
>>> | c76b9e28a88041c0b4805ea5932ddd2c | magnum
>>> |                                  | default |                    |
>>> magnum at localhost                   | True    |
>>> | ceilometer                       | ceilometer
>>> |                                  | default |
>>> |                                    | True    |
>>> | cinder                           | cinder
>>> |                                  | default |
>>> |                                    | True    |
>>> | dde9fdcb268a4d44a29894f37981c448 | admin        |
>>> f4b4256e014a47e983f2904a9a3dac8e | default |                    |
>>> root at localhost                     | True    |
>>> | glance                           | glance
>>> |                                  | default |
>>> |                                    | True    |
>>> | heat                             | heat
>>> |                                  | default |
>>> |                                    | True    |
>>> | magnum                           | magnum
>>> |                                  | default | OpenStack
>>> |                                    | True    |
>>> | magnum_admin                     | magnum_admin
>>> |                                  | default | OpenStack
>>> |                                    | True    |
>>> | neutron                          | neutron
>>> |                                  | default |
>>> |                                    | None    |
>>> | nova                             | nova
>>> |                                  | default |
>>> |                                    | True    |
>>> | openst_admin                     | openst_admin
>>> |                                  | default | OpenStack
>>> |                                    | True    |
>>> | osadmin                          | osadmin      |
>>> f4b4256e014a47e983f2904a9a3dac8e | default |
>>> |                                    | True    |
>>> | placement                        | placement
>>> |                                  | default |
>>> |                                    | True    |
>>> | swift                            | swift
>>> |                                  | default |
>>> |                                    | True    |
>>> | temgr                            | temgr
>>> |                                  | default |  |       | True    |
>>> +----------------------------------+--------------+---------
>>> -------------------------+---------+--------------------+---
>>> ---------------------------------+---------+
>>>
>>> Would you happen to have any ideas on this duplicate users scenario?
>>>
>>> On another note: now I go to try my domain account. This time I enter in
>>> the domain "mydomain", my username "temgr", and my password. I now get a
>>> somewhat familiar error:
>>>
>>> "You are not authorized for any projects or domains."
>>>
>>> If I try to find what projects my user is assigned to, I get the below
>>> error:
>>>
>>> # openstack project list --user temgr
>>> You are not authorized to perform the requested action:
>>> identity:list_user_projects. (HTTP 403) (Request-ID:
>>> req-2ee22612-f023-4186-8cce-cf29005444a5)
>>>
>>> If I switch back to the default *policy.json file, I can check (I
>>> created the "mydomain" domain and project to test).
>>>
>>> # openstack project list --user temgr --long
>>> +----------------------------------+----------+-------------
>>> ---------------------+-----------------------------------+---------+
>>> | ID                               | Name     | Domain
>>> ID                        | Description                       | Enabled
>>> |
>>> +----------------------------------+----------+-------------
>>> ---------------------+-----------------------------------+---------+
>>> | 7872eb2b3630406b86b669aa978796bc | mydomain |
>>> 30d0cc8521be4074bb8289f6be12f3fe |                                   |
>>> True    |
>>> | e33b4ba7b3a449f7b267694efe1dbd38 | services |
>>> default                          | Tenant for the openstack services |
>>> True    |
>>> | f4b4256e014a47e983f2904a9a3dac8e | admin    |
>>> default                          | admin tenant                      |
>>> True    |
>>> +----------------------------------+----------+-------------
>>> ---------------------+-----------------------------------+---------+
>>>
>>> # openstack role list
>>> +----------------------------------+------------------+
>>> | ID                               | Name             |
>>> +----------------------------------+------------------+
>>> | 2bf0aa5d94254e9a8a976000f925dcfd | ResellerAdmin    |
>>> | 614641898bf14b1bade2a9f331a52bac | heat_stack_owner |
>>> | 6795eb6529be4eb395cc9f22f834ee72 | SwiftOperator    |
>>> | 9fe2ff9ee4384b1894a90878d3e92bab | _member_         |
>>> | c373a7e73ed84b00aac92698ef23af4a | admin            |
>>> | f9bd71427880479182c32b84a7c1611a | heat_stack_user  |
>>> +----------------------------------+------------------+
>>>
>>> # openstack domain list
>>> +----------------------------------+----------+---------+---
>>> -----------------+
>>> | ID                               | Name     | Enabled |
>>> Description        |
>>> +----------------------------------+----------+---------+---
>>> -----------------+
>>> | 30d0cc8521be4074bb8289f6be12f3fe | mydomain | True
>>> |                    |
>>> | 90a99943256b4a22a5c51352d428a7e5 | heat     | True
>>> |                    |
>>> | default                          | Default  | True    | The default
>>> domain |
>>> | f950f5d49d8f4acba4790113580a956f | magnum   | True
>>> |                    |
>>> +----------------------------------+----------+---------+---
>>> -----------------+
>>>
>>> # openstack role assignment list --user temgr
>>> +----------------------------------+-------+-------+--------
>>> --------------------------+---------------------------------
>>> -+-----------+
>>> | Role                             | User  | Group |
>>> Project                          | Domain                           |
>>> Inherited |
>>> +----------------------------------+-------+-------+--------
>>> --------------------------+---------------------------------
>>> -+-----------+
>>> | c373a7e73ed84b00aac92698ef23af4a | temgr |       |
>>> 7872eb2b3630406b86b669aa978796bc |                                  |
>>> False     |
>>> | c373a7e73ed84b00aac92698ef23af4a | temgr |       |
>>> e33b4ba7b3a449f7b267694efe1dbd38 |                                  |
>>> False     |
>>> | c373a7e73ed84b00aac92698ef23af4a | temgr |       |
>>> f4b4256e014a47e983f2904a9a3dac8e |                                  |
>>> False     |
>>> | c373a7e73ed84b00aac92698ef23af4a | temgr |
>>> |                                  | 30d0cc8521be4074bb8289f6be12f3fe |
>>> False     |
>>> | c373a7e73ed84b00aac92698ef23af4a | temgr |
>>> |                                  | default                          |
>>> False     |
>>> +----------------------------------+-------+-------+--------
>>> --------------------------+---------------------------------
>>> -+-----------+
>>>
>>> Am I missing something with the above configuration?
>>>
>>> Again.. Sorry this was so scattered. I can provide any additional
>>> information of course. Any ideas or direction would be much appreciated.
>>>
>>>
>>>
>>> On Tue, Jul 25, 2017 at 8:33 PM, Erik McCormick <
>>> emccormick at cirrusseven.com> wrote:
>>>
>>>> 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=NorthA
>>>>> merica,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=N
>>>>> orthAmerica,OU=Global,DC=DOMAIN,DC=NET
>>>>> user_objectclass = person
>>>>> user_filter = (memberOf=CN=OpenStackAdmins,O
>>>>> U=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=UserAcco
>>>>> unts,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/20170726/9b8bf3b2/attachment.html>


More information about the Openstack mailing list