Bug 1457742

Summary:	User cannot act as an admin on LDAP mapped domain
Product:	Red Hat OpenStack	Reporter:	Marek Aufart <maufart>
Component:	openstack-keystone	Assignee:	John Dennis <jdennis>
Status:	CLOSED NOTABUG	QA Contact:	nlevinki <nlevinki>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	alee, dhajare, josorior, maufart, nkinder, rmascena, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-14 08:17:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1455829

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.