Bug 1457742 - User cannot act as an admin on LDAP mapped domain
Summary: User cannot act as an admin on LDAP mapped domain
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: John Dennis
QA Contact: nlevinki
URL:
Whiteboard:
Depends On:
Blocks: 1455829
TreeView+ depends on / blocked
 
Reported: 2017-06-01 08:47 UTC by Marek Aufart
Modified: 2017-07-14 08:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-14 08:17:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1455829 0 unspecified CLOSED Cloud provider is not collecting data for sub-tenant 2023-09-14 03:58:11 UTC

Description Marek Aufart 2017-06-01 08:47:02 UTC
Description of problem: There two keystone domains - default and cee, cee is mapped to LDAP. We want set a default admin user as domain admin of cee (LDAP) domain. Command doesn't fail, but admin user cannot act as admin of domain cee.

Version-Release number of selected component (if applicable):


How reproducible: always


Steps to Reproduce:
1. let have two domains in keystone, default and LDAP based named e.g. cee
2. grant admin user admin role on cee domain
3. authorize against cee domain with admin user (without project/tenant)

Actual results: auth error


Expected results: admin can access all projects/tenants in cee domain


Additional info: This BZ came from CloudForms integration https://bugzilla.redhat.com/show_bug.cgi?id=1455829 see the original BZ for more information.

Comment 1 Ade Lee 2017-06-16 14:30:52 UTC
Can you confirm that OS_PROJECT_DOMAIN_NAME is set to the cee domain?

Comment 2 Marek Aufart 2017-06-19 15:27:43 UTC
openstack_domain_id was set to cee domain IIRC, but I cannot say what project was specified or if it was nil. Does OS_PROJECT_DOMAIN_NAME matter for this case in Keystone HTTP API?

Comment 3 Raildo Mascena de Sousa Filho 2017-06-26 14:35:50 UTC
Hi Marek, 


Yes, for this case OS_PROJECT_DOMAIN_NAME will be important to define the scope of the token.

We add more details in the original bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=1455829

Can you confirm that is enough to fix their problem?

Comment 4 Marek Aufart 2017-07-13 09:44:45 UTC
Hi, we're testing adding OS_PROJECT_DOMAIN_NAME and OS_USER_DOMAIN_NAME parameters instead of OPENSTACK_DOMAIN_ID.

Do you know from what OSP version are OS_PROJECT_DOMAIN_NAME and OS_USER_DOMAIN_NAME were parameters supported?

Comment 5 Marek Aufart 2017-07-14 08:17:22 UTC
Using OS_PROJECT_DOMAIN_NAME and OS_USER_DOMAIN_NAME parameters looks to be working for us. No need for fix on Keystone side, thanks.


Note You need to log in before you can comment on or make changes to this bug.