[Openstack] Keystone: domain_specific_drivers_enabled not working with LDAP
Tristan Evans
azurepancake at gmail.com
Thu Jul 27 01:13:55 UTC 2017
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
a32c0f55cb6a7562a0bf7a5aede6841636ab45b7a571dd3d5fd477dfefc26330 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/95c1439b/attachment-0001.html>
More information about the Openstack
mailing list