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 <[email protected]> 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 <[email protected]> > 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@localhost | True | >> | 0c19f40cb1364ebb876bfd90918dead2 | ceilometer >> | | default | | >> ceilometer@localhost | True | >> | 11599c71ad114654b003b654e03a4e6b | neutron >> | | default | | >> neutron@localhost | True | >> | 170716mgr | 170716mgr >> | | default | | | True | >> | 39cc615e69824f108bc9366224f25a66 | nova >> | | default | | >> nova@localhost | True | >> | 44c1b20c016d41ec9ea69f667540c227 | gnocchi >> | | default | | >> gnocchi@localhost | True | >> | 498777mgr | 498777mgr >> | | default | | | True | >> | 646b17dc9b7c4a4d8c96fe7fde9a2a7a | swift >> | | default | | >> swift@localhost | True | >> | 7729a23a63824862825b2e7ed707b907 | heat-cfn >> | | default | | >> heat-cfn@localhost | True | >> | 783720mgrod | 783720mgrod >> | | default | | | >> True | >> | 7d8d021ac276468bb474a19b8fc1dfd2 | cinder >> | | default | | >> cinder@localhost | True | >> | 86874cd1808a4c83ac998365a0ee4c4b | placement >> | | default | | >> placement@localhost | True | >> | 9500dc78f7e24fe698e108537b6c9c71 | glance >> | | default | | >> glance@localhost | True | >> | a24de5a8ef444a779a0fb460b663a9b1 | heat >> | | default | | >> heat@localhost | True | >> | admin | admin >> | | default | >> | | None | >> | c3c6aa2b0fc24e30a4615cbdd19bbbb0 | ironic >> | | default | | >> ironic@localhost | True | >> | c76b9e28a88041c0b4805ea5932ddd2c | magnum >> | | default | | >> magnum@localhost | True | >> | ceilometer | ceilometer >> | | default | >> | | True | >> | cinder | cinder >> | | default | >> | | True | >> | dde9fdcb268a4d44a29894f37981c448 | admin | >> f4b4256e014a47e983f2904a9a3dac8e | default | | >> root@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 < >> [email protected]> wrote: >> >>> Answers inline below... >>> >>> On Tue, Jul 25, 2017 at 5:26 PM, Tristan Evans <[email protected]> >>> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 : [email protected] >>>>> > Unsubscribe : http://lists.openstack.org/cgi >>>>> -bin/mailman/listinfo/openstack >>>>> > >>>>> >>>> >>>> >>> >> >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
