Bug 1131179

Summary:	[AAA] group roles not inherited by members of the group when the OU of the group contains upper case letters
Product:	[oVirt] ovirt-engine-extension-aaa-ldap	Reporter:	wdaniel
Component:	Core	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ondra Machacek <omachace>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	alonbl, bazulay, benglish, bugs, dornelas, ecohen, gklein, iheim, lpeer, lsurette, omachace, oourfali, prmarino1, pstehlik, rbalakri, Rhev-m-bugs, yeylon, yzaslavs
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	1.0.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	infra
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:	1131155	Environment:
Last Closed:	2014-10-17 12:36:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1131155
Bug Blocks:	1063095

Description wdaniel 2014-08-18 15:43:08 UTC

+++ This bug was initially created as a clone of Bug #1131155 +++

Description of problem:
when adding a LDAP user if the user is a member of a group with upper case letters in the OU for the group the roles assigned to said group will not be inherited by the user.

Version-Release number of selected component (if applicable):
This was observed in Ovirt 3.2 and 3.3 when connected to a 389 server version 1.2.11.15 when connected in RHDS mode

How reproducible:
fairly simple

Steps to Reproduce:
1. create a group in 389 server where the name or OU contain at lease on capital letter
2. add the group in ovirt and assign roles to it
3. create a user in 389 server and make it a member of the group previously created in step 1.
4. add the user in ovirt

Actual results:
the user will not inherit any roles from the group.
also you will see 00000000-0000-0000-0000-000000000000 in the group_ids field of the ad_groups table in the database

Expected results:
the user should inherit the roles assigned to the group

Additional info:
The problem is the memberof plugin in 389 server normalizes the OU's for the groups to all lower case. When the user is added it looks like it trying to match the group name via a exact match in the ad_groups table instead of an ilike.
A simple workaround is to update the ad_groups table manually and change the contents of the name field in the ad_groups table to lowercase. Also interesting to note is you can still modify the roles for the group without any issue after you have changed it to lower case.

This was discussed on the user mailing list here
http://lists.ovirt.org/pipermail/users/2014-August/026765.html

--- Additional comment from Alon Bar-Lev on 2014-08-18 11:10:11 EDT ---

3.3 version will not get fixes, please check with latest 3.4.z before reporting new issues, thanks!

most probably already fixed in the new ldap implementation within 3.5.

not sure it worth the effort of z-stream for 3.4.

QA note: please test using new ldap implementation, if ok, please mark as verified with component ovirt-engine-extension-aaa-ldap.

Comment 1 Paul Robert Marino 2014-08-28 15:19:28 UTC

the issue does exist in 3.4

Comment 2 Yair Zaslavsky 2014-10-07 00:22:40 UTC

Ondra, can you please setup group and matching user on
ADW-W2K12RC2 ?


Thanks!

Comment 3 Yair Zaslavsky 2014-10-11 17:34:44 UTC

I have tested with the setup you provided on 3.5 , and it does not work as well.

OU:
dn: OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com

Group:
dn: CN=QA-Group,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com

User:
dn: CN=qa1,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com

I wonder if this is setup issue, or something else.
With other users and groups in the setup - it works.

Alon - anything to add here at this stage?

Comment 4 Yair Zaslavsky 2014-10-11 17:35:43 UTC

(In reply to Yair Zaslavsky from comment #3)
> I have tested with the setup you provided on 3.5 , and it does not work as
> well.
> 
> OU:
> dn: OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
> 
> Group:
> dn:
> CN=QA-Group,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,
> DC=com
> 
> User:
> dn:
> CN=qa1,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
> 
> I wonder if this is setup issue, or something else.
> With other users and groups in the setup - it works.
> 
> Alon - anything to add here at this stage?


The authz provider (the generic ldap one) returns an empty list of groups for the qa1 user.

Comment 5 Alon Bar-Lev 2014-10-11 20:17:44 UTC

Some of the searches return valid response, some are not. Probably the gc is not synchronized throughout domain.

$ dig @brq-w2k12r2.ad-w2k12r2.rhev.lab.eng.brq.redhat.com SRV _gc._tcp.ad-w2k12r2.rhev.lab.eng.brq.redhat.com

_gc._tcp.ad-w2k12r2.rhev.lab.eng.brq.redhat.com. 600 IN SRV 0 100 3268 win-23q60qfkb3d.ad-w2k12r2p.rhev.lab.eng.brq.redhat.com.
_gc._tcp.ad-w2k12r2.rhev.lab.eng.brq.redhat.com. 600 IN SRV 0 100 3268 brq-w2k12r2.ad-w2k12r2.rhev.lab.eng.brq.redhat.com.

$ ldapsearch -E pr=100/noprompt -o ldif-wrap=no -p 3268 -h brq-w2k12r2.ad-w2k12r2.rhev.lab.eng.brq.redhat.com -x -w Heslo123 -D 'user3.lab.eng.brq.redhat.com' -b '' '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(member:1.2.840.113556.1.4.1941:=CN=qa1,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com))' cn

dn: CN=QA-Group,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
cn: QA-Group


$ ldapsearch -E pr=100/noprompt -o ldif-wrap=no -p 3268 -h win-23q60qfkb3d.ad-w2k12r2p.rhev.lab.eng.brq.redhat.com. -x -w Heslo123 -D 'user3.lab.eng.brq.redhat.com' -b '' '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(member:1.2.840.113556.1.4.1941:=CN=qa1,OU=rh-Brno,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com))'

Comment 6 Alon Bar-Lev 2014-10-11 20:19:27 UTC

*** Bug 1131155 has been marked as a duplicate of this bug. ***

Comment 7 Alon Bar-Lev 2014-10-12 00:18:20 UTC

ok, renaming back as the original issue is unrelated to new implementation. per comment#5, different issue and will be solved separately.

not sure why it was cloned.

Comment 8 Sandro Bonazzola 2014-10-17 12:36:39 UTC

oVirt 3.5 has been released and should include the fix for this issue.