+++ 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.
the issue does exist in 3.4
Ondra, can you please setup group and matching user on ADW-W2K12RC2 ? Thanks!
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?
(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.
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))'
*** Bug 1131155 has been marked as a duplicate of this bug. ***
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.
oVirt 3.5 has been released and should include the fix for this issue.